Building in the open
AI Evidence
An SBOM describes software components. An AI-enabled product also ships models, external services, agents and the evaluations meant to justify them. SBOMFlow is bringing that evidence into the same release record, review queue, gate and history as the rest of the product — under one rule: machine assistance may explain, but it is never the source of truth.
Straight status, up front: this is a capability in development, not a finished product surface. What an operator can run in v0.5.0 is labelled available; every other piece of the chain is labelled exactly as far along as it is. Nothing here runs a model, scores one, or watches one at runtime.
The boundary
They are the structure of this page, not a footnote to it. Every capability below either keeps to them or is not listed.
SBOMFlow’s own evidence path is deterministic and makes no AI calls. Where an AI-assisted tool contributes — today, a sealed scan from an external AI-assisted scanner that you import from local disk — every result is recorded as an observation that needs human review, never as a SBOMFlow finding and never as a gate input.
What a supplier or a manifest declares is recorded as a declaration. What the scan observed in the release tree is recorded as an observation. The two are kept apart, compared where they can be compared, and a disagreement is shown to you and never resolved for you.
AI evidence enters the same review queue and the same explainable gate as everything else. Every AI-aware gate control is off until an operator turns it on; until then the evidence is informational, and a control that could not run blocks with its reason rather than passing.
SBOMFlow never runs, loads or evaluates a model, never assesses its behaviour, quality or safety, and never reduces evaluation results to a score. An evaluation is recorded exactly as it was supplied, with who supplied it. An inventory cut short by a resource budget says it is partial. An empty inventory means nothing was recognised — not that the product has no AI.
Model files are read as bytes under a size bound and never deserialised; a format that can only be read by executing code is recorded and refused. A model reference that names a registry is recorded as a reference, never fetched. Discovery records the names of environment variables, never their values. SBOMFlow certifies no AI system and decides for no one whether it is safe.
What runs today
Model files in a scanned release — including SafeTensors, GGUF, ONNX and TFLite — are recognised, hashed and surfaced as evidence with a warning, in every scanned release, and deliberately never parsed or loaded.
ai-evidence.json artifact in every runEvery analyze and audit run lists the AI model files it found, says how sure it is about each one, and never runs them. You can hand the run your own declaration of the models, services and agents the product is meant to contain and see where it disagrees with what was observed: the declaration never overwrites the observation, and a run given no declaration says plainly that nothing was compared. What the record holds →
Sealed output from an external AI-assisted security scanner can be imported from local disk. Every finding arrives as an external, AI-assisted observation that needs human review — never a SBOMFlow finding, never a gate input, never re-scored. Partial coverage stays visible, and zero findings never means safe.
The evidence chain
Statuses below are enforced by the same no-overclaim discipline as the rest of the site. When a row changes state, this page changes with it — not before.
| Evidence | What it records | Status |
|---|---|---|
| Model artifacts in the release | Files observed in the build: format, hash, size and how strongly the format was identifiedIdentified from bytes and written to the AI evidence record on every analyze and audit run | Available today |
| Model & external-service inventory | Declared models, deployment aliases and external AI services, reconciled against what was observedYou supply the declaration; the run shows where it disagrees with the observation and never resolves the disagreement for you. A run given no declaration says that nothing was compared | Available today |
| Datasets & provenance | Dataset identity, provenance, licences, transformations, declared limitations | Available today |
| Prompts & prompt bundles | Prompt artifacts where they are genuine release artifacts, hashed and versioned | Available today |
| Agents, tools & MCP dependencies | Agents, tools, services and MCP servers observed in the release treeSBOMFlow finds the agents, tools, services and MCP servers a release declares in its configuration and dependencies, and says what it could not see. A declared permission is a supplier claim, never a verified fact. When what you declared and what was found differ, you see both — the tool never decides which is right, and none of it reaches a gate. How the record is kept → | Available today |
| Frameworks, runtimes & supporting software | The conventional software around the models — already first-class composition evidence | Available today |
| Evaluation & test evidence | Evaluation results, thresholds and human acceptance recorded as evidence, never as verdictsEvaluation records already in the release tree are read on every run and recorded exactly as supplied. SBOMFlow read an account of an evaluation rather than watching one happen, and the record says so | Available today |
| AI-specific release drift | Model and AI-evidence changes between releasesAI changes ride the same drift engine as everything else, and “nothing changed” is reported separately from “nothing was compared” | Available today |
| Human review & AI-aware gates | The live review queue, approvals and explainable gates extended with AI-aware policiesOpt-in policy controls, off by default: every AI control stays informational until an operator enforces it, an enforced control that could not run blocks with its reason instead of passing, and the reviewer console carries an AI evidence section | Available today |
| Standards-based AI/ML BOM output | Linked software SBOM plus CycloneDX ML-BOM and SPDX 3.0.1 AI profile outputOpt-in exports built from the same AI evidence record, linking to the SBOM instead of copying it | Available today |
| Redacted AI evidence sharing | A verifiable, redaction-audited AI evidence pack, following today’s passport pattern | Available today |
Standards named exactly: CycloneDX ML-BOM and the SPDX 3.0.1 AI profile ship as opt-in outputs — SBOMFlow defines no proprietary standard, and no generated document is ever regulator-approved.
What you cannot run yet. Some AI groundwork shipped inside 0.5.0 without a way to use it yet; it is not listed as available. A module that exists is not a feature that ships, and this page will only say otherwise when an operator path exists.
Two limits worth naming. A declared agent and a discovered one are matched by name and never merged into one entity — where an agent’s identity depends on the environment it runs in, which a static scan cannot observe, the comparison is refused rather than approximated. And a run you give no declaration stays observed-only and says so, rather than treating silence as agreement.
The questions this exists to answer
Not in the design documents — in the release, tied to the same release identity as every other component.
Model files observed in the build and declared external services, recorded separately, so a declaration never impersonates an observation.
Where they are genuine release artifacts they are recorded with provenance; each kind is shown with its current status in the evidence chain above.
A new model file, a swapped external service, a changed declaration — release-to-release drift, extended to AI evidence.
Gaps stated plainly, as engineering facts — the same discipline the rest of the record already has.
The same human review queue, approvals and explainable gates — extended, not duplicated.
Where this matters first
This is release assurance for real connected products with AI inside.
On-device detection models that change between firmware releases — often without anyone recording which weights shipped.
Perception and control models whose provenance and evaluation evidence belong in the release record their safety case points at.
Anomaly detection and optimisation models inside OT products, where operators ask exactly what runs on their network.
Traffic classification and filtering models — security products whose own composition should be the best-documented of all.
Where the “model” is a remote service: which service, which deployment alias, what data-handling context — declared, dated and reviewed.
When a buyer’s security review asks “does this product use AI, and how do you know?” — an evidence-backed answer instead of a shrug.
We want to build this with a small number of teams that ship AI-enabled connected products — none is represented here as a customer or partner. A design partner brings one real release with AI inside, sees each capability as it lands with its real status, and shapes the evidence model, the review boundaries and the sharing format against that release.