Record detail
Everything about one record: statement, rationale, acceptance criteria, state, priority, owner and source.
For: Product owner, Tester, Team developer
What you can do here
- Read the record as an agent would receive it.
- Choose Edit to change the text, the acceptance criteria or the state.
- If it was proposed by an AI agent, Proposed by shows which one.
Change proposals
Agents cannot edit records. When you ask an agent to change one, it proposes the change (propose_change) and a banner appears here. Change proposals shows it as a difference: removed text in red, new text in green, and for acceptance criteria which are new, reworded or removed.
- Accept change applies it under the same rules as Edit (your permission for the record's state; the agent's reason is kept in the history).
- A reworded criterion keeps its identity, so the tests linked to it stay linked.
- If the record changed after the proposal, it can only be rejected; ask the agent for a new one.
- With maker-checker on, the person the agent acted for cannot accept a change to an Authority record.
Verifying acceptance criteria
Each criterion has its own status. Satisfaction is the share of criteria verified as met; it shows here, in the record lists, in Explorer and on the Overview.
| Status | Meaning |
|---|---|
| Not verified | Nobody has checked it yet (also after its wording changed). |
| Met | Checked and satisfied. |
| Not met | Checked and not satisfied yet. |
- Check the criterion, for example by running the test or trying the feature.
- Optionally write the evidence: a test name, a pull request, a demo.
- Press Mark met or Mark not met. Reset returns it to Not verified.
Tip Coding agents with the propose permission can report results too, through report_acceptance_result. Their reports show the agent's name, and you can override them here.
Relations
Relations place the record in the traceability chain. Agents use them to receive exactly the context a task needs: the chain above the record, how it is realized, the constraints that apply and any conflicts.
| Relation | Use it when |
|---|---|
| Refines | This record details a higher one: business → objective, stakeholder → business, functional / non-functional → stakeholder or business. |
| Realizes | A technical requirement states how a functional or non-functional one is achieved. |
| Constrains | A constraint limits specific requirements. Constraints without links apply to the whole project. |
| Replaces | A newer record takes the place of an older one of the same type (retire the old one). |
| Conflicts with | The two cannot both hold. Neither can become Authority until the conflict is resolved. |
| Relates to | Background only. |
- Add a relation with the form at the bottom; the lists only offer record types the rules allow.
- Suggest relations with AI proposes links with a reason; accept or dismiss each one.
- Links proposed by coding agents appear as Proposed; confirm or reject them.
- A confirmed conflict is closed with Resolve: say how it was resolved and, if a decision settles it, give its code; the decision is linked to both records and the resolution stays in the history.
- Chain shows acceptance satisfaction of this record together with everything below it.
Keep in mind An Authority record cannot refine or realize a Draft or Retired record, and a record cannot go back to Draft or be Retired while Authority records depend on it.