Embedded software verification runs on documents. A 500-page requirements specification holds hundreds of testable obligations, and turning them into structured, traceable unit, integration, and end-to-end tests is mechanical, tedious, and costs a senior engineer weeks. We built a platform that does the transcription and leaves your engineers the judgment — with human review before anything touches your ALM tool. It works the same way on automotive ECUs, medical devices, industrial controllers, avionics, and consumer firmware.
Deployed scale
The problem
Every verification organization we have worked with has the same three. Most tooling addresses one and pretends the other two do not exist.
GAP 01
Requirements live in PDFs, Word files, and spreadsheets. Tests have to live in a structured test management tool. The bridge between them is a human retyping a specification, one obligation at a time, for weeks — and getting it slightly wrong under deadline pressure.
GAP 02
Your repositories define real system behaviour — C and C++ sources, model-based design artifacts, RTOS components, interface definitions, harness files — with no corresponding coverage. Engineers trace code structure to test obligations by hand, and nobody can say what percentage of implemented behaviour is actually verified.
GAP 03
Thousands of existing tests use inconsistent structure, lack signal enrichment, miss pre-conditions, and carry no requirement traceability. Modernizing them by hand is arithmetically impossible, so the debt compounds and every audit surfaces it again.
Architecture
The knowledge base is built by parsing your actual source into signal entities and code chunks. Every generation path is grounded in it, which is why the output references things that exist rather than things a model remembers.
Every box above is a separately packaged subsystem with its own store, its own telemetry, and its own kill switch. Disabling any one of them leaves the core pipeline byte-for-byte unchanged.
Subsystems
Each subsystem is isolated and fail-open: a failure returns empty rather than crashing a sibling. That is what makes a staged rollout realistic instead of an all-or-nothing platform migration.
| Subsystem | What it does | Default |
|---|---|---|
| Requirements Pipeline | Reads specification documents, extracts testable requirements, matches signals, generates natural-language and executable tests, pushes approved tests to your ALM tool. | Core |
| Coverage Builder | Ingests model-based design repositories from source control or local filesystem, normalizes artifacts into code chunks, and generates executable tests per component with coverage-driven iteration. | On |
| Merge Monitor | Monitors merged pull requests across watched repositories, triages each for behavioral relevance, reconstructs testable intent from the diff, and routes through a scoping panel before dispatch. | Opt-in |
| Suite Modernizer | Reads legacy tests from existing suites, retrofits them to a golden structure with full signal enrichment, shows a field-level diff with editable steps, and writes approved updates back in place. | Opt-in |
| Conversational Q&A | Natural-language questions over signals, requirements, and code with three separate citation planes, repository-scoped filtering, multi-turn context, and a grounding critic that rejects unsupported answers. | Opt-in |
| Document Memory | Persistent semantic memory over requirement prose and code artifacts. Feeds every other subsystem with searchable, cited context so they share one view of the corpus. | On |
| Coverage Scanner | Proactive scan for uncovered signals and functions across every configuration combination, with optional model-assisted triage to rank what actually matters. | Opt-in |
| Requirements Authoring | Drafts formal "shall" requirements from engineering prose, with grounding validation against the knowledge base so authored requirements reference real system behavior. | Isolated |
The non-negotiable
This is the constraint that makes the system adoptable in a regulated verification organization. Generation is fast and cheap; a wrong test written silently into a test plan is neither. So every generated artifact stops in a review queue.
Approve, edit, or reject — every case, individually or in bulk, with the source requirement shown alongside it.
Field-level diffs on legacy updates — you see precisely what changes in an existing case before the write, never a wholesale replacement.
Traceability written at generation time — each case carries the requirement identifier and matched signals that produced it, so an audit answers itself.
A grounding critic runs first — output referencing a signal absent from the index is rejected before a reviewer ever sees it.
SOURCE REQUIREMENT
SRS-0912 · §4.2.1
"The controller shall disable the output stage when the input validity flag remains deasserted for more than 250 ms."
MATCHED SIGNALS · re-ranked
GENERATED CASE
pre device in run mode, output stage enabled
step deassert SensorInput_Valid
step hold for 300 ms
exp OutputEnable_Cmd deasserted within 250 ms
Who uses it
Stop retyping specifications. Review generated tests against the source requirement shown beside them, and spend the reclaimed time on edge cases the document never stated.
Generate coverage straight from behavioural models, interface definitions, and test harnesses, with optional requirement traceability attached to each generated case.
Populate a test plan in an afternoon instead of a quarter, or run a modernization pass across a legacy suite that has been untouchable for years.
Ask what a signal does, which configurations it appears in, or how two components interact — and get an answer with citations into signals, documents, and code.
Draft formal requirements from engineering prose with grounding validation, then run a coverage scan to see what the new requirement leaves untested.
Answer the question no one could answer before: what fraction of implemented behavior is actually verified, and where exactly is the gap?
No pre-normalization required. You point the pipeline at the corpus you already have.
Structured specifications
Formal requirement identifiers and section headings, as produced by requirements management tooling.
Narrative specifications
Prose using shall, must, and should language, with no formal identifiers — extracted, classified, and assigned traceable handles automatically.
FAQ
Only after a human approves. Every generated case lands in a review queue where an engineer approves, edits, or rejects it. Legacy updates additionally show a field-level diff against the existing case before the write. We consider unattended writes into a test plan a defect, not a feature.
Generation is grounded in an index built from your source, not from model recall. Requirements are matched against real signal entities with a re-ranking pass, and a grounding critic rejects any output referencing something absent from the index before a reviewer sees it. The model chooses among things that exist; it does not supply the vocabulary.
No — it removes the transcription and leaves the judgment. The scarce skill in verification is knowing which edge case the specification failed to state, not typing pre-conditions into a form. Teams that adopt this reallocate senior engineers from data entry to coverage analysis and gap resolution.
No. Most engagements start with one. Each subsystem is a separate package with its own store, telemetry, and kill switch, and each is fail-open — a failure returns empty rather than crashing a sibling. Disabling one leaves the core pipeline byte-for-byte unchanged, which is exactly the property that makes a staged rollout defensible to a change board.
Through your own internal AI gateway. All subsystems share a single transport that points at whatever inference endpoint your organization has already approved, so model access follows your existing policy rather than introducing a new vendor path. The embedding model runs resident and locally, which is why adding a subsystem costs no new model deployment.
In a technical briefing we will walk your actual document through the extraction path and show you what the matched signals and generated tests look like against your naming conventions — not a canned demo corpus.
Written on this
Playbook
Connecting an Agentic System to Azure DevOps
Tools split by consequence rather than by endpoint, a credential the sandbox never sees, and the two operations — pipeline triggers and stale approvals — that break a naive integration.
Verification
Requirements Traceability Without the Spreadsheet
The traceability matrix is accurate the day it is written and wrong within a sprint. Generating the link at authoring time is what makes it survive.
Verification
Line Coverage Is Not Verification Coverage
Most organisations can report line coverage to two decimals and cannot say which implemented behaviour nobody has written a test for. Those are different numbers.
Verification
Paying Down Legacy Test Debt Without an Engineer-Year
The assertions in a decade-old suite are usually fine. What is missing is everything around them — and retrofitting that is tractable in a way rewriting is not.