Amendment Reviews

When a reviewer selects Amendment Required, the governance flow enters an iterative review cycle. The API is locked for changes, the submitter addresses feedback, and the flow continues without starting from scratch.

How It Works

Reviewer requests amendment → API entity is locked
Submitter is notified — changes are needed
Submitter updates spec and addresses feedback
Submitter resubmits for review
Reviewer re-reviews (Round 2+)
Reviewer approves or requests further amendments

Entity Locking

When an amendment is requested, the API entity is locked via a LockedByGovernanceFlowId. This prevents:

Other deployments of the same API
Concurrent governance flows for the same entity
Changes by anyone other than the submitter

The lock is released when the flow reaches a final outcome (Approved or Rejected).

Review Rounds

Each amendment cycle increments the review round:

Round	Meaning
Round 1	Initial review
Round 2	First re-review after amendment
Round 3+	Subsequent re-reviews

The management UI shows round dividers in the approvals timeline, making it clear how many iterations occurred.

Reviewer Experience

When re-reviewing after an amendment, reviewers see:

The updated specification (with changes highlighted)
The original comments they left requesting amendments
The review round number — so they know this is a re-review
Updated compliance scores reflecting any improvements

Best Practices

Be specific in amendment requests. “Fix the error responses” is less useful than “The 404 response is missing the standard error schema — see the compliance report for details.”
Use amendments, not rejections, for fixable issues. Rejection ends the flow permanently. Amendments keep the flow alive for iteration.
Track round count. If an API is on round 4+, it may indicate a design misalignment that needs a conversation rather than more amendments.