Record detail

What you can do here

• Read the record as an agent would receive it.
• Use the details form to change the text, the acceptance criteria drawer to edit criteria, and Status to change the state.
• If it was proposed by an AI agent, Proposed by shows which one.

When the record changed while its form was open

If a record changes its state while you have its form open — someone approves it, the preparation exit makes it binding, it is retired — your save is refused and nothing is written: "… changed its state after you opened this form (it was approved, made binding or retired meanwhile), so nothing was saved. Open the record again and make your change there." The acceptance criteria panel rechecks the current state and your permissions when you submit it. The fields form does not replace the independently edited criteria list. Field and criteria saves keep their required history and guided changes in the same transaction: a failure saves none of that transaction. If a concurrent operation prevents the save, keep your inputs and review the latest record before trying again.

Functional Requirement workspace

A saved Functional Requirement opens as one workspace. Its heading identifies the record and authority state. Context shows every Refines, Constrained by, Governed by and Realized by neighbour; there is no compulsory single parent. Edit context relations moves to the independent relation commands below the record, for people with Relations edit permission. The left working set filters Functional Requirements by text and state and remembers its scroll and return address for you in this solution; an open record outside the filter is still identified. Field and task drafts are never stored in that working set.

The details form edits Title, Code, Priority, Owner, Type, Source reference, Rationale and Statement, plus Spec perspective when guidance offers it. State is read only here; use Status above. Origin and its evidence remain read only. Authority changes need a reason. Your roles must permit editing at the current authority state. A browser without protected workspace navigation shows the fields read only.

Save changes compares the version opened with the current saved version, including changes to criteria. A conflict keeps your writing. Review saved values, then either use the saved version and discard the draft or explicitly keep your draft against the reviewed version for another manual save. A missing target, refused permission, mismatched response or unconfirmed save keeps the draft and blocks another attempt until reload; the first operation may already have completed.

Acceptance criteria opens the existing right drawer with evidence, tests, covering work and defects. The criterion cards follow the drawer surface so their codes, evidence and links remain readable at every light level. Open Acceptance criteria, History or Link code with Enter; Escape closes a clean drawer and returns focus to its opener. If a task has unsaved changes, Escape opens the shared leave decision. Keep editing preserves the draft; Discard and continue drops only the unsaved changes. In History, Tab to the History changes region and use the arrow keys to read wide columns. Edit criterion text and a change reason with Save criteria; rewording resets verification. Each verification form has its own Verification and Evidence fields and Save verification. Change proposals has an independent Decision and optional Note, followed by Save decision. Code links, relation suggestions and conflict resolutions also save independently. Refresh task details rereads the drawer's original target while keeping dirty inputs. Tasks pause while this requirement's fields are saving. Suggest relations asks for candidates, Ask again refreshes them, Accept suggestion stores one after the relationship checks, and Dismiss drops a candidate without linking it. Reading a task does not grant permission to edit it: record editing, Criteria verify, Relations edit and Work edit remain separate.

Adopting reviewed saved field values replaces only the field draft; independent relation and task edits stay in place. Pin task keeps the drawer on that requirement while you read another. A dirty or saving task holds its original target. Closing or following another target asks about its changes; Keep editing preserves them, Discard and continue drops only the selected drafts, and Save and continue proceeds only when all selected saves are confirmed. History shows changes; Impact shows what a change reaches. Resolve asks how a conflict was settled and optionally names its decision, in the drawer.

Leaving by a peer, Back, another page or solution switch uses the same decision for all affected fields and tasks. Separate saves can partly succeed: confirmed tasks remain saved while a failed field or task keeps its draft and stops navigation. Type can move the record to another type's existing screen. Save or discard open tasks first; a criterion save can require a fresh field review. Only after a confirmed Type change and settled tasks does the workspace follow the saved record's new address. If another task stops that step, Open saved record makes another guarded attempt after you resolve it. New Functional Requirement keeps its existing create and return flow. If a staged relation fails after creation, the saved record still opens once and Previous action shows what failed. Use Add relation to repair that edge instead of creating the record again. Warnings carried by an older record address remain visible on the saved page.

Kept changes in this tab. Some browsers, such as Safari on iPhone, cannot ask before their own Back or Forward gesture changes the page. There the requirement says so under its heading and keeps every unsaved field and eligible task change in this browser tab as you type, for this person, tenant, solution and record only. Links, peers, panels, solution switches and Sign out still ask Keep editing, Save and continue or Discard and continue first. After a native Back or Forward, return to the requirement in the same tab: the kept changes come back with Restored unsaved changes kept in this tab and remain unsaved. Nothing is stored or sent until you choose Save. Saving checks the changes against the version you first opened; if someone saved a newer version meanwhile, you review both before deciding, exactly as for any conflict. Discard kept changes removes them.

Kept changes expire eight hours after your last change and are removed the next time the page looks. Signing out removes every change kept in the tab. They are not shared with other tabs or devices, and the browser may remove them earlier, for example in private browsing or when its storage is full. If the tab cannot keep a change, that change is not accepted, earlier kept changes stay, and editing pauses with an explanation. Passwords, sign-in values and one-time results are never kept: Share outside the team, which shows a package token once, needs a browser with protected navigation. If a save was sent but its result never arrived, for example because you went Back while it was saving, it may already be stored. Nothing is sent again: on return the page shows your kept changes beside the saved values. Choose Keep my changes for an explicit save to save them yourself (a conflict appears if the earlier save went through), or Discard kept changes. If your roles no longer allow editing, kept changes are not shown and can only be discarded.

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.

1. Check the criterion, for example by running the test or trying the feature.
2. Optionally write the evidence: a test name, a pull request, a demo.
3. On other record screens press Mark met or Mark not met; Reset returns it to Not verified. In the Functional Requirement workspace choose Verification, add Evidence if needed, and press Save verification. Choosing Not verified resets that criterion.

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.

• 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.

Authority states