No completed run evidence is published here.
The checked-in validation material does not contain a successful, request-bearing run. The only checked-in result is a failed smoke attempt that recorded zero requests. It cannot establish throughput, availability, recovery, enforcement, or release behavior.
The sections below are a protocol. Results become evidence only when a run records its version, configuration, timestamps, workload, traffic, faults, raw outputs, and acceptance decisions.
Fix the test boundary before observing results.
Record the management-plane build, launcher and agent release identities, and the exact workload package hash.
Record host resources, operating system, network path, runtime versions, and relevant external dependencies.
Archive the validated infraveil.json, approval mode, gateway policy, restart limits, health definitions, and persistence paths.
Define pass, fail, and inconclusive thresholds before running traffic or injecting faults.
Test identity, approval, execution, and outcome separately.
- 1. Enroll through the Trust Console.
Confirm the customer key remains on the customer machine and the host receives only the scoped identity needed for its workspace.
- 2. Validate the runtime contract.
Reject malformed or ambiguous
infraveil.jsoninput and record the accepted manifest revision. - 3. Exercise release approval.
For manual and allowlist modes, show that an unapproved exact hash stays pending. If auto is tested, record that it removes the per-release veto while enabled.
- 4. Correlate execution.
Tie the approved hash to downloaded bytes, the launched process, health observations, route state, and the resulting receipt.
Measure only traffic that reaches the configured gateway.
Drive a recorded mix of successful requests, application errors, malformed requests, slow bodies, streaming responses, and WebSocket traffic through managed routes. Compare client results with gateway decisions, upstream application logs, and counters.
Report request rate, latency distribution, response codes, dropped connections, resource use, and any missing telemetry. A test at the origin does not establish protection against upstream volumetric DDoS, traffic that bypasses the configured gateway is outside the gateway result, and provider-layer mitigation must be validated separately.
Observe stop conditions as closely as recovery.
Interrupt synchronization; record workload continuity, stale-state labeling, queued activity, and reconnect ordering.
Crash a supervised service until its configured restart budget is exhausted; verify that the runtime stops thrashing and reports the failure.
Deploy an unhealthy but valid release and observe the configured health gate, stop, or rollback behavior.
Constrain workspace or cache storage; record whether writes stop safely and what remains recoverable.
Remove a required upstream service and distinguish running, healthy, reachable, and current states.
Record the delay between hosted revocation and local application after the host reconnects.
Record what is stored, not what the mode name implies.
For source-custody mode, enumerate application files, the manifest, package, cache, and configured persistent paths on disk. For no-source attach, verify that a fresh package contains the manifest only and separately inspect whether files from any earlier hosted package remain in the workspace.
Repeat the inspection after restart, failed deployment, rollback, cleanup, and offboarding. Record permissions and deletion behavior for each path.
A result needs enough context to be reproduced.
| Record | Required contents | What it can support |
|---|---|---|
| Run manifest | Versions, hashes, host, topology, configuration, start and end time | Reproducibility boundary |
| Traffic record | Generator settings, completed requests, response distribution, latency, errors | Observed behavior for that workload |
| Fault timeline | Injected event, expected response, actual timestamps, stop or recovery state | Observed failure handling |
| Evidence bundle | Raw outputs, receipts, logs, counters, gaps, and reviewer decision | Audit and independent review |
Results apply only to the recorded build and environment. A later runtime, policy, workload, or infrastructure change requires a new run or an explicit explanation of why the prior result still applies.