Trace each generated assertion back to the requirement it came from, mark what was read out of the code instead, and hold the suite for the quality engineer who signs the report.
A suite is read in, and the requirements it was meant to trace to are read in beside it.
02
A test is generated, and the record says whether it came from a requirement or from the code.
Reason
03
An assertion is written, and its expected value is marked as observed behaviour or as specified.
04
A fixture is built from the interface contract rather than from the code that happens to call it.
05
An existing human-written test is improved, and it ships only if a mechanical filter shows it better.
Decide
06
A module carries an open defect, and coverage over it is reported as a measurement, not as evidence.
07
An assertion is changed, and the prior expected value, the new one and the reason are written down.
Out
08
A test would be deleted or weakened, and the change is held for a named quality engineer instead.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Generation, tracing and the assertion record belong to the agent. Approval belongs to a named quality engineer, who signs the test report and answers for it.
Example workflow
One test, requirement to report
AgentHuman
1Suite and source receivedRepository, test runner, coverage report or requirement tracker
2Basis assembledThe requirement, the interface contract, the existing tests and the defects still open
3Test draftedThe assertion, the fixture, the trace it claims and confidence
4Controls appliedTrace checks, derivation marking, fixture-source rules and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is merged at any of them — the agent is drafting tests, and the quality lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the quality engineer to approve.
Low confidence
Adds a test-engineering read first.
Quality approval
The test is held with its trace, its derivation mark and the confidence.
Approve · Amend · Send to test engineering
Approved — merged into the suite▼
6Repository and runner updatedOnly where write access and review policy allow it
7Outcome evaluatedAmendment rate, trace outcomes, defects caught and corrections after release
Amendments
Each quality-engineer amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Signing a test report into a regulatory submission.
Deleting or disabling a failing test.
Deciding that observed behaviour is correct behaviour.
Declaring a coverage objective satisfied.
Automation boundaryAgent acts unaided
✓Draft tests from the requirement and the contract.
✓Mark which assertions were derived from the code itself.
✓Record what the assertion expected before the agent changed it.
✓Report coverage as a measurement and hold the suite for review.
Nothing reaches the suite except by a named engineer, inside the agreed boundaries.
Approving a suite as adequate for release.
Writing or amending the requirement itself.
Judging a mutant equivalent and dismissing it.
Changes to authoring policy or approval thresholds.
Example output
One generated test, annotated
For most teams this is a build artefact; where a submission carries a printed name it is a record with a signer. Below is one test as the agent leaves it.
Test-generation output · single assertionIllustrative example
Unit under test
Assertion written
Expected value
Derived from
Confidence
Held for
Dose calculator
Asserts the value the current build returns
Observed, not specified
The source code
88%
The named quality engineer, by name
As receivedTaken from the unit and the run that exercised it — the requirement it should trace to is absent.
What the record holdsInterface contractObserved return valueOpen defect record
Why this is flaggedIt records what the code does, not what the requirement demanded.
ActionApproveAmendSend to test engineering
What the score decidesBelow the configured threshold a test picks up a test-engineering read before approval.
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
Each generated testFrom the code and the requirement
03Generation
Draft from the requirement
Work from the requirement and the interface contract, and mark what could only have been read out of the implementation.
01Approved path
The fixture became the spec
Pick a permissive fixture because it is convenient, and the run that follows certifies the assumption instead of the code.
02Human review
What was looked for, and not found
No statute, no regulation and no guidance found in this work sets a coverage percentage, requires a test to be meaningful, or forbids deleting a failing one. The gap between a test failing and a record that it failed is unlegislated, and that is where the agent sits.
04Build an evidence trail
The test, the requirement it traces to and the engineer 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 suite-level oracle figure can read clean while a couple of code classes carry nearly all of the amendments. Nestack reports the engineer-amendment rate by code class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Code with an open defect
13.5%
3.7×
Review
Untraced legacy modules
9.6%
2.6×
Review
Concurrency and timing paths
6.0%
1.6×
Watch
Stable well-specified modules
2.7%
0.7×
Normal
Bar: engineer-amendment-rate lift vs. stable-module baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a wildcard costs later
The loop shuts when the assertion that froze a defect is a regression case. That suite is what the next suite generated is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises in one code class.
02Diagnose
The wildcard in the twenty-first field, written because it was convenient, is worked back until one cause is left.
03Improve
Every change goes out numbered, with the tests that caused it attached.
04Verify
Nothing releases while one touched assertion case is still red.
05Learn
The case stays on, and the authoring rules are rewritten alongside it.
Learn → DetectThe return edge. The next suite generated 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, test generation, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Test-workflow discovery and automation-boundary work.
02Runner, coverage and forge assessment.
03Requirement-tracing and fixture-source rule mapping.
04Suite and runner ingestion.
05Generation logic and trace binding.
06Confidence scoring and flag routing.
07Quality approval workflow.
08Repository and runner integration.
09Assertion and traceability cases.
10Guardrails and generation controls.
11Assertion-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 repository, one suiteProductionProduction repositoriesAdvancedMultiple repositories / teams
Introduced at Pilot
Generation to your requirements✓✓✓
Named quality approval✓✓✓
Suite-inventory baseline✓✓✓
Introduced at Production
Reporting by assertion class—✓✓
Approval workflow in your systems—✓✓
Approved write-back—✓✓
Runner-and-repository integration—✓✓
Introduced at Advanced
Multi-language generation rules——✓
Multi-stage quality approvals——✓
Large suite volume——✓
Multi-suite generation controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, suite 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 suites and the requirements they trace to→Suite ingestion and trace mappingWeek 1
02Representative modules and their contracts→Generation baseline, contract binding and the trace matrixWeek 2
03Your assertion and fixture policy→Requirement-tracing and fixture-source rule mappingWeek 1
04Access to relevant APIs, feeds or exports→Runner, coverage and repository assessment, then integration setupWeek 2
05Assertions you would not want submitted→Traceability cases and the evaluation roundWeek 4
06What no test may certify→Confidence scoring, flag routing, guardrails and approval controlsWeek 3
07A named quality engineer to approve tests→Quality approval workflow, 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 follow the work, not the grid, which is why one band is drawn beneath another in the fifth week.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Test workflow discovery, traceability mapping and the automation boundaryW2Source integration and the generation baselineW3Generation workflow, confidence logic and approval controlsW4Evaluation suite, traceability cases and failure-mode testingW5Repository integration, pilot suites and targeted correctionsW6One verification cycle run under the quality owner, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6Once the assertion record validates, Agent Care assumes the agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a test-writing agent around the requirement your last suite never traced to.
Show us one suite, the requirements behind it and who signs the test report. If your suite was written from the code, then it can tell you the behaviour changed and it cannot tell you the behaviour was ever right.
