Reference values
A reference value is an expected identity used by a verifier's policy—for example, a boot measurement or an approved software/configuration digest. This explorer follows published references alongside observed identities and the documents that describe them.
- Expected reference
- A value a policy proposes or permits. Who published it and which client accepts it are separate questions.
- Observed identity
- A value extracted from captured workload evidence. Its authenticity and match to the intended policy require verification.
- Document fingerprint
- A hash of captured publication or policy bytes. It detects a document change; it is not a hardware measurement.
A concrete example: published PCRs, observed workloads and file hashes
Maple publishes PCR0 measurements for its Nitro enclave. A published PCR0 can supply an expected value to a client policy. A PCR0 from an authenticated live attestation would describe an observed enclave. The SHA-256 of the downloaded PCR JSON file is a third value: it identifies the publication bytes. Matching two copies of that file establishes publication agreement, not which enclave served a request.
The timeline includes software releases, configuration and reference-policy updates, document edits, and different fleet instances sampled at different times. A newly seen value asks for explanation; it does not by itself mean a deployment, an attack or a policy violation. Compare the full identity for the same component and field with the exact client's policy, then inspect the authenticated evidence and review history.
A stable value has limits too. In the reviewed Chutes design, the base-image measurement did not identify operator serving code. That code could change without a new base-image value. Audits establish what a value covers; the explorer records what we captured.
Select a timeline point for exact old/new values, evidence and review scope. How to read the timeline · How this relates to private inference
Reference change timeline
Dots mark first captures, changed sets and returns to previously seen sets. Pale ticks mark sampled days. Empty space means no capture; it does not prove stability. Dates are UTC observation dates.
Latest captured values
Full values stay inspectable. “Latest” means the last capture of this surface; it may be historical. Reported workload ≠ published reference ≠ values accepted by a particular client.
| Surface / evidence | Last capture | History | Full reference values |
|---|
How to read the timeline
Reference-set delta: the number of entries added and removed. Replacing one opaque hash is two set edits; it says nothing about the size of the underlying code change.
Captured-text delta: inserted and deleted lines between retained versions of the same document. A one-line minified bundle can contain a large change. This is not a deployed-code diff.
Provider route cards: inventory routes associated with the provider or observed model. This is a conservative navigation aid, not a verified dependency graph or a count of affected plaintext paths.
Audit surface: every point links to the precise reference and evidence surface. Full-value matches to the existing review ledger are shown with their recorded scope and review date; they are not new audit approvals. Source-to-artifact mappings, reproducible builds, request bindings, dependency changes and operator policy changes still need a scoped review. No synthetic risk score is assigned.
The published JSON inventory extracts digest-shaped values with their field paths, including policy keys. It does not interpret every boolean, threshold or permission as a reference value; the document hash still catches those edits. Provider-supplied historical PCR lists are captured as sets at fetch time, not backdated as observed deployments. Legacy model rows and rejected reports remain visible without upgrading their trust.