Connected-device manufacturer
The problem. Placing a product on the EU market means showing technical evidence per release, and the CRA’s reporting clock lands on releases you have already shipped.
You bring. The release tree or firmware build, the SBOMs your suppliers send, and an offline advisory snapshot.
You get. A release-backed evidence pack with CRA coverage and gaps stated plainly — an engineering gap assessment you can hand to whoever assesses you.
Still yours. The conformity judgment, with your assessor, notified body or counsel. SBOMFlow never files a report.
Prepare CRA evidence →
Product-security lead
The problem. Triage arrives without exploitation context, and the SBOM request from a customer lands in the middle of a sprint.
You bring. The release evidence, an advisory snapshot or an explicit network opt-in, and any supplier VEX you hold.
You get. Findings with confidence and provenance, exploitation signals as labelled inputs, VEX written from your decisions, and SBOM exports on demand.
Still yours. Every triage outcome, every VEX status, and what is allowed to leave the building.
Triage with context → Answer a questionnaire →
Release engineer
The problem. Either there is no release gate, or there is one nobody can explain when it blocks.
You bring. The release candidate, an optional policy you wrote, and the CI you already run.
You get. A deterministic, explainable gate decision with the reason recorded, a dry run to rehearse it, and native annotations on the pull or merge request.
Still yours. The policy. The gate is informational until you enforce one, and it never decides what is acceptable.
Gate a release in CI →
Engineering manager
The problem. “What changed since the last approved release, and did anyone actually look?” has no answer that survives a quarter.
You bring. Two analysed releases, or a local release store that keeps every release’s record.
You get. Drift between any two releases, a portfolio view across products, and an audit trail that names who decided what.
Still yours. Whether a change blocks a release. Drift is context; it never closes a finding by itself.
Track what changed → Sign off with accountability →
Reviewer or assurance professional
The problem. Evidence arrives as screenshots and spreadsheets that cannot be reproduced, and observed status is presented as if it had been reviewed.
You bring. An evidence bundle or assurance passport a manufacturer handed you.
You get. A static reviewer console that opens in a browser with nothing installed, every hash re-verified offline, and observed evidence kept apart from reviewed evidence.
Still yours. What you accept. A recorded approval attributes a decision to a person; it is not a statement that the decision was correct.
Read a bundle → Sign off with accountability →
AI-enabled product team
The problem. Models, services and agents ship alongside packages, and no release record holds them.
You bring. A release tree with model files or serving configuration — and, if you have one, your own declaration of the AI in the release.
You get. An AI inventory observed from bytes, a comparison with what you declared, and AI drift against the previous release, under the same review discipline as everything else.
Still yours. Resolving any disagreement between declared and observed. Nothing here runs, scores or certifies a model.
Understand AI change → AI Evidence status →
Design partner
The problem. You want to know whether this fits your release process before anyone commits to anything.
You bring. One representative release, run in your own controlled environment. Every artifact stays with you.
You get. A real evidence run on your build, a written list of what the v0.5.0 tester build does not yet do, and a structured place to say where it fits and where it does not.
Still yours. Whether to continue. This is an invitation, not a roster: no organisation is represented here as a customer.
The design-partner programme → Request tester access →
Researcher or educator
The problem. Studying or teaching release evidence needs a tool whose claims are testable and whose limits are written down.
You bring. Questions. The public documentation, a labelled synthetic sample run and the stated limitations are open to read.
You get. An evidence-first design with explicit reproducibility boundaries, uncertainty kept visible, and machine assistance separated from source-of-truth evidence.
Still yours. The methodology and the critique. We would rather discuss a limitation than have it discovered.
Inspect the sample run → Stated limitations → Write to us →
