# 2.0 Per-Operation Runtime Reporting
Commit 23 replaces the ambiguous single active-backend view with explicit
reports for ordinary encode, ordinary strict decode, and secret decode. A
report is evidence about one named scope. It is not authority to use another
scope and it never upgrades allocation protection.
## Ordinary Backend Report
`runtime::backend_report()` exposes three independent values:
- `encode_backend` reports the backend selected by ordinary encode dispatch;
- `strict_decode_backend` reports the backend selected by ordinary strict
decode dispatch;
- `secret_decode_backend` is always
`scalar-constant-time-oriented`.
The first two identify the strongest healthy backend for qualifying ordinary
inputs. They are capability-oriented reports, not traces of the most recent
call. Small inputs, unsupported alphabets, and other documented fallback
shapes can execute a narrower backend or scalar code. In particular, an
AVX-512-capable x86 host reports AVX-512 while automatic encode deliberately
uses SSSE3/SSE4.1 for 12-23 bytes and AVX2 for 24-191 bytes before selecting
AVX-512 from 192 bytes. Automatic strict decode likewise retains AVX2 below
the strongest candidate but selects AVX2 automatically from 32 encoded bytes;
retained Commit 34 measurements did not establish the frozen AVX-512 advantage.
Exact static/evidence calls may use AVX-512 from one complete 64-byte encoded block.
Tests run sufficiently large Standard inputs through test-only execution
counters and compare the observed backend with the corresponding report;
separate boundary tests prove each length policy.
Commit 24 adds forced backend KATs and quarantine. Ordinary reports identify
`scalar-fixed`, `never-run`, `testing`, `healthy`, `quarantined`, or
`synchronization-unavailable`, retain a stable backend fault when applicable,
and expose every process-local generation change.
`BackendIdentifier` has private construction. Its stable string can be logged
or compared without making backend additions a public exhaustive-enum change.
Every `OperationBackendSnapshot` includes:
- the operation identifier;
- opaque backend identifier;
- operation-specific security posture;
- backend-health posture;
- health generation;
- the last stable backend-fault identifier, when quarantined.
`initialize_backends()` lets an application pay KAT latency during startup.
Concurrent or recursive callers that observe `testing` use scalar. A backend
that fails a KAT or redundant checked comparison is permanently quarantined
for that process and the report names scalar as active execution. See
[`2.0_BACKEND_HEALTH.md`](2.0_BACKEND_HEALTH.md).
`BackendPolicy::ScalarExecutionOnly` is a durable policy check rather than a
snapshot of temporary fallback. It rejects `never-run`, `testing`, and
`healthy` candidate states even if the sampled operation currently names
scalar. Applications should finish `initialize_backends()` during
single-threaded startup before evaluating this policy.
No ordinary backend report is a constant-time claim.
## Wasm Artifacts
Wasm does not use native x86-style runtime CPU probing. The report separately
records one of:
- `not-wasm`;
- `wasm-scalar-artifact`;
- `wasm-simd128-artifact`.
The separate runtime field is `wasm-host-runtime-unidentified`: guest Rust code
cannot authenticate whether Node/V8, Wasmtime, a browser, or another JIT loaded
the artifact. Runtime-specific admission remains external release evidence.
`wasm-simd128-artifact` means the selected artifact was compiled with
`target-feature=+simd128`. Runtime/JIT and wipe limitations remain those in
`WASM_SIMD128_RUNTIME_REVIEW.md` and `CONSTANT_TIME.md`.
## Token-Scoped Assurance
`AssuranceToken::report()` combines per-operation backend selection with the
four independent context generations:
- ordinary backend health;
- secret scalar algorithm;
- wipe primitive/barrier;
- speculation/result gate.
It also reports wipe-barrier, result-gate, attestation, secret-policy, and
Wasm artifact posture. A token report deliberately contains no protected
memory claim because no allocation participates in that observation.
For an attested token, wipe and result-gate posture come from the exact
matching attestation evidence. A best-effort token reports current build and
target posture. Neither result can turn `WipedBestEffort` into
`WipedAttested`.
## Exact Allocation Reports
`ProtectedSecret::operation_report(&token)` reports physical protection only
for that exact live allocation. It fails closed when the token, context, or
provider generation is stale. Its independent fields include:
- secret operation (`secret-encode`, `secret-decode`, or `not-started`);
- `WipeNotCompleted` while the allocation is live;
- `ProtectionAttested`, `ProtectionConfirmedAbsent`, or
`ProtectionUnknown` from the exact provider handle;
- conservative accounting posture;
- lifecycle posture;
- address-free allocation presence;
- provider health and protection generations.
The report contains no pointer, provider handle, allocation identity, or
secret length. The default provider therefore reports
`ProtectionConfirmedAbsent`; finite accounting cannot be rendered as a page
lock, dump exclusion, or attestation.
## Teardown Snapshots
`CleanupReport::snapshot()` and `CleanupError::snapshot()` keep these axes
separate:
- wipe evidence;
- physical protection;
- accounting;
- lifecycle;
- allocation presence;
- pending teardown stage and journal substage;
- provider health and retry attempt.
A successful close reports `absent`. Retryable and permanently quarantined
storage reports `present` without an address. Indeterminate disposal reports
`unknown-no-address-retained`; the provider must have destroyed the addressable
handle before returning that state. A lifecycle value never silently upgrades
wipe, protection, or accounting evidence.
`ProviderReport::snapshot()` separately records provider health generations,
active/reserved counts, retryable quarantine, permanent quarantine,
tombstones, and conservative byte/page charges. Aggregate accounting is not
allocation-specific physical protection.
## Stable Logging Contract
Snapshot fields use stable lowercase identifiers and redacted diagnostics.
They are intended for operator logs and release evidence. Typed reports remain
`#[non_exhaustive]` where extension is expected. Consumers should not infer:
- a secret timing claim from ordinary acceleration;
- runtime CPU probing from Wasm artifact selection;
- page locking from provider resource charges;
- wipe attestation from successful lifecycle transitions;
- allocation absence from a tombstone.
The dedicated gate is `scripts/check-2.0-operation-reporting.sh`.