Common representation · Draft specification
One evidence family.
Distinct evidence boundaries.
DEEPBOM Evidence IR connects multiple model formats and optional evidence inputs through shared identities, references and validation rules. Each member answers a different question.
Input → common IR → output
Open the compatibility explorer to search versioned field mappings, distinguish implemented and proposed paths, and inspect input/output schemas, source references and evidence limits. The website and GitHub share the same generated catalog.
Common representations
| Representation | What it records |
|---|---|
| Artifact IR | Observed artifact structure, native facts and serialized storage. |
| Model IR | A common program and contracts derived from validated Artifact IR, or a separately versioned native-state adapter. |
| Weight IR · optional | Assessed tensor payload statistics, source bindings and explicit coverage limits. |
| Activation IR · optional | Imported execution captures bound to a model, run and probe. Static inspection does not create runtime measurements. |
| Provenance IR · optional | Connections to datasets, code, runs, reports and external BOMs; supplied-file consistency and declared relationships remain distinct. |
| Training IR · optional | Ordered lifecycle and time observations linked to available state and activation captures. Collector closure does not imply completed training. |
| Snapshot IR · optional | Fixed model state, dataset release or configuration within an explicit scope. Existing native-state hashes are preserved through an adapter. |
Shared rules
Artifact analysis and explicit local native capture retain distinct source contracts. Optional members use typed references without modifying source identities. Evaluation and change-review documents are supporting workflow records, not extra analytical IR layers. References, digests, exact counts and coverage must remain consistent. Unknown, unsupported and unassessed values stay explicit.
The family JSON Schema accepts one member document. It is not a bundle format. JSON Schema checks structure; member validators additionally check source bindings and semantic consistency. A digest alone does not authenticate a publisher or prove a lineage claim.
Use and inspect the specification
- Current additive family JSON Schema · Snapshot and workflow contracts
- Artifact family v1 catalog · Native family catalog · Current compatibility index
- Provenance IR schema entry point
- Specification, compatibility checks and maintenance process
- Weight and activation workflows · OMOP metadata connections
These names describe a DEEPBOM-maintained specification. They do not imply endorsement or certification by OMOP, CycloneDX, SPDX or W3C. External mappings retain their source standards and limits.
Review a model change
Snapshot, provenance and external evaluation records flow through one evidence context and the same validators in Web, CLI, SDK and local MCP. Exact model and data identities, comparable conditions, units, denominators and source records precede any before/after calculation. Missing bindings stay unresolved.
Open the local evidence review · Run the synthetic example · Workflow, outputs and limits
Current contract and transition
The artifact metadata route keeps deepbom.provenance_ir.v1 and --section provenance_ir. The additive workflow uses typed deepbom.provenance_ir.v2 references. Existing native state, artifact and numerical contracts retain their identifiers; archived documents are never relabeled. Read the earlier transition rules.
Exchange through TEA
TEA describes discovery and exchange of transparency documents. It can deliver future exports while Evidence IR continues to define and validate their evidence. A TEA adapter is proposed, not implemented. Read the pinned specification review.