Draft regulated requirements with code and test traceability

Why use this

1. A regulated engineering team may need requirements that explain both intended behavior and how evidence demonstrates it. Drafting directly from code can accidentally turn an implementation quirk into a requirement or attach a test that does not cover the stated criterion.

2. This job could prepare traceable requirements candidates for senior review. Keeping stakeholder intent, implementation evidence and test coverage distinct helps reviewers see where the draft needs correction rather than treating structure as regulatory assurance.

Why an agent / simpler alternative

Useful judgment

Connect source behavior and issue intent to testable statements, identifying unsupported acceptance criteria and traceability gaps.

Simpler alternative

Use a controlled requirements template manually when the scope is small and evidence is already mapped.

Unsuitable when

The draft would be treated as approved regulated documentation or compliance evidence without qualified review.

Proposed inputs

1. Name

   Code/issue excerpts

   Owner

   Authorized engineering owner

   Minimum scope

   Relevant versioned behavior and requirement discussions

   Quality check

   Distinguish intended behavior from incidental implementation

2. Name

   Requirement/test framework

   Owner

   Qualified owner

   Minimum scope

   Approved format, acceptance conventions and evidence identifiers

   Quality check

   Check test status, scope and version

Access and setup — proposed or unknown

Proposed minimum

1. Review synthetic code descriptions and issue/test records; no repository access, test execution or controlled-document updates.

Compatibility unknowns

1. Current traceability tools, code coverage, document controls and runtime compatibility are unknown.

External actions requiring approval

1. Controlled-record changes, evidence sharing, code changes and regulatory submissions require appropriate authorization.

Expected deliverable and review checks

Proposed artifact

Requirements draft with criterion IDs, code/issue/test links, missing evidence and senior-review questions.

Critical checks

1. Keep requirements testable; verify evidence actually covers each criterion; distinguish test plans from passed runs and drafts from approved records.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A code workaround becomes mandatory behavior

   Why it matters

   The draft freezes an accidental design choice

   Proposed response

   Trace it to stakeholder intent or mark it unresolved.

2. Signal

   A test title is mistaken for proof of coverage

   Why it matters

   Traceability appears complete without relevant evidence

   Proposed response

   Inspect scope and status before linking it as support.

Effort and cost — unknown

Setup work

1. Define traceability categories and approval ownership.

Ongoing review

1. Senior engineers review intent, criteria and evidence adequacy.

Unknowns

1. Evidence completeness, regulatory context, revision effort and tooling costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent an issue, behavior description and two test records with mismatched scope/status; draft a traceability row.

Acceptance checks

1. Flag unsupported criteria and unexecuted tests; approve no requirement; infer no compliance.

Stop conditions

1. Stop if authoritative intent or controlled-document permissions are unresolved.

Limits

1. A structured draft cannot establish regulatory compliance, validated requirements or sufficient testing evidence.