v0.6.0

Rio v0.6.0

Give a client one JSON file explaining which SBOMs Rio selected, what it changed, which requirements
it checked, and what happened at each delivery destination. An optional self-contained HTML report
presents the same validated facts without the original workspace or credentials.

See the record

Two SBOMs consumed → pipeline evidence added → delivered to Dependency-Track → receipts retained.

Here is a readable excerpt from an actual Rio v0.6.0 record, produced with a synthetic HTTPS receiver
speaking the Dependency-Track upload API. Input digests are shortened here:

Consumed
  api.cdx.json  SHA-256 1d2b04c0df45…
  worker.cdx.json  SHA-256 721bd8311e64…

Added to both SBOMs
  build.url  https://ci.example.org/runs/42
  build.id   42

Delivered
  Receiver   Dependency-Track API
  URL        https://127.0.0.1:61362
  Projects   api / 1.0.0, worker / 1.0.0
  TLS        observed; certificate verification enforced

Server acknowledgments
  api: HTTP 200, accepted
    token: 11111111-1111-4111-8111-111111111111
  worker: HTTP 200, accepted
    token: 22222222-2222-4222-8222-222222222222

Read the full record.json ·
Download the HTML report (open locally) ·
Reproduce this example

The URL is the destination server, not the Dependency-Track project website. This demo used a
local receiver; your record contains your configured instance URL, such as https://dtrack.example.org.
It also retains the original and delivered SBOM digests, exact payload sizes, project identities,
and response timestamps. Pipeline values are supplied by your build; HTTP 200 records acceptance,
not proof of ingestion.

With intake, pipeline context, and delivery configured in rio.yaml:

rio normalize --gate fail && rio deliver --evidence target/rio/record.json
rio record inspect --file target/rio/record.json
rio record report --file target/rio/record.json --output target/rio/report.html

What changed

• Normalization retains stable change pointers and selected repair sources, including the digest of
  the mapping bytes actually loaded. Upstream assertions remain assertions; Rio no longer invents
  a fixed confidence score for new identity evidence.
• Selection scope and effective requirements are inspectable, with explicit component traversal,
  evaluated counts and warn/fail mode. Empty or unsupported checks do not appear to have passed.
• deliver --evidence retains the exact batch scope and index snapshot before requests, then collects
  a portable record on ordinary success, rejection, partial or unknown outcomes. Missing evidence
  stays distinct from a runner-recorded unattempted result. Local publication failures never retry uploads.
• record report renders scope, changes, checks, every selected attempt, observations and exceptions
  as escaped offline HTML. It includes the exact input JSON digest and uses no scripts or remote assets.

Try it

With intake and delivery targets configured in rio.yaml, and credentials available to native delivery:

rio normalize --gate fail &&
  rio deliver --evidence target/rio/record.json
rio record inspect --file target/rio/record.json
rio record report --file target/rio/record.json --output target/rio/report.html

Use fresh evidence/report paths. If the enforced gate fails, export its normalization evidence with
rio record; do not proceed to delivery. After explicit reconciliation, collect a new snapshot:

rio record --schema-version 2 --batch target/rio/record.json.batch.json --output record-after.json

See the CLI workflow
and the installed-binary client handoff demo.

Compatibility

Explicit journal collection still defaults to record v1. Record v2 is opt-in through
--schema-version 2 or deliver --evidence; --batch requires v2. New readers accept both versions;
v1-only readers refuse v2. Existing --record still means one delivery journal. Normalization adds
independently versioned optional index extensions; older records remain useful with missing details
labelled. Mapping assertions retain their supplied JSON values; ambiguous duplicate object names
and invalid Unicode in mapping tables now refuse before output is written.

What the evidence means

An accepted receipt is an acknowledgment, not proof of ingestion. Dependency-Track activity remains
separate from content verification, which that adapter does not claim. HTTP, TLS verification bypass,
failed-gate override permissions, unknown outcomes and missing evidence remain visible. Every selected
attempt is retained rather than choosing the most favorable result.

Records are unsigned consistency evidence. Full SBOM/input/mapping files and authenticated worker
identity remain outside this increment. Keep the JSON alongside HTML for machine inspection.

Validation

The workflow has been exercised with installed binaries, source removal, corrupted projections,
actual process interruption, lost responses and retained retry/reconciliation snapshots. Native
Linux/macOS/Windows CI covers delivery and evidence. Disposable Dependency-Track 5.1.1 with
PostgreSQL 18 was tested over HTTP and a local HTTPS gateway, including trusted CA and explicit bypass;
harness inventory observations are kept separate from native evidence. Disposable Distribution and
Zot checks cover shared OCI delivery/evidence behavior. Artifactory remains outside the tested scope.

Implementation and CI evidence: PR #102,
client acceptance tracking.