Deterministic Cyber Resilience Act (CRA) compliance for firmware.
Audit every Git commit against EU regulations in under four seconds. Zero false positives. No new dashboards to learn.
Now accepting pilot partners. Read-only GitHub access, no code stored beyond the evidence you choose to retain.
Engineering moves at commit speed. Compliance moves at document speed.
An engineer raises a geofence ceiling from 120 to 150 metres on a Tuesday. The change is reasonable and the reason is sound. Nobody in that pull request knows the constant is written into a risk assessment, or that changing it invalidates a test signed off eight months ago.
Today that surfaces at the next quality review, weeks later. Sometimes it surfaces in an audit. Sometimes it does not surface at all. Under the Cyber Resilience Act, a substantial modification can require a new conformity assessment — and the modification is a single line in a header file.
TraceGuard closes the gap at the commit, not at the release.
The model proposes. A deterministic layer decides.
Language models are useful for reading a diff against regulatory prose. They are not trustworthy as the final authority on a compliance verdict, and no amount of prompting changes that. TraceGuard separates the two roles explicitly.
Hypotheses, structured
The model returns findings in a schema: rule ID, file path, a literal quotation from the diff, the reasoning, and a recommended action. No free-text parsing anywhere in the pipeline.
Verification, deterministic
Every finding is then checked by code, not by a model. The cited rule must exist in your document. The file must be part of the change. The quoted evidence must appear literally in the diff, line by line. Anything that fails is discarded and logged as discarded.
Severity comes from your document
Never from the model. The verdict is computed by the engine from the findings that survive verification — the model never declares it.
Injection-aware
Diff content and commit messages are treated as data under audit, never as instructions. An attempt to steer the analyser from inside a code comment is detected deterministically and escalated to human review instead of being silently obeyed.
What a verdict looks like
VIOLATION 787eeb1 drone-firmware-demo · main SR-01 SR-08 The change raises the maximum operating altitude ceiling from 120 m to 150 m, exceeding the certified limit and breaching the altitude ceiling rule; the associated behavioural change also requires re-running the safety test suite. evidence firmware/include/safety_params.h -#define GEOFENCE_MAX_ALTITUDE_M 120 +#define GEOFENCE_MAX_ALTITUDE_M 150 7.8 s · €0.018 · 3.1k / 573 tok · ticket SAFE-284
Measured, not asserted
Every number on this page comes from an evaluation harness that ships with the system and can be re-run on demand.
| Measurement | Result |
|---|---|
| Main set — 30 hand-labelled firmware commits | 100% precision, 100% recall, zero false positives |
| Holdout set — 10 commits the system had never seen | 100% precision, 100% recall |
| Verdict stability — 10 ambiguous cases × 3 runs | No verdict changed across 30 runs |
| Rule compiler vs. CRA Annex I, hand-written ground truth | 94.4% recall, 77.8% precision, zero fabricated citations across 175 rules |
Your standard, compiled into evaluable rules.
You do not rewrite your safety documentation. TraceGuard ingests the PDF — a CRA annex, an internal safety manual, an ISO 13849 risk assessment — and proposes machine-evaluable rules with thresholds, severities and indexing terms.
Every rule cites its source
A proposed rule that cannot be quoted literally from your document is discarded automatically. Across 175 rules extracted from the CRA, zero fabricated citations.
Paperwork is separated, not ignored
Obligations no diff can breach — CE marking, retention periods, notified bodies — are listed in an appendix rather than fired at your engineers on every commit.
Your team approves before anything runs
Proposed rules are reviewed and corrected by your quality team. Nothing reaches production until they sign it off.
Any standard, same engine
CRA today. IEC 61508, ISO 13849, EN 4709, FDA guidance: a different input document, not a different product.
Nothing new for your engineers to learn.
There is no portal to log into, no tool to adopt, no workflow to change. Findings arrive where your team already works: as a ticket in your own Jira project or your own GitHub Issues, with the rule, the exact line and the recommended action.
-
Install a GitHub App on one repository
Read-only access to contents, write access to issues. Nothing else. Not organisation-wide — only the repositories you select. Uninstallable at any time, without telling us.
-
A push arrives, signed
The webhook signature is verified over the raw bytes with HMAC-SHA256. The request is acknowledged with 202 in milliseconds; analysis runs asynchronously and never blocks your pipeline.
-
The change is filtered, then audited
Binaries, lockfiles and generated artefacts are dropped before anything is analysed. A change too large for a reliable verdict produces no verdict — it produces a ticket asking for human review.
-
A ticket appears in your board
Severity taken from your document. Deduplicated, including on webhook redelivery. If a later commit removes the offending line, the ticket is annotated and labelled — never closed automatically, because confirming a safety finding is a human decision an auditor needs to trace.
Built for a team that will ask hard questions.
| Control | Implementation |
|---|---|
| Repository access | GitHub App with per-installation tokens issued by GitHub. Contents read-only, Issues read-write, scoped to the repositories you select. Isolation is enforced by GitHub, not by our code. |
| Credential storage | Customer tokens encrypted with AES-256-GCM before they reach the database, with a per-secret derived key. The database never sees plaintext. |
| Tenant isolation | Row-level security enabled with no policies on every operational table. Only the server's service role can reach them. Every record carries its owner. |
| Source code handling | Diffs are processed in memory. Only the evidence fragment supporting a finding is retained, because an audit trail without evidence is worthless. |
| Retention | Configurable. After the window you choose, evidence is deleted and the audit trail — verdicts, rules cited, timestamps — survives without it. |
| Offboarding | Your full analysis history is exported to you, then deleted in a single cascading transaction. We will show you the exact SQL that does it. |
| Data residency | Frankfurt (eu-central). Processing within the EU. |
| Model training | Your code is never used to train models. |
No system is impenetrable, and we will not tell you otherwise. We will tell you which vectors are closed, which remain open, and why — before you ask.
A technical walkthrough, not a sales call.
Thirty minutes. You describe how your team finds out today that a change invalidated a test or a document. We compile one of your safety documents into proposed rules and send them back for your team to correct. That commits you to nothing and takes us a day.
Pilots are free and run for two weeks. We would rather find out the product is wrong from a team that tells us than announce a launch to nobody.