The Requirements Agent

What it looks for

Three defect classes, all of them structural rather than semantic, and all of them things a person could find given a week they do not have.

• Unverified requirements — a requirement with no test, inspection or analysis linked to it. The most common gap, and the one that surfaces at the worst possible moment, which is a customer audit.
• Orphaned verification — a test that verifies nothing, usually because the requirement it covered was reworded and re-created rather than revised. The test still runs; it no longer proves anything anyone asked for.
• Contradiction — two requirements that cannot both be satisfied. An operating temperature range from one document and a component derating rule from another that excludes its upper end. This is the class that needs a model rather than a query.

How it reads a requirement

Requirements arrive as prose, and prose is where the ambiguity lives. The agent's first job is to identify what a requirement actually constrains: a characteristic, a limit, a condition, and whether the statement is testable at all.

A requirement that cannot be verified is flagged as such rather than as verified. *The enclosure shall be robust* has no test that can pass or fail it, and the honest output is that this requirement needs rewriting — not a proposed test that pretends to cover it.

Where a requirement does constrain something typed, the agent checks it against the characteristics on the relevant specifications, which is how contradiction detection works at all. Two prose statements cannot be compared; two limits on the same characteristic can.

Every finding cites the requirement text, the document and revision it came from, and the specific characteristic or test it relates to. A finding with no citation is not shown, because an unverifiable claim about verification is worse than silence.

The failure it prevents

A programme reaches design review with a requirements matrix showing full coverage. Every row has a verification method. The review passes.

During qualification, two tests fail in a way that reveals a third requirement was never actually tested — its verification column named a test that had been superseded eighteen months earlier and no longer exercised that condition. The matrix said covered because somebody typed *covered*.

A coverage claim maintained by hand degrades silently, because nothing about the document changes when the thing it references does. Resolving coverage from actual links rather than from typed text is the difference, and the agent is what makes that resolution continuous instead of an exercise before a review.

How it meets the rest of the product

Requirements are objects with revisions and relationships, so coverage is a resolvable fact rather than a maintained assertion. The agent works on that graph; without it there would be nothing to analyse and the agent would be reading spreadsheets.

Findings arrive as tasks in the work queue, scoped to the programme and visible to whoever owns it. They are not notifications and they do not expire — a gap that nobody has addressed is still a gap in March.

Coverage is rendered as a resolution rather than a report. Opening a programme's traceability view runs the same query the agent runs, so what a reviewer sees in a design review and what the agent found overnight cannot disagree with each other.

Evidence links reach quality records and test reports, which is what separates a verification link from a verification. A link with no results behind it is shown as an open claim, and that distinction is the one an auditor examines first.

The agent runs at Observe and Recommend tiers only. It reports gaps and proposes links for review; it does not create a verification link, mark a requirement covered, or alter a requirement's text. A traceability matrix an agent can edit is a traceability matrix nobody can trust.

How it meets your ERP

Requirements do not belong in an ERP and the agent has nothing to say to one directly. The seam is indirect and worth stating: requirements produce critical characteristics, characteristics produce inspection plans, and inspection plans are what reach an ERP or MES.

So an unverified requirement is frequently an uninspected characteristic, and the agent's finding is the earliest possible warning of a control that will be missing on the line. That chain is the reason this analysis matters operationally rather than only at audit.

Where an ERP or MES inspection result read exists, the agent can distinguish a verification link that exists on paper from one with results behind it — which is a materially different question and the one an auditor actually asks.

Where the boundary is

It never closes a gap. It does not create verification links, does not mark requirements as covered and does not edit requirement text. Every output is a finding with citations for a person to act on.

It also does not write requirements. Generating requirement text from a customer document is deliberately not offered, because a requirement nobody deliberately wrote is a requirement nobody owns, and ownership is most of what a requirement is.