Engineering Evidence Graph™: connecting requirements, configuration and evidence

A verification matrix is the classic tool: one row per requirement, columns for method, event, evidence and status. It is indispensable, and it is two-dimensional. Real assurance questions are not.

“Is this requirement verified?” depends on the evidence, which depends on the configuration it was produced on, the procedure revision used, the anomaly raised during the test, the corrective action, the retest and the person who closed it. Each of those has its own history. A requirement may be verified by several activities, and one test may verify dozens of requirements.

Those are many-to-many, multi-step relationships. A graph holds them naturally, and lets a question travel in either direction: down from a need to its evidence, or up from a changed part to every conclusion that depended on it.

Bidirectional traceability is a property of these edges, not a separate report. Downward, a stakeholder need resolves to the evidence that satisfies it. Upward, a test result resolves to every requirement, review and certification package that relies on it, which is exactly the question a change raises.

Most traceability records say that a requirement is verified by a test. Fewer record which configuration the test ran on: requirement revision, hardware revision and serial number, software build, procedure revision, tool version and test environment.

In the Engineering Evidence Graph, the configuration is its own node, and every piece of evidence has a produced on relationship to it. A baseline under review is also a configuration. Comparing the two is what makes evidence validity computable rather than a matter of memory.

NASA's guidance on product verification already expects verification reports to record the version of the requirements and of the product that was verified. The graph turns that record into something that can be queried across thousands of results.

• Origin: the system of record, file or instrument a record came from, and when.
• Integrity: a content hash of raw evidence, so a later copy can be shown to be identical.
• Production context: procedure revision, facility, instrumentation and calibration status.
• Authorship: who created, edited and approved it. Links suggested by AI are marked as suggestions until an engineer accepts them.

Provenance is what lets a reviewer trust a status without re-deriving it, and what lets an auditor reconstruct why a decision was made.

Because evidence is linked to its configuration, a change to any configuration item can be followed to every piece of evidence produced on the old revision, then to every requirement that evidence closed, then to every review that relied on it.

That traversal is the basis of two AEAIP concepts: configuration-aware evidence validity and continuous engineering assurance.

Closure and approval are nodes too: who decided, in what role, under which authority, on what date and on the basis of which evidence. A requirement is not closed because a status field changed; it is closed because an authorised person approved a closure that points to current evidence.

AI in AEAIP can propose links, classify evidence and draft closure rationale. It cannot create an approval.

1. 01Subsystem: Flight Software
2. 02Requirement FSW-247: Transition from NOMINAL to SAFE mode within 2 s of a watchdog timeout, preserving the last 60 s of housekeeping telemetry.
3. 03Verification method: Test — hardware-in-the-loop (HIL)
4. 04HIL test: HIL campaign C3 on the flat-sat, fault-injection case FI-12
5. 05Test procedure: TP-FSW-118 Rev C · approved
6. 06Applicable configuration: FSW build 4.2.0 · OBC engineering model S/N 002 (Rev D) · HIL simulator v3.1
7. 07Test result: FAIL — transition 2.7 s; telemetry buffer truncated to 41 s
8. 08Anomaly: ANM-0219 (major) — telemetry flush blocked the mode-manager task
9. 09Corrective action: CA-0219 — flush moved to a low-priority task; FSW build 4.2.1
10. 10Retest status: HIL retest C3-R on build 4.2.1 · scheduled, not yet run
11. 11Verification closure: Open — awaiting retest evidence
12. 12Authorized review: Not started — closure needs the flight software lead and the chief engineer

Every step is a node; every arrow is a typed relationship. The chain shows not only that FSW-247 is not yet verified, but exactly why, what has been done about it and who still has to act.

Requirements management and ALM tools already provide traceability, verification tracking and change flagging, often called suspect links. PLM systems manage configuration and product structure. Test and quality systems hold results and nonconformances.

The Engineering Evidence Graph is not intended to replace them. It is intended to connect their records into one assurance view, with configuration-aware validity across tool boundaries. No integrations are implemented today; they are on the roadmap.