Evidence protocol
Virtual Capacity Proof Test v1.0
The Virtual Capacity Proof Test is a synthetic, methods-first protocol for checking whether a capacity-acceptance system refuses unprovable actions and preserves evidence. It covers stale telemetry, topology mismatch, reserve floors, thermal and water constraints, SLA limits, rebound, and connection loss. Passing a synthetic test demonstrates protocol behavior only; it is not a customer, pilot, or production result.
Definition
What it is
The protocol is a versioned set of inputs, expected decisions, required evidence fields, and negative cases for the allow / repair / reject / no-proof boundary.
Category boundary
What it is not
It is not a safety certification, independent validation, customer benchmark, or claim that the tested logic has controlled a production facility.
Operational significance
Why operators care
A negative-case-first test makes refusal behavior reviewable before site integration. It also gives operators a reproducible way to inspect evidence completeness and decision determinism.
Mechanism
How the decision path works
- Step 01
Load a declared synthetic topology, policy, telemetry sequence, and capacity request.
- Step 02
Run the candidate through the versioned dispatch-envelope evaluator.
- Step 03
Compare the result and required evidence fields with the expected fixture.
- Step 04
Canonicalize the artifact, verify hashes, and retain failures without overwriting them.
Textual diagram equivalent
Decision flow
Versioned fixture → evaluator → expected versus observed decision → evidence completeness checks → canonical artifact hash → pass or fail record.
Synthetic test fixture
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. A stale-telemetry fixture expects no-proof and verifies that no accepted-headroom entry is emitted.
Evidence record
Scope before result
This record keeps the claim, environment, evidence maturity, and review boundary together. Publication status is not a substitute for named technical ownership or independent review.
- Claim
- The supplied synthetic fixtures specify deterministic acceptance and refusal expectations for seven failure families.
- Maturity
- DESIGN TARGET
- Environment
- synthetic
- Measurement window
- Fixture timestamps span a synthetic 15-minute operating window.
- Sample size
- Seven negative-case families; fixture expansion is pending review.
- Version
- 1.0.0-publication-candidate
- Artifact hash
- See the versioned release manifest for per-file SHA-256 digests.
- Result
- Publication candidate: fixtures and expected outcomes are available; no reviewed performance result is asserted.
- Uncertainty
- Coverage completeness and evaluator independence have not yet received named external review.
- Interpretation
- Use this release to review the proposed proof contract and negative cases, not to infer production effectiveness.
- Technical owner
- Unassigned — publication remains gated
- Reviewer
- Unassigned — no independent review is claimed
- Next review
- Not scheduled until named ownership is approved
Assumptions
- All inputs are synthetic and contain no customer or facility data.
- Expected outcomes describe the protocol contract, not measured field performance.
- The evaluator and fixtures use the same declared schema version.
Method
- Validate each fixture against the release schema.
- Evaluate the declared capacity request against topology, policy, and telemetry state.
- Compare decision, reason code, binding constraint, and artifact requirements.
- Fail closed on missing inputs, schema drift, or non-deterministic output.
Negative and no-proof cases
- Stale telemetry and connection loss
- Topology mismatch
- Reserve-floor violation
- Thermal or water constraint
- SLA limit and rebound breach
Reproduction procedure
- Download the manifest, fixtures, schema, and validator from the stable release path.
- Verify each file digest against the manifest.
- Run the validator with Node 22, then compare expected decisions without modifying fixtures.
Failure and no-proof cases
- A fixture accepts capacity when a required input is stale or absent.
- Repeated identical inputs produce materially different decision artifacts.
- An accepted action lacks a binding constraint, margin, or rollback posture.
Limitations
- Fixtures are synthetic and cannot represent every facility topology or failure interaction.
- The release is publication-gated until named technical ownership and independent review are recorded.
- A passing protocol result does not authorize field control.
Evidence and sources
Inspect the basis, not just the answer
Local evidence objects show the GridNinja proof contract. Primary sources provide external standards and risk-management context; they do not validate GridNinja performance.
Related operator resources
Continue the proof path
- Trust starts with boundariesSee how Shadow Mode, replay, allow / repair / reject decisions, audit logs, and proof packs establish evidence before bounded autonomy.
- Sample runtime-assurance decision traceA publication-gated synthetic runtime-assurance trace showing allow, repair, reject, and no-proof evidence fields.
- Claims must never outrun evidenceHow GridNinja scopes public claims by environment, maturity, evidence, approved surface, caveat, and review expiry.
Proof before autonomy
Test the evidence boundary against your capacity question
Start with a Capacity Audit or read-only Shadow Mode discussion. GridNinja does not require control authority to identify where a capacity claim remains unproven.