This chapter describes evidence semantics, not a successful test result.
The current whitepaper can document the control contract and the records the runtime is designed to produce. It does not publish a completed Validation Protocol run that demonstrates request-bearing reliability, recovery, or enforcement outcomes.
A claim about observed behavior should cite a dated run bundle for an identified product build and environment. Without that bundle, the claim remains architectural, contractual, or unverified.
Source can show a mechanism and its intended invariants.
Which checks exist, what inputs they bind, which failures are handled, where state is stored, and which actions are bounded in the inspected revision.
That the inspected code is the deployed code, that a path executed, that dependencies behaved as expected, or that an outcome met its target.
Customers can inspect components installed on their hosts. Public runtime snapshot parity with the current deployable launcher and agent is not established and must not be inferred from similar filenames or documentation.
Follow the claim from intent to outcome.
| Layer | Representative record | Question answered | Does not establish |
|---|---|---|---|
| Intent | Desired-state revision or bounded command | What the hosted plane requested, for which target, and when | Approval, delivery, or execution |
| Artifact identity | Exact package hash and vendor release signature | Which bytes were selected and whether expected release metadata signed them | Customer approval or runtime outcome |
| Customer approval | Customer signature over the exact release hash | Whether the configured customer key approved that hash | That a human reviewed it under auto mode, or that it executed |
| Transfer integrity | Digest of bytes obtained on the customer host | Whether received bytes match the expected digest | Process start or service health |
| Execution | Local acknowledgement, process identity, start or exit event | Whether the identified runtime attempted or entered execution | Healthy, reachable, or current state |
| Outcome | Health checks, route probes, request records, service metrics | What the configured observers saw for the recorded interval | Unobserved paths or future behavior |
| Recovery | Fault timeline, restart or rollback receipt, restored probes | What happened after a specific recorded failure | Recovery from other failures or incompatible data changes |
Status names need explicit evidence.
The hosted service recorded intent. The target may not have received it.
A target reported receipt. It does not mean the action completed.
The executing component reported its terminal action state. Inspect correlated outcome evidence.
A defined step stopped with an error. The system may still be partially running.
Hosted authority was withdrawn. An offline target can apply that change only after receiving it.
A prior state was requested or restored. Data and dependency compatibility require separate validation.
A useful bundle preserves identity across systems.
- Target: workspace, host, agent, service, and route identifiers.
- Revision: management-plane build, launcher and agent versions,
infraveil.jsonrevision, package hash, and policy revision. - Time: issued, received, started, completed, observed, and recovered timestamps with clock assumptions.
- Causality: command or rollout identity propagated into runtime events, receipts, health, gateway records, and rollback activity.
- Gaps: dropped events, queue pressure, stale state, missing probes, sampling, retention, and offline intervals.
Reproduce the claim at the customer boundary.
- 1. Inspect the delivered runtime.
Record the exact customer-side components and hashes rather than relying on a source snapshot.
- 2. Exercise the selected approval mode.
Show the behavior for an approved hash, an unapproved hash, and a changed package.
- 3. Observe disk and network boundaries.
Record custody-mode persistence, outbound calls, managed routes, and any route that bypasses the gateway.
- 4. Inject failures.
Test coordination loss, process failure, disk pressure, bad health, and recovery stop conditions.
Use the Validation Protocol to define and publish a dated execution record. Until such a record exists, describe runtime outcomes as unverified rather than proven.