Running a test is rarely the difficult part in safety-relevant engineering — applying agentic testing to keep requirements, specifications, test cases, and evidence consistent while the project changes is. FEV.io TRACK helps teams manage that work along the V-model by deriving structured requirements from existing documents, drafting test specifications, and keeping the links between each level visible and up to date.

Testing is not the expensive part. Keeping everything aligned is.

Ask an engineering team where the verification budget goes and few will say “running tests.” Most of the effort sits between the artefacts.

A customer specification arrives as a PDF. Requirements sit in one tool, test specifications in another, and sometimes in spreadsheets nobody is proud of. Test scripts live beside the code. Logs come from the test bench. Each artefact may be sound on its own. The weak point is the set of links between them, usually maintained by hand by someone already short on time.

Then a system requirement changes. Or a hardware specification is revised. Or a supplier delivers a new interface definition. And the questions start:

• Which test cases are now invalid?

• Does the specification still match the implementation?

• Is the evidence complete enough for the next review, the next audit, the next release gate?

• Where did this particular test case come from in the first place, and who decided it was sufficient?

The questions themselves are straightforward. Answering them is not. Someone has to reopen old documents, reconstruct decisions and check links that may already be stale. If the team finds the impact late, rework piles up just before approval, when there is least room left in the schedule.

TRACK focuses on that awkward middle. It helps the team keep the verification chain intact as requirements, interfaces and hardware change.

What Agentic Testing Means in TRACK

“Agentic AI” has become a catch-all term, so it helps to spell out what TRACK actually does.

TRACK does not send one prompt to one model and return whatever comes back. Several focused agents split the work. They validate the request, retrieve approved passages, rank the evidence, draft the result and check it against the sources. If the evidence is weak, the system revises the query and tries again before a person sees the draft.

That extra check matters. A one-step response can sound convincing even when the documents do not support it. TRACK is expected to stop and say when the evidence is missing. In safety work, “the source documents disagree” is a useful result. A polished guess is not.

What agentic does not mean in TRACK:

• It does not mean the system releases anything. Every generated artefact is a draft.

• It does not mean the system executes tests. Execution stays in your environment, with your people.

• It does not mean autonomous decision-making about safety. The AI proposes; the responsible expert disposes.

Expert-in-the-loop is part of the architecture. TRACK is designed so that approval remains a human responsibility and cannot be hidden inside an automated workflow.

Design downwards: the generation cascade

TRACK first works down the left side of the V. It drafts each level from the one above and attaches a citation to the source passage.

01 · Input — what already exists

The starting point is whatever the team already has: customer specifications, legacy documents, extracts from standards, supplier data and old test procedures. TRACK does not require a neatly curated dataset before work can begin.

02 · Generated — requirements

Atomic, uniquely identified, verifiable. Each requirement names the source passage it was derived from, down to section and page. Where the source is ambiguous, the requirement is flagged rather than smoothed over.

03 · Generated — test case specification

Preconditions, steps, expected results and acceptance criteria per requirement, including negative and boundary cases. Coverage is expressed against requirement IDs, so gaps are visible instead of implied.

04 · Generated — test scripts and unit tests

Executable artefacts for the target framework and the HIL/SIL environment, ready to be reviewed and run in the existing pipeline.

Every step produces a draft for review. Engineers no longer start from an empty page, and they can see where each proposed item came from. That saves time without hiding the reasoning.

Design downwards: the generation cascade

The second half of the job runs horizontally. A requirement on the left arm is linked to the test that verifies it on the right arm — in both directions.

A one-way link answers “which test verifies this requirement?” A link in both directions answers the question reviewers usually care about more: “why does this test exist, and what changes if the requirement moves?”

Concretely, a trace in TRACK looks like a chain of identified objects rather than a document reference:

REQUIREMENT REQ-042 → CODE MODULE brake_ctrl.c → FUNCTIONAL TEST TC-118 → TEST LOG RUN #4711 → SOURCE SRS §4.2.1, p. 37

Each hop can be followed in either direction. The final link back to the source is mandatory, and much of the architecture exists to enforce that rule.

Source-to-evidence: the AI may only state what is in the document

Impact analysis: the question that used to take days

When a requirement, interface or hardware specification changes, TRACK follows the dependency graph and identifies the affected tests, scripts and evidence. It also checks indirect dependencies that are easy to overlook in a manual review. 

Practically, this shows up in three places: 

• Impact lists. Which artefacts are affected, ranked by how much review effort they are likely to need. 

• Notifications. The engineers who own affected artefacts are informed, rather than finding out at the next review. 

• What-if analysis. Teams can examine the consequences of a planned change before committing it, turning change-request discussions into evidence-based decisions. 

Different roles need different views of the same change. Engineers need the affected objects. Reviewers need the change and its reason. Assessors need the trace and sources. Project managers need an estimate of the review effort still open. 

What TRACK reads

The system is designed around the artefacts engineering teams already produce, not around a format they would have to adopt.

Category	Formats and sources
Structured	CSV, JSON, XML, YAML, database exports (SQL dumps)
Semi-structured	DOCX, XLSX, PPTX, PDF — including tables and complex formatting — plus HTML
Unstructured	Plain text, Markdown, image files, scans (PDFs without a text layer)
Engineering data	Source code (C, C++, Python), requirements exports from DOORS, Polarion, codebeamer, and HIL / measurement logs

For a first evaluation, the practical minimum is modest: requirements as CSV (preferred) or PDF, and the associated documents grouped by function. Starting with a representative subset rather than the entire archive is usually faster and more informative.

The technology stack

TRACK is a system, not a model wrapped in a user interface. The reference architecture below is adjusted for each deployment. Approved base images, identity providers, network rules and available GPUs all affect the final setup.

Application and interface layer

A web front end built on Next.js, delivering the role-based dashboards, the trace explorer and the review workflows.

Service layer

Python (≥ 3.13) services on FastAPI, with Pydantic for strict schema validation at every boundary. Typed contracts are not cosmetic here: they are what stops a malformed generated artefact from propagating into the trace graph.

Agent orchestration

LangGraph and LangChain coordinate the agent workflow. Separate stages handle validation, conversation context, retrieval, re-ranking, drafting, evaluation and query refinement. Each stage can be inspected on its own.

Retrieval, vectors and knowledge graph

Weaviate handles semantic retrieval across the document set. A knowledge graph records how requirements, architecture elements, tests and evidence relate in the relevant domain. Retrieval can therefore follow engineering relationships, not only similar wording. The graph also limits which source objects may support a generated statement.

Data and object storage

PostgreSQL for structured project data, trace links and audit history; MinIO for document and artefact object storage, including original files so that every citation can be resolved back to the source document as delivered.

Model serving

LlamaSwap and llama.cpp for local inference, GPU-accelerated (H100-class hardware for larger deployments, smaller configurations for pilots). Model choice is deliberately pluggable — open-weight models for fully sovereign operation, and where a customer permits it, hosted models for specific tasks.

Integration layer

MCP (Model Context Protocol) connectors link TRACK to the surrounding engineering stack: Jira, Azure DevOps, Git, and requirements exports from DOORS, Polarion or codebeamer. TRACK does not replace that toolchain. Your tools continue to hold the objects; TRACK maintains the links between them, reducing the manual coordination work that usually sits with engineers.

Deployment and data sovereignty

For many customers, capability is not the first question. Data control is.

TRACK is built to run on premises, inside the customer’s infrastructure. Specifications, source code, intellectual property and sensitive project data can remain within the customer perimeter. A controlled hosted variant is possible where security policy allows it, but the default design priority is data sovereignty.

Related properties that tend to come up in the same meeting:

• No training on customer data. Customer artefacts are used to answer and to generate within a project, not to improve a shared model.

• Complete audit history. Every change is attributable to author, timestamp and source.

• Project-level isolation. Separation between projects and programmes is enforced at the data layer, not by convention.
• Restricted or air-gapped environments. Operation without external network access is a supported deployment pattern, not a workaround.

Standards context

Verification and validation in these industries is not a matter of taste, and the relevant reference frameworks differ by domain:

• Rail: EN 50126 / EN 50128 / EN 50129, across SIL 1 to SIL 4

• Automotive: ISO 26262, Automotive SPICE 4.0, ISO/SAE 21434

• Space and aviation: ECSS-based verification and audit requirements

One distinction is important: TRACK supports the production of a standards-conformant chain of evidence. It is not a certification tool and does not certify products or processes. Certification still applies to the customer’s product and process. TRACK contributes a closed, source-cited chain from requirement to test to evidence, making assessment preparation more transparent and less manual.

Tool qualification questions (where they apply) are handled per project, with the customer’s assessor involved early rather than late.

Where the AI stops

The limits need to be plain. In a safety review, exaggerated claims can end the conversation before the technical discussion starts.

• The AI drafts. It does not approve.

• The AI links and analyses. It does not decide what is safe.

• The AI executes nothing. Test execution stays in the customer’s environment.

• The AI reports uncertainty. Incomplete or contradictory source material produces a flag, not a guess.

• Output quality tracks input quality, and TRACK measures and reports that rather than hiding it.

These are deliberate boundaries, not missing features. They keep responsibility with the people who sign off the work.

What it looks like in practice

Day to day, TRACK is useful in fairly unglamorous ways:

• Less manual effort when something changes. The affected artefacts are identified in minutes rather than reconstructed over days.

• Reviews that start from something. Reviewers spend their time judging a cited draft instead of assembling context.

• Audit preparation as a by-product. The evidence chain is produced as work happens, rather than compiled retrospectively under deadline.

• Knowledge that survives staffing changes. Legacy specifications and test logic remain queryable after the colleagues who wrote them have moved on or retired.

The clearest gains so far are in drafting functional test cases and updating artefacts after a change. That is where automation earns its place: it takes on the repetitive coordination work while engineers keep the judgement calls.

One core, several domains

Rail, automotive, aviation, space and defence share the same basic traceability problem, but they do not use the same artefacts or standards. TRACK therefore keeps one agentic core and uses domain-specific configurations for document logic, standards mapping and evidence templates.

Frequently asked questions

Does TRACK replace our requirements management tools?

No. DOORS, Polarion, codebeamer, Jira and Azure DevOps continue to hold the objects. TRACK connects them via MCP interfaces and maintains the links, the derivation and the evidence chain between them.

Can we use this if AI is not permitted in our safety-relevant process?

That restriction is usually about AI making or approving safety-relevant decisions — which TRACK deliberately does not do. It produces drafts and links; approval and execution remain with your experts. The right sequence is to involve your safety and quality functions from the first conversation rather than after a pilot.

What happens if the AI hallucinates?

The architecture restricts generated statements to what the approved sources support, with a citation attached. Unsupported output is a failure state and is surfaced as such. Contradictory or missing source material is reported rather than filled in.

Does our data leave our network?

Not in the default deployment. TRACK is built to run on premises, and operation in restricted or air-gapped environments is a supported pattern.

How much of our documentation do we need before starting?

Less than teams expect. Requirements as CSV or PDF plus the associated documents grouped by function are enough for a meaningful first evaluation. A representative subset beats a complete archive for a first pass.

Does this mean fewer test engineers?

It means test engineers spend less time on transcription, link maintenance and documentation assembly. The judgement — what is sufficient, what is safe, what gets released — is the part the system is explicitly designed not to touch.