9e6b8d32b4
The contract cargo class: a content-addressed statement of what a unit of work must hold (pre/post/inv), what it may touch (frame), and what it may spend (a joule EnPI ceiling against a signed baseline) — discharged into one signed receipt that evidences functional safety, energy management, and AI governance at once. Doctrine: inherit don't invent, bind don't name, seal don't float — every trust-bearing field binds or serializes a demoted state, conformance seals once at discharge against a content-addressed evidence bundle (resolution-free, air-gapped capable), and breach is deviation without a timely amendment, with amendments governing the future only. Ships the v0.6.0 spec with its full amendment history: archive/ holds every prior version byte-exact so the SPEC §16 digest chain verifies, and provenance/ holds the three adversarial diff rounds whose findings drove each traced amendment. Reference workspace joulecontract-rs/ (schema, receipt, seal, amend, conformance) runs the diff-round attack scenarios as tests and mechanically verifies the digest chain. Root README catalogs joulecontract in the standards family, the tree, and the contribution guide. Site: joulecontract.transaction.science. Co-Authored-By: Claude Fable 5 <[email protected]>
240 lines
17 KiB
Markdown
240 lines
17 KiB
Markdown
# JouleContract
|
||
|
||
**An Open Standard for Energy-Accounted Interface Contracts**
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Status** | Draft for Review |
|
||
| **Version** | 0.2.0 — re-founded on the recognized governance canon |
|
||
| **Canonical home** | `joulecontract.transaction.science` |
|
||
| **License** | Specification text: CC-BY-4.0 · Reference implementation: Apache-2.0 (Rust) |
|
||
| **Stewardship** | The protocol is ownerless. Transaction Science, Inc. is the steward. |
|
||
| **Position** | The operand between JouleCode, JouleProof, and JouleClaw; denominated in the EOC joule unit; readiness scored by ARL. |
|
||
| **Prime directive** | Energy optimization, safety, and auditability — served by one receipt, not three programs. |
|
||
|
||
---
|
||
|
||
## Abstract
|
||
|
||
A JouleContract is a content-addressed, signed statement of what must be true across a transition and what that transition is permitted to cost. It is **not a new governance framework**. It is the technical control object whose single signed receipt simultaneously discharges evidence for three management-system standards that today run as separate programs with separate audits: functional safety (IEC 61508), energy management (ISO 50001 with ISO/IEC 30134), and AI governance (ISO/IEC 42001).
|
||
|
||
Complex systems fail at their interfaces. A JouleContract is a contract over an interface crossing — any transition where work transforms state and an invariant must survive the boundary. Energy is the coordinate that makes those transitions one class of object on one ledger. Three audits collapse into three projections of one receipt log.
|
||
|
||
---
|
||
|
||
## 1. Design Principle: Inherit, Don't Invent
|
||
|
||
The three things this standard serves — energy optimization, safety, auditability — each already have a mature, internationally recognized management-system standard. JouleContract does not replace them. It binds their evidence into one object so that what are now three parallel programs become three views of a single signed receipt.
|
||
|
||
The contribution is the **convergence**, not a new vocabulary. Energy is load-bearing from the first receipt because it shares that receipt with safety and governance, rather than being reported separately and late.
|
||
|
||
---
|
||
|
||
## 2. Normative Inheritance
|
||
|
||
The standard is built on, and emits evidence into, the following. Conformant implementations MUST be expressible in terms of these where the column applies.
|
||
|
||
### 2.1 Safety — IEC 61508 (and sector derivations)
|
||
|
||
- IEC 61508 is goal-based functional safety: set a risk-reduction target, then demonstrate it through **structured evidence** (an assurance case) across a defined safety lifecycle, under a V-model verification-and-validation process that explicitly admits model checking and theorem proving as assurance techniques.
|
||
- Rigor is graded by **Safety Integrity Level (SIL 1–4)**, a property of the function, not the component.
|
||
- Sector derivations apply where relevant: ISO 26262 (automotive), IEC 62304 (medical-device software), EN 50128/50129 (rail), IEC 61511 (process).
|
||
- **What JouleContract inherits:** the assurance-case-as-evidence model (the receipt log *is* the assurance case), the SIL grade, and the "shall is mandatory / may must be justified" normative discipline (RFC 2119 keywords are used throughout).
|
||
|
||
### 2.2 Energy — ISO 50001 + ISO/IEC 30134
|
||
|
||
- ISO 50001 is the energy-management system: it tracks **Energy Performance Indicators (EnPIs)** against an **Energy Baseline (EnB)** through a governed continual-improvement loop.
|
||
- ISO/IEC 30134 defines data-centre KPIs — PUE (Part 2, 2026 edition), CUE (carbon, Part 8) — and, critically, defines **multiple measurement categories for varying precision and granularity** and rules for **unaccounted energy** and on-site generation.
|
||
- **What JouleContract inherits:** the joule ceiling is an **EnPI measured against an EnB**; the ratchet (§5) is the ISO 50001 continual-improvement loop; the energy-provenance tag (§4.2) is the ISO/IEC 30134 measurement category, and the `Estimator` case is 30134's "unaccounted energy" rule made explicit.
|
||
|
||
### 2.3 Governance — ISO/IEC 42001 (and family)
|
||
|
||
- ISO/IEC 42001 is the first certifiable international AI management-system standard, governing the full lifecycle under Plan-Do-Check-Act, third-party auditable.
|
||
- Family: 23894 (AI risk, guidance), 42005 (impact assessment), 42006 (requirements for certification bodies), 42007 (AI conformity schemes), 38507 (board-level governance of AI), 5338 (AI lifecycle processes).
|
||
- **What JouleContract inherits:** the AIMS is the **wrapper** JouleContract operates inside; the amendment model (§5) is 42001 change control; the contract is a control object within an AIMS, not a competing system.
|
||
|
||
### 2.4 Assurance, Evidence, and Trust
|
||
|
||
- **ISAE 3000 / SOC 2** — the assurance-engagement model for independent attestation; JouleContract receipts are the evidence such an engagement reads.
|
||
- **eIDAS** — qualified electronic signatures, seals, and timestamps as the EU legal basis for the signed receipt; FIPS 140-3 validated cryptography for US federal boundaries.
|
||
- **in-toto / SLSA / DSSE / Sigstore** — the supply-chain provenance envelope the receipt is wrapped in at the recognized edge (§7).
|
||
- **ISO 19011** — guidance for auditing management systems; the audit is a query over the receipt log.
|
||
|
||
---
|
||
|
||
## 3. The Core Object
|
||
|
||
A JouleContract is a content-addressed object bound to a unit of work. It declares four obligations.
|
||
|
||
1. **Precondition (`pre`)** — what MUST hold for the transition to be admissible.
|
||
2. **Postcondition (`post`)** — what MUST hold once the transition completes.
|
||
3. **Invariant (`inv`)** — what MUST hold throughout, and MUST survive the boundary unchanged.
|
||
4. **Joule ceiling (`ceiling`)** — the maximum energy, in the EOC joule unit, the transition is permitted to spend, expressed as an EnPI against a declared EnB (ISO 50001).
|
||
|
||
The first three are the inheritance of Hoare logic and Design by Contract (§9); they are also the obligations an IEC 61508 assurance case discharges. The fourth is the energy coordinate (§4).
|
||
|
||
**Identity.** A contract MUST be content-addressed by the SHA-256 digest of its canonical serialization. References MUST be by digest.
|
||
|
||
**Correctness stays the verifier's.** A contract states a specification; it does not certify itself. A proof is not a specification: discharging an obligation establishes that an implementation satisfies the stated pre/post/invariant, not that those were the right obligations. Conformant systems MUST keep correctness with an independent verifier of record (§6). This mirrors the independent functional-safety assessment of IEC 61508, the effective challenge of SR 11-7, and the independent attestation of ISAE 3000.
|
||
|
||
---
|
||
|
||
## 4. Energy as Coordinate
|
||
|
||
Energy is not a feature; it is the coordinate system. `pre`/`post`/`inv` describe *what* must survive a transition. The joule is the only unit present in *every* transition across *every* domain — a refactor, a settlement, a drug infusion, a shift handoff are all energy becoming work. That shared unit is what lets transitions from unrelated domains share one ledger and one audit.
|
||
|
||
### 4.1 The ceiling is the one measured clause
|
||
|
||
Correctness clauses are binary. The joule ceiling, as an EnPI against an EnB, produces a **measured residual** (allowed − spent). That residual is the continuous signal correctness cannot give, and it is what ISO 50001 improvement loops and CSRD/ESRS E1 disclosures sum over.
|
||
|
||
### 4.2 Energy provenance = ISO/IEC 30134 measurement category
|
||
|
||
Every joule figure MUST carry a provenance tag corresponding to an ISO/IEC 30134 measurement category:
|
||
|
||
- **`Metered` (HwShunt)** — measured at hardware; highest category.
|
||
- **`ModelBased`** — derived from a model anchored to a metered baseline for a comparable workload.
|
||
- **`Unaccounted` (Estimator)** — estimated from published energy-traceability methods where the substrate exposes no measurement (opaque cloud VMs, containers); ISO/IEC 30134's unaccounted-energy rules apply.
|
||
|
||
An `Unaccounted` figure is defensible **only** while the tag travels with the number. Downstream consumers MUST NOT treat it as `Metered`. The failure mode prevented is estimation laundering itself into apparent measurement.
|
||
|
||
---
|
||
|
||
## 5. The Receipt, the Amendment, and the Ratchet
|
||
|
||
The contract is the **promise**. The receipt is the **record that the promise held**, and the unit of evidence for all three inherited management systems at once. A compliance report (SOC 2, ConMon, Part 11, CSRD, a 61508 assurance case, an ISO 50001 review) is a *projection over the receipt log*.
|
||
|
||
### 5.1 Required receipt fields
|
||
|
||
`contract` (digest) · `transition` (JouleCode digest) · `discharge` (per obligation: the JouleProof tier that closed it, or `undischarged` + reason) · `execution` (JouleClaw tier(s)) · `joules_spent` · `joules_allowed` (the EnPI ceiling in force) · `residual` · `provenance` (§4.2) · `grid_mix` (OPTIONAL, EOC) · `verifier` (independent, §6) · `signature` (§7).
|
||
|
||
### 5.2 Amendment model (ISO 42001 change control)
|
||
|
||
A rigid contract is a state, and states break; a silently soft one is no contract. JouleContract is **amendable**, and every amendment is itself a signed JouleCode transition chained to the prior contract digest — attributed, reasoned, signed. The contract is its own amendment log.
|
||
|
||
**Breach is redefined:** not "the ceiling was exceeded" or "a postcondition failed," but **deviation without a matching amendment**. A measured overrun accompanied by a signed, reasoned amendment is governed change, not breach. This is functional-safety modification control and ISO 42001 change management expressed as a ledger.
|
||
|
||
### 5.3 Enforcement at receipt-time; ratchet at improvement-time
|
||
|
||
Enforcement is at **receipt-time** (observed), not compile-time (rigid), so adaptive systems bend rather than break — the IEC 61508 principle that a failure occurs in a predictable, safe, recorded manner. Over successive transitions the ceiling MAY ratchet toward the measured floor (the ISO 50001 continual-improvement loop), rejecting regressions, without touching correctness obligations.
|
||
|
||
---
|
||
|
||
## 6. Independent Verification
|
||
|
||
Conformant systems MUST designate a **verifier of record** distinct from the generator of the work. Where one agent drafts both obligation and implementation, an independent checker MUST discharge the obligation, or self-certification results. This single requirement satisfies three recognized regimes at once: the independent functional-safety assessment (IEC 61508), the effective challenge of model risk management (SR 11-7), and the independent assurance engagement (ISAE 3000) — and corresponds to the receiver-confirmation step ("synthesis by receiver") in clinical handoff protocols such as I-PASS.
|
||
|
||
---
|
||
|
||
## 7. Wire Format and Recognized-Edge Emission
|
||
|
||
Novel core, recognized edge. The boundary MUST speak vocabularies auditors and pipelines already accept.
|
||
|
||
- Contract and receipt serialize as canonical JSON; the receipt MAY be a JSON Web Proof for selective disclosure.
|
||
- A receipt MUST be expressible as an **in-toto Statement** with a `JouleContract` predicate type, wrapped in **DSSE**, and MAY carry a **SLSA** provenance predicate.
|
||
- Signatures MUST be verifiable with standard tooling (Sigstore/cosign). For EU legal effect, signatures SHOULD be **eIDAS** qualified electronic signatures or seals with qualified timestamps; for US federal boundaries, **FIPS 140-3** validated cryptography.
|
||
- Governance mappings (§8) SHOULD be emitted as **OSCAL**.
|
||
- Energy figures SHOULD be reportable as ISO/IEC 30134 KPIs (PUE/CUE) and ISO 50001 EnPIs.
|
||
|
||
---
|
||
|
||
## 8. Regulatory and Standards Mapping
|
||
|
||
Each element corresponds to an obligation an existing recognized standard already imposes. This is the floor regulated buyers recognize on sight.
|
||
|
||
| JouleContract element | Recognized standard / control |
|
||
|---|---|
|
||
| Discharged obligation (pre/post/inv) + SIL grade | IEC 61508 assurance case & SIL; ISO 26262 / IEC 62304 (sector) |
|
||
| Independent verifier of record | IEC 61508 FS assessment; SR 11-7 effective challenge; ISAE 3000 |
|
||
| Signed receipt per transition | 21 CFR Part 11 (e-records/e-sigs); NIST 800-53 **AU**; eIDAS |
|
||
| Amendment = signed transition | ISO/IEC 42001 change control; NIST 800-53 **CM**; SOX; DORA |
|
||
| Continuous receipt log | NIST 800-53 **CA** (ConMon); EU AI Act record-keeping; ISO 19011 audit |
|
||
| Joule ceiling as EnPI vs EnB | ISO 50001 EnMS; energy-performance objectives |
|
||
| Energy provenance category | ISO/IEC 30134 measurement categories & unaccounted-energy rules |
|
||
| Residual + grid-mix | CSRD / ESRS E1; ISO/IEC 30134-8 CUE |
|
||
| Whole-system governance wrapper | ISO/IEC 42001 AIMS (certifiable per 42006) |
|
||
|
||
---
|
||
|
||
## 9. Lineage
|
||
|
||
- **Hoare logic; Dijkstra's weakest precondition** — the {P} C {Q} obligation generator.
|
||
- **Meyer, Design by Contract (Eiffel)** — pre/post/invariant in the signature; JouleContract adds the joule ceiling as another contract clause.
|
||
- **Knuth, literate programming (1984)** — intent is the durable source; code is extracted from it.
|
||
- **Governance lineage** — IEC 61508 (1998–2010), ISO 50001 (2018), ISO/IEC 42001 (2023): the standard does not reinvent these; it composes them.
|
||
|
||
On the name: "pseudocode" is declined as an homage. *Pseudo* means false; this is the source of truth in the stack — the most rigorous artifact, not the least.
|
||
|
||
---
|
||
|
||
## 10. Conformance: a Composed Profile, not a Single Ladder
|
||
|
||
A JouleContract Assurance Profile is a **triple**, because flattening these axes hides exactly what an auditor needs:
|
||
|
||
```
|
||
JCAP = ⟨ Safety class, Energy class, Governance class ⟩
|
||
```
|
||
|
||
- **Safety class** — the rigor of obligation discharge, expressed as an **IEC 61508 SIL (1–4)** or sector equivalent. SIL 4 implies formal discharge (theorem proving / model checking) by an independent verifier.
|
||
- **Energy class** — the **ISO/IEC 30134 measurement category** backing the joule figure: `Metered` > `ModelBased` > `Unaccounted`.
|
||
- **Governance class** — the **ISO/IEC 42001** conformance maturity of the surrounding AIMS, from declared to certified (per 42006).
|
||
|
||
A `⟨SIL-3, Metered, certified⟩` transition is a categorically stronger object than `⟨SIL-3, Unaccounted, declared⟩`, and the profile says so. There is no single number to game.
|
||
|
||
---
|
||
|
||
## 11. Security Considerations
|
||
|
||
- **Signature integrity** — trust derives from the signature and identity binding; key-ID hints MUST NOT be trusted; verifiers MUST resolve to a trusted key (eIDAS trust list or Sigstore root).
|
||
- **Unaccounted-energy abuse** — `Unaccounted` figures are unverifiable at the substrate and could be under-reported; they SHOULD be periodically reconciled against `Metered` baselines per ISO/IEC 30134, with large unexplained residual swings flagged.
|
||
- **Amendment flooding** — amendments could retroactively legitimize breaches; they are themselves attributed, signed, independently challengeable transitions, and an audit can detect amendments that consistently trail their own overruns.
|
||
- **Self-certification drift** — the independent-verifier requirement (§6) is the only barrier to silent self-certification and MUST NOT be waived at SIL-3 or above.
|
||
|
||
---
|
||
|
||
## 12. Open Questions
|
||
|
||
- Granularity: at what transition size does proof-per-transition stay tractable under JouleProof's cheapest-sufficient cascade, and where must obligations batch?
|
||
- Cross-domain unit reconciliation: how are operational work-joules (a handoff) and compute-joules (a refactor) normalized on one ledger via ISO 50001 EnBs without false equivalence?
|
||
- First mandate vector: which authority first references a JouleContract Assurance Profile in a conformity scheme (ISO/IEC 42007) or procurement clause — since adoption timeline is governed by that reference, not by quality.
|
||
|
||
---
|
||
|
||
## Appendix A — Example (informative)
|
||
|
||
```json
|
||
{
|
||
"joulecontract": "0.2.0",
|
||
"subject": "fn settle_batch(orders) -> Settlement",
|
||
"pre": ["all orders signed", "sum(debits) == sum(credits)"],
|
||
"post": ["ledger balanced", "each order has a settlement id"],
|
||
"inv": ["no order in two settlements", "no negative balance at any step"],
|
||
"ceiling": { "enpi_joules": 3.0, "unit": "EOC-J", "enb_ref": "sha256:ab19…" },
|
||
"amends": "sha256:9b2c…"
|
||
}
|
||
```
|
||
|
||
```json
|
||
{
|
||
"ReceiptPayload": {
|
||
"contract": "sha256:1f4a…",
|
||
"transition":"sha256:77de…",
|
||
"discharge": [
|
||
{ "obligation": "ledger balanced", "tier": "JP-L1-typecheck", "result": "closed" },
|
||
{ "obligation": "no negative balance","tier": "JP-L3-smt", "result": "closed" }
|
||
],
|
||
"execution": ["JC-L0-cache", "JC-L3-model"],
|
||
"joules_spent": 2.1,
|
||
"joules_allowed": 3.0,
|
||
"residual": 0.9,
|
||
"provenance": "Metered",
|
||
"grid_mix": { "renewable": 0.61, "region": "eu-w-1" },
|
||
"verifier": "did:web:audit.example.org",
|
||
"profile": { "safety": "SIL-3", "energy": "Metered", "governance": "certified" },
|
||
"signature": "eIDAS-QES…"
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
*End of draft v0.2.0. Re-founded on IEC 61508, ISO 50001 / ISO/IEC 30134, and ISO/IEC 42001. Sections 10 and 12 invite revision.*
|