V&V Programme Intelligence

Programme state.
Continuously computed.

Live graph of every artefact, link, and dependency. Change impact propagates automatically. Gate readiness is always current.

LIVE · TYPE 26 FRIGATE
MAETRIX GRAPH ENGINE · CONSTELLATION MODE
ARTEFACTS
LINKS
GAPS DETECTED
APPROVED
SUSPECT LINKS
GATE READINESS
Where V&V programmes fail

Three operational failures that compound into programme risk.

None require a gate review to expose. They require continuous visibility that current tooling does not provide.

01

A requirement changes. Downstream test coverage is now unknown.

Engineers manually trace what needs retesting, if they trace it at all. Gaps surface at CDR, not during development. By then rework is measured in schedule weeks.

02

Gate readiness is assembled in the week before the review.

No continuous view of approved vs. open artefacts or traceability coverage. CDR readiness is a manually compiled snapshot that is already out of date when it reaches the board.

03

Traceability matrices fall behind the moment a change is committed.

RTMs in spreadsheets or DOORS exports are not self-updating. The record presented at review reflects the programme as it was, not as it is.

04

No single view across contractors and sub-contractors.

Each contractor holds their own DOORS module. Nobody has a consolidated view of programme state across the supply chain. Integration gaps are discovered at system-level review, not before.

05

Safety artefacts are approved without linked evidence.

Under schedule pressure, approvals go through without test evidence attached. No system flags it. The deficiency is invisible until a SQEP assessor or gate reviewer checks the link. By that point it is already on the critical path.

06

Change requests are raised but not propagated.

A CR is approved and the source artefact is updated. The downstream tests, design outputs, and evidence documents that now need re-verification are not automatically identified. Engineers find out when they check manually, or not at all.

The platform

A continuously updated graph of every artefact, link, and gap.

Every change propagates immediately to connected artefacts and the gate readiness score.

GRAPH ENGINE

Live programme graph

Every artefact is a node. Every dependency, verification link, and evidence chain is an edge. State changes propagate in real time. No manual refresh. No stale snapshots.

CHANGE IMPACT

Downstream impact before the change is committed

Select any node and describe a proposed change. MAETRIX returns severity-coded findings for every affected downstream artefact before any edit is made to the programme record.

AI AGENTS

Four intelligence agents, each exhaustive

Gap Analysis, Requirement Quality, DEF STAN / JSP clause mapping, and GSN assurance case generation. Each covers the full programme. Results on first run.

GATE READINESS

Continuously computed gate readiness score

Approved artefact coverage, open gaps, safety nodes without evidence, and suspect links factored into a single score against your target gate. Updated on every state change.

Defence context

The structural controls UK defence V&V requires.

Not optional features. Requirements your SQEP assessor will check. Built into the platform, not into a process document.

DEF STAN 00-056
DEF STAN 00-055
JSP 520
JSP 440
DEF STAN 05-138

Second-person approval

The artefact creator cannot approve their own work. Enforced by the system, not by process discipline. Cannot be bypassed regardless of role or seniority.

Suspect link detection

When a node changes, every connected link is automatically flagged suspect. Engineers must re-confirm each one against the updated content before it is trusted again. Unconfirmed links are visible to the whole team.

Mandatory transition rationale

Moving any artefact to In Review or Approved requires a written justification. The rationale is stored in version history with a full snapshot. Not just visible on screen. It is part of the permanent record.

Gate baseline locking

A locked baseline is a point-in-time snapshot of the full programme graph: every node, every link, every maturity state. The evidence artefact for CDR, PDR, or SRR. Irrecoverable by design.

Change request workflow

Once frozen, an artefact cannot be edited without a raised and approved change request. Every unlock is traced to its CR reference. The record is complete from start to finish.

Immutable audit log

Every state change, approval, and rationale is cryptographically chained. When the gate comes, the record is already there. It was written as the programme ran.

DOORS + MAETRIX

DOORS stores requirements. MAETRIX computes programme state.

Most programmes are contractually locked into DOORS. The rest of the programme state lives in spreadsheets, shared drives, and email threads. MAETRIX runs above all of it, adding the intelligence layer none of them were designed to provide.

Capability IBM DOORS Next MAETRIX
Requirements authoring and module management
Suspect link detection on node change
Configuration baseline snapshots
Second-person approval workflow
Live cross-programme graph with gap visualisation
Automated change impact analysis across all downstream artefacts
Continuously computed gate readiness score
AI gap analysis across full programme
DEF STAN / JSP clause mapping per requirement
GSN assurance case generation
Immutable audit log with cryptographic chain
Register interest

No commitment. We'll respond within 48 hours.