Acceptance criteria
Authorize the conditions for a change, inspect their evidence and apply your organization's shipping policy.
Early access. Email hello@archdocs.io to turn it on for your organization.
Write acceptance criteria when you need explicit conditions for a change and a record of how each condition is satisfied. Criteria are available on every plan when enabled. Free permits up to 10 criteria per design doc; Team and above have no plan count limit.
Propose and authorize criteria
- Open the design doc's Acceptance criteria panel and add criteria, or ask an agent to call
propose_acceptance_criteria. - Mark each criterion required or advisory and choose the fact or attestation it needs.
- Have a person with
verification:reviewreview and authorize the draft. Agents can propose criteria and request review, but cannot authorize them.
A proposal stays a draft until a person authorizes it. The authorized statements, their versions and the person who authorized them remain part of the record. Changing a statement can require new evidence; evidence for an earlier wording does not automatically satisfy its replacement.
Choose the evidence
You can require a human attestation or allow a human or agent to attest to a statement. Submitted evidence keeps the note, attachments and attribution. A journal entry never counts as verification evidence.
On Business or Enterprise, with evidence tracking enabled, you can also use GitHub facts such as a pull request being merged, named checks passing or a commit being included. Keep the connector source and scope visible. Each linked pull request and Final integrated code evaluate different subjects. GitHub evidence covers linked PRs and selected commits; it does not establish that every change belonging to the work is linked.
An agent report is not independent verification or approval. An explicit agent attestation can satisfy an authorized attestation criterion under a policy that accepts it. The result retains Agent-attested attribution, including when a person reviews it. Review does not turn an agent's report into a GitHub fact.
Read the result
The criterion badges use these names:
| Status | What to do next |
|---|---|
| Satisfied | Read the source and scope to see what satisfied the authorized condition. |
| Failed | Inspect the failed fact or rejected evidence. |
| Pending | Supply evidence, wait for checks or complete the required review. |
| Inconclusive | Resolve unavailable or insufficient source data before drawing a conclusion. |
| Needs recheck | Recheck after the linked code, subjects or policy change. The earlier result no longer applies. |
Source labels distinguish Checked via GitHub, From Archdocs records, Human-attested and Agent-attested. A Verified context label means the active authorized criterion has a Satisfied result. It says nothing broader than that criterion under the effective policy. It does not approve a design, certify a whole system or prove deployment correctness.
Verified in the document verification summary means required criteria are satisfied and the results are not stale. Advisory criteria can still need attention. Read individual results and their sources before relying on the summary.
Set the verification policy
Configuration requires Team or above, a person and verification:manage. The default Standard policy accepts human and agent attestations without an evidence-review step. Human-reviewed requires a person to review attestations. Agents never review evidence. The default also sets the ship gate to Warn, does not require criteria to ship and does not let agents ship a doc with acceptance criteria. Free uses these defaults and cannot edit the policy.
| Ship gate | Effect |
|---|---|
| Allow | Permit shipping with unsatisfied criteria. |
| Warn | Require acknowledgement for blocking results, or for draft criteria when no authorized criteria exist. This is the default. |
| Block | Refuse normal shipping until required criteria pass and any configured criteria requirement is met. If no authorized criteria exist, authorize or discard the draft before shipping. |
Advisory criteria do not block shipping. Loosening a policy requires a reason. A person with verification:manage can record a ship exception for current results. The criteria keep their results and the doc records Shipped with an exception.
A merged PR, a passing check, a closed issue and a correct deployment remain different facts. Implemented code does not establish general availability.