Keep stakeholder intent authoritative

State the outcome before choosing the implementation

An operator needs to resume a failed import without losing or duplicating accepted records. That outcome can govern several possible checkpoint designs. Starting with “store a checkpoint every 100 records” chooses a mechanism before establishing whether it protects the actual need.

Review the meaning of accepted, interruption, and source revision. Identify operational limits and consequences. A concise sentence can still depend on decisions that need to be recorded.

Write acceptance criteria that distinguish success

Cover the ordinary outcome, failures, recovery, and important boundaries. For the import example, include interruption before and after checkpoint persistence, replay of accepted IDs, and a changed input source. Each criterion should say what the stakeholder can observe rather than merely naming an internal function to test.

System and software requirements then allocate the responsibilities needed to meet those criteria. Unit evidence for one child is useful, but it does not substitute for acceptance evidence of the whole stakeholder outcome.

Recover intent without approving accidents

In an existing system, requirements may be scattered across contracts, documentation, tests, code, support history, and domain knowledge. Recover candidate statements with their sources and disagreements. Do not assume the current implementation is always correct or that one new prompt overrides prior accepted intent.

proof req new specs/stakeholder --component importer \
  --description "An interrupted import resumes without losing or duplicating accepted records" \
  --preview

This previews structured authoring for the configured stakeholder spec. It does not approve the candidate or provide all its acceptance criteria. Review the generated shape and applicable defaults before writing and advancing the record.

Preserve authority and the path into software

Use the project's approval and delegation policy to resolve intent. Agents may draft, recover, review, and approve within authorized scope. The requirement's source, rationale, and approval history should make that scope inspectable.

proof req show STK-REQ-042 --with lineage,traces
proof audit --check obligation_completeness --verbose

The first shows the recorded relationships. The second checks allocation of declared stakeholder obligation classes to active system satisfiers. Neither proves the stakeholder set is complete or that the product meets every accepted criterion.

Continue from here

Derive system responsibilities. Define stakeholder acceptance evidence.

Bring a stakeholder promise that gets lost when work is split into implementation tasks. Bring a change to Proof.