Write the requirement that would otherwise never exist — the default, the misuse case, the retention period — and hold each draft, with the finding it came from, for a named engineering owner.
A requirement is drafted from the finding that raised it, and the finding travels into the document with it.
02
A section is written for the default state, because a default nobody specifies is set by whoever writes the code.
Reason
03
A hazard is logged, and the control that answers it is drafted as a requirement with its acceptance criterion.
04
A security default is drafted, since the Cyber Resilience Act binds that default from December 2027.
05
A retention period is stated, since minimisation by default under Article 25(2) is drafted, not coded.
Decide
06
A misuse section is written, because reasonably foreseeable misuse is a section and not a bug report.
07
A clause is marked not applicable, and the justification for scoping it out is drafted in the same line.
Out
08
A requirement cannot be stated without a decision nobody has taken, and that is raised as the finding.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Drafting, tracing and versioning belong to the agent. Approval belongs to a named engineer or quality owner, who takes the requirement into the design record and owns it there.
Example workflow
One requirement, finding to approval
AgentHuman
1Source material receivedA hazard log entry, an interview note, a standard clause, a support finding or a change request
2Context assembledThe document now in force, the requirements it already carries, the hazards open against it and the clauses it answers
3Requirement draftedThe requirement, its acceptance criterion, the source it came from and confidence
4Controls appliedCoverage checks, duplicate-requirement checks, testability checks and drafting confidence
No human action required
Stages 1 to 4 run unaided, and nothing is approved at any of them — the agent is drafting, and the owner lane opens at the approval gate.
5DecisionSplits at the approval gate
Routine requirement
Goes to the named owner to approve.
Anything touching a hazard
Adds a quality owner read first.
Owner review
The requirement is held with its source, its acceptance criterion and the coverage it closes.
Approve · Amend · Send to quality review
Approved — by the named owner▼
6Repository and tracker records updatedOnly where write access and document control allow it
7Outcome evaluatedCoverage closed, requirement churn, owner amendments and what review found
Amendments
Each owner amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Taking a requirement into the design record.
Deciding a device software safety classification.
Judging whether a standard applies to a product.
Signing a technical file for a regulator.
Automation boundaryAgent acts unaided
✓Draft the requirement and bind it to its source.
✓Attach an acceptance criterion to each hazard control in scope.
✓Flag a default state that no requirement specifies.
✓Report each standard clause the document has not answered yet.
Nothing enters the design record except by a named owner, inside the agreed boundaries.
Accepting that a hazard has been controlled.
Declaring a requirement out of scope.
Setting the risk a product is allowed to carry.
Changes to the document, the baseline or the rules.
Example output
One requirement, annotated
Our SOP and process documentation agent writes down how work is done; this one writes down what must be true of a thing before it is built, and below is one requirement as it leaves it.
Requirement draft · single itemIllustrative example
Requirement
Stated as
Drawn from
Acceptance criterion
Confidence
Held for
Default telemetry and its retention
One testable sentence, imperative
Hazard log, 4 August 2026
Bound to a named test case
Held unapproved
The named engineering owner
As receivedTaken from the hazard log and the clauses the regulations name; no paywalled standard is quoted here.
What the draft carriesHazard log entryInterview noteStandard clause
Why no approval hereTaking a requirement into the record is a judgement an owner makes.
ActionApproveAmendSend to quality review
What the score decidesBelow the configured threshold a draft gets a quality read before the owner sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every requirementFrom the finding that raised it
03Evidence
Where the requirement lands
The agent does not decide that a requirement is right. When one is approved and the build meets it exactly, the fault sits in the document, and the amendment is filed against the shipped release.
01Approved path
The requirement nobody wrote
Ask which side of the fork you are on. For ordinary software the document is private and discretionary. For a device — and a class I device counts once it is automated with computer software — it is the design input, and the duty attaches at drafting, not at build.
02Human review
What was checked, and not found
For ordinary software no statute was found that requires a specification to exist, to be complete, to be accurate or to be traceable. What binds instead is the contract: the statement of work, and the acceptance criteria written into it.
04Build an evidence trail
The requirement, the source it came from and the owner who approved it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A document-level coverage figure can read clean while safety and hazard controls carry most of the owner amendments. Nestack reports the amendment rate by requirement class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Safety and hazard controls
12.1%
3.7×
Review
Security and default states
8.6%
2.6×
Review
Privacy and retention rules
5.4%
1.7×
Watch
Routine functional requirements
2.3%
0.7×
Normal
Bar: amendment-rate lift vs. routine-requirement baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What an unwritten requirement costs
The loop shuts when the hazard that reached build unspecified is a regression case. That suite is what the next document drafted is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises on safety and hazard controls.
02Diagnose
The requirement nobody wrote, which is the hazard nobody controlled, is traced back through the drafting run until one cause remains.
03Improve
Every change goes out numbered, with the requirements that caused it attached.
04Verify
Nothing releases while one touched requirement case is still red.
05Learn
The case stays on, and the drafting rules are rewritten alongside it.
Learn → DetectThe return edge. The next document is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, requirement drafting, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Requirement discovery and automation-boundary work.
02Hazard, interview and standard sources.
03Finding-to-requirement and clause-coverage mapping.
04Requirement source intake.
05Source, clause and hazard binding.
06Coverage scoring and review routing.
07Owner approval workflow.
08Repository and tracker integration.
09Requirement and coverage cases.
10Guardrails and approval controls.
11Requirement-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne document, one releaseProductionProduction document controlAdvancedMultiple products / standards
Introduced at Pilot
Requirement drafting to your document rules✓✓✓
Named owner approval✓✓✓
Document-inventory baseline✓✓✓
Introduced at Production
Reporting by requirement class—✓✓
Quality review workflow in your systems—✓✓
Approved write-back—✓✓
Repository-and-tracker integration—✓✓
Introduced at Advanced
Multi-source requirement drafting——✓
Cross-release requirement packs——✓
Large document estates——✓
Multi-standard drafting controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, document volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live documents and the standard each answers to→Requirement-class capture and clause mappingWeek 1
02Representative hazard logs, interviews and clauses→Source binding, drafting logic and the coverage baselineWeek 2
03Your release calendar and the owners it names→Clause mapping, source binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Repository, tracker and hazard-log assessment, then integration setupWeek 2
05Requirements you would not want traced→Coverage cases and the evaluation roundWeek 4
06What no draft may assume→Coverage scoring, review routing, guardrails and release controlsWeek 3
07A named owner who approves the requirement→Release to the named owner, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Widths answer to the work and not to the grid, which is why a band sits beneath another in week five.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Requirement discovery, clause mapping and the automation boundaryW2Source integration and the document-inventory baselineW3Requirement drafting, coverage logic and release controlsW4Evaluation suite, coverage cases and failure-mode testingW5Repository integration, pilot documents and targeted correctionsW6One release cycle run under the engineering lead, then Agent Care handover
Reading the bandA bar spans the weeks its own work is named in, and week five carries two by design.
At the end of W6Once the requirement record validates, Agent Care assumes the agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Product AI agent
Build a spec and PRD drafting agent around the requirement your last release never wrote down.
Show us one document you ship against and the hazard log beside it. If what you ship is a device, a vehicle or a product sold into the EU, then an omission is not a gap in the document but a gap in the thing. A requirement nobody can state comes back as a finding.
