Evidence object
Sample runtime-assurance decision trace
A runtime assurance trace records the candidate action, evidence state, constraints checked, binding limit, decision, permitted repair, and rollback posture. This sample uses synthetic data to show the shape of an inspectable allow / repair / reject / no-proof record. It does not represent a customer site, field test, pilot, or production control event.
Definition
What it is
The trace is a decision artifact designed to explain why a candidate was accepted, changed, refused, or left unproven at a specific time.
Category boundary
What it is not
It is not a raw telemetry dump, proprietary solver disclosure, universal safety certificate, or proof that the illustrated action occurred.
Operational significance
Why operators care
Operators and reviewers can follow the decision path without relying on a model score. The trace also provides a stable object for replay, audit, correction, and comparison.
Mechanism
How the decision path works
- Step 01
Bind the request to topology, policy, and telemetry versions.
- Step 02
List each evaluated constraint and its margin.
- Step 03
Record the decision and any bounded repair.
- Step 04
Attach rollback requirements, evidence hashes, and expiry conditions.
Textual diagram equivalent
Decision flow
Requested action + evidence snapshot → constraint evaluations → binding margin → repaired action → rollback posture → immutable trace reference.
Synthetic trace excerpt
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. The example repairs a capacity request after reserve margin becomes binding and records the original request separately from the accepted action.
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 sample demonstrates a trace structure that separates request, repair, binding constraint, and rollback posture.
- Maturity
- DESIGN TARGET
- Environment
- synthetic
- Measurement window
- One synthetic decision instant plus a declared recovery window.
- Sample size
- One illustrative trace; no population inference.
- Version
- 1.0.0-publication-candidate
- Artifact hash
- See the versioned release manifest for the example digest.
- Result
- A structural example is supplied; no operational result is claimed.
- Uncertainty
- The example has not received named operator or independent review.
- Interpretation
- Evaluate the transparency of the proposed artifact, not facility performance.
- Technical owner
- Unassigned — publication remains gated
- Reviewer
- Unassigned — no independent review is claimed
- Next review
- Not scheduled until named ownership is approved
Assumptions
- Synthetic topology
- Synthetic telemetry
- No control command was issued
Method
- Validate schema
- Inspect constraint sequence
- Verify original and repaired actions remain distinct
Negative and no-proof cases
- Missing input version
- Missing rollback
- Unlabeled repair
- No-proof collapsed into reject
Reproduction procedure
- Download the example and schema
- Run the release validator with Node 22
- Inspect the recorded constraint and decision fields
Failure and no-proof cases
- The trace omits the original request after a repair.
- Constraint results cannot be tied to an input version or timestamp.
- A no-proof outcome is collapsed into a generic rejection without evidence context.
Limitations
- The sample is synthetic and deliberately excludes facility topology and protective thresholds.
- Schema completeness does not establish the correctness of an underlying model.
- Named review and release signing are pending.
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
- How much virtual capacity is safe, for how long, and under which evidence?Learn how a dispatch envelope constrains data center actions by electrical, thermal, reserve, workload, water, and SLA limits before execution.
- Review the proof objects before a live reviewInspect the proof artifacts that make virtual capacity reviewable: constraints, decisions, accepted headroom, provenance, replay, and rollback evidence.
- Runtime assurance keeps capacity actions inside the envelopeHow a runtime assurance gate constrains AI data center actions with deterministic allow, repair, reject, and no-proof outcomes.
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.