Evidence object
Accepted-headroom ledger specification
An accepted-headroom ledger records only the capacity that passed the declared evidence and dispatch-envelope checks for a specific site context and time window. Each entry links the accepted quantity to its request, binding constraint, remaining margin, evidence versions, authority boundary, and expiry conditions. It prevents modeled or claimed headroom from being silently treated as durable sellable MW.
Definition
What it is
The ledger is an append-oriented capacity accounting record with explicit lineage from request to proof-adjusted acceptance.
Category boundary
What it is not
It is not an energy bill, DCIM inventory, commercial settlement statement, or guarantee that a past acceptance remains valid under changed conditions.
Operational significance
Why operators care
Facilities, commercial, and assurance teams can reconcile which capacity was accepted, what evidence supported it, and why later entries changed or expired.
Mechanism
How the decision path works
- Step 01
Reference the original capacity request and evaluation context.
- Step 02
Record accepted quantity, duration, binding constraint, and margin.
- Step 03
Attach evidence versions, authority boundary, and rollback posture.
- Step 04
Append correction, expiry, or retraction records without erasing prior state.
Textual diagram equivalent
Decision flow
Capacity request → proof adjustment → accepted entry → active monitoring → expiry, correction, or re-evaluation → linked ledger history.
Synthetic ledger entry
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. A time-bounded accepted quantity expires when topology version or telemetry freshness no longer matches the recorded evaluation context.
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 proposed ledger schema preserves capacity lineage, evidence references, and expiry conditions.
- Maturity
- DESIGN TARGET
- Environment
- synthetic
- Measurement window
- Illustrative entries use declared start, end, and evidence-expiry timestamps.
- Sample size
- One schema and one synthetic example.
- Version
- 1.0.0-publication-candidate
- Artifact hash
- See the versioned release manifest for per-file digests.
- Result
- A reviewable schema candidate is supplied; no production ledger is represented.
- Uncertainty
- Operator usability, scale, and external interoperability remain unreviewed.
- Interpretation
- Use the candidate to review evidence lineage and capacity-accounting semantics.
- Technical owner
- Unassigned — publication remains gated
- Reviewer
- Unassigned — no independent review is claimed
- Next review
- Not scheduled until named ownership is approved
Assumptions
- Append-oriented records
- UTC timestamps
- Stable evidence identifiers
Method
- Validate required lineage fields
- Verify expiry representation
- Verify corrections can reference superseded entries
Negative and no-proof cases
- Missing expiry
- Duplicate capacity
- Overwritten correction
- Unresolved evidence reference
Reproduction procedure
- Download the proof-pack schema and example
- Run the validator
- Inspect the acceptedHeadroomLedger entry and references
Failure and no-proof cases
- Accepted quantity lacks a declared duration or expiry condition.
- Later corrections overwrite rather than reference the prior record.
- The same reserve or headroom is counted in overlapping entries.
Limitations
- The ledger structure does not independently prove the correctness of its inputs.
- Commercial use requires reconciliation with contracts and operating procedures.
- The example release is synthetic and publication-gated.
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
- Proof-adjusted capacity starts where nominal headroom stopsHow proof-adjusted capacity separates nameplate, modeled, claimed, and accepted headroom for safer sellable MW decisions.
- 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.
- 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.