Evidence specification
Load Passport specification
A Load Passport is a versioned contract describing what an AI workload requires and what flexibility it may safely offer. It expresses power and timing needs, placement constraints, SLA class, thermal or recovery dependencies, permitted actions, evidence requirements, and authority boundaries. It lets capacity decisions evaluate a workload as an operational contract rather than an anonymous demand curve.
Definition
What it is
The specification provides machine-readable and operator-readable fields for a workload's declared operating envelope and proof requirements.
Category boundary
What it is not
It is not a customer identity record, scheduler replacement, pricing agreement, or permission to expose workload contents, topology, credentials, or proprietary policy.
Operational significance
Why operators care
Infrastructure teams can evaluate whether a proposed workload placement or flexibility action fits facility constraints while preserving the workload's explicit protections.
Mechanism
How the decision path works
- Step 01
Declare workload demand, duration, ramp, placement, and SLA requirements.
- Step 02
Declare permitted flexibility, recovery, and rollback constraints.
- Step 03
Bind the passport to policy and schema versions.
- Step 04
Use only the minimum fields required for a capacity decision and proof artifact.
Textual diagram equivalent
Decision flow
Workload requirements + permitted flexibility + SLA and recovery limits → Load Passport → dispatch-envelope evaluation → accepted action and proof reference.
Synthetic passport
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. The sample permits a bounded timing shift but forbids interruption and requires recovery before a declared deadline. No real workload or operator data is present.
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 schema candidate separates workload requirements, permitted flexibility, recovery, and evidence references.
- Maturity
- DESIGN TARGET
- Environment
- synthetic
- Measurement window
- The example declares a synthetic 30-minute operating and recovery window.
- Sample size
- One schema and one synthetic example embedded in the proof pack.
- Version
- 1.0.0-publication-candidate
- Artifact hash
- See the versioned release manifest for the schema digest.
- Result
- A sanitized schema candidate is supplied; no deployment claim is made.
- Uncertainty
- Scheduler interoperability and operator usability are not yet reviewed.
- Interpretation
- Use the artifact to review the proposed workload-to-capacity contract.
- Technical owner
- Unassigned — publication remains gated
- Reviewer
- Unassigned — no independent review is claimed
- Next review
- Not scheduled until named ownership is approved
Assumptions
- No customer identifiers
- UTC timestamps
- Policy-controlled flexibility fields
Method
- Validate schema
- Inspect required protections
- Verify the example contains no sensitive operational data
Negative and no-proof cases
- Missing SLA class
- Unbounded flexibility
- Missing recovery
- Sensitive data field
Reproduction procedure
- Download the schema and example
- Run the release validator
- Review fields against the documented authority boundary
Failure and no-proof cases
- Permitted flexibility is inferred rather than explicitly declared.
- SLA and recovery constraints cannot be tied to a policy version.
- The passport includes sensitive workload or facility data not required for acceptance.
Limitations
- The candidate schema does not replace site-specific workload, security, or change-control procedures.
- No interoperability or field-performance claim is made.
- Publication remains gated pending named technical and independent review.
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
- The platform for runtime-assured virtual capacitySee how GridNinja coordinates workloads, cooling, storage, and bridge power inside a runtime-assured dispatch envelope.
- For AI Clouds Racing Against the GridAccelerate AI cloud time-to-power by proving virtual capacity across power, cooling, workloads, reserves, and bridge power.
- Accepted-headroom ledger specificationA publication-gated specification for recording proof-adjusted capacity, binding constraints, evidence, and expiry conditions.
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.