Every firmware changechecked against your safety rules.
TraceGuard checks each commit against the rules your product was certified against and points at the exact lines that break one. It runs inside your own CI, with your own model: your code never leaves your infrastructure. Zero false positives across 40 hand-labelled commits.
Accepting three design partners · GitHub Action, CLI or GitHub App · Your runner, your model endpoint
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. For a certified drone or machine, that single line can mean re-testing, or a new conformity assessment under the Machinery Regulation that applies from 20 January 2027.
It is not rare. In twelve months, 16 ArduPilot commits changed how safety-relevant parameters are defined, including renames and unit changes. Read the report.
TraceGuard closes the gap at the commit, not at the release.
The model proposes. Code 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, by code
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 by pattern and escalated to human review instead of being silently obeyed.
What a verdict looks like
A real output from the evaluation repository. The ticket carries the same content: the rules breached, the reasoning, and the exact lines that triggered it.
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.
VIOLATION 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 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
| Measurement | Result |
|---|---|
| Main set — 30 hand-labelled firmware commits | 100% precision · 100% recall |
| 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 |
Your standard, compiled into evaluable rules.
You do not rewrite your safety documentation. TraceGuard ingests the PDF (a drone class-marking file, 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
Machinery Regulation, drone class requirements (EU 2019/945, EN 4709), IEC 61508, ISO 13849, the CRA: a different input document, not a different product.
Inside your pipeline. Your code stays with you.
No portal to adopt and no workflow to change. The check runs in your own CI, where the diff never leaves your infrastructure, or as a GitHub App that opens the finding in your board. Same engine, same verification.
Commit your rules
One Markdown file in the repository, one rule per heading, with the ID and severity from your risk assessment. Or let TraceGuard compile it from your PDF.
Add ten lines of workflow
The check runs on your runner on every push and pull request. The job needs read access to contents and nothing else. GitLab CI and Jenkins use the same file as a CLI.
Your model, your endpoint
Your own Anthropic account, Azure OpenAI, or a model you host with vLLM or Ollama. The diff goes there and nowhere else. Nothing is sent to TraceGuard.
The finding lands on the line
An annotation on the exact line of the diff, a job summary, and a JSON report sealed with SHA-256. The job fails only on a verified violation.
Two files you can read before they run
During the pilot the check ships as an action definition and a single readable JavaScript file that your security team can review line by line. Reports verify with one command, without us: traceguard verify-report.
Prefer tickets?
The GitHub App mode reads the diff with read-only access and opens the finding in your Jira or GitHub Issues, deduplicated on redelivery. It never closes a ticket on its own: confirming a safety finding is a human decision.
on: [push, pull_request] permissions: contents: read jobs: traceguard: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } - uses: ./.github/actions/traceguard with: api-key: ${{ secrets.ANTHROPIC_API_KEY }} paths: firmware/
Swap the provider for openai-compatible and a base-url to keep the diff on a model inside your network.
Built for a team that will ask hard questions.
| Control | Implementation |
|---|---|
| Where the code goes | In your CI: the diff is computed on your runner and sent only to the model endpoint you configure. Nothing reaches TraceGuard, and the job needs contents: read and nothing else. |
| Repository access (App mode) | 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. |
| Reports you can verify | Every run writes a JSON report sealed with a SHA-256 of its content. One command recomputes it, without us. |
| 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 (App mode) | 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 | In your CI: wherever your runner and your model live. App mode: application and database hosted in Frankfurt (eu-central), with diff content sent to our language-model provider for analysis; details on the data handling page. |
| Model training | Your code is never used to train models. |
No system is impenetrable. We will tell you which vectors are closed, which remain open, and why — before you ask.
Asked first, answered plainly.
Which regulations does it cover?
The ones in your rule document. Teams use it for drone class requirements (EU 2019/945), the Machinery Regulation that applies from 20 January 2027, functional-safety standards such as IEC 61508 or ISO 13849, and the Cyber Resilience Act. TraceGuard detects engineering changes that affect those requirements; conformity is assessed by you or a notified body, not by a tool.
Do you see or store our source code?
Not in the CI mode: the check runs on your runner and nothing reaches us. In the GitHub App mode the diff is processed in memory and only the evidence fragment that supports a finding is retained, for as long as you choose.
Can we use our own model?
Yes. The CI mode works with your own Anthropic account or with any server that speaks the OpenAI chat API, including a model you host yourself with vLLM, Ollama or Azure OpenAI.
What permissions does it need?
In the CI mode, read access to contents and nothing else. The GitHub App requests contents read-only and Issues read-write, scoped to the repositories you select. No organisation-wide access and no administration permissions. You can uninstall it at any time without telling us.
Is the analysis deterministic?
The verification layer is: rule existence and evidence matching are checked by code. The language model that proposes findings is not deterministic, and anyone claiming otherwise is overselling. Across 30 repeated runs on the most ambiguous cases, no verdict changed.
How many false alarms should we expect?
Zero across 40 hand-labelled commits, including ten the system had never seen. An engineer who receives one false alert mutes the tool within a week, so the goal is not to detect a lot — it is to never interrupt anyone without a reason.
Does it work with GitLab or Jenkins?
Yes, in the CI mode: the same file runs as a CLI anywhere with Node and git. The GitHub App mode is GitHub-only, with tickets in Jira or GitHub Issues. Tell us what else you use and we will give you a real date rather than a promise.
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. Prefer email? Write to diego.macias@traceguard.eu.