open-standards/joulecontract/archive/joulecontract-spec-v0.4.md

# JouleContract

**An Open Standard for Energy-Accounted Interface Contracts**

| | |
|---|---|
| **Status** | Draft for Review |
| **Version** | 0.4.0 — amends 0.3.0 (see Amendment Log, §15) |
| **Canonical home** | `joulecontract.transaction.science` |
| **License** | Specification text: CC-BY-4.0 · Reference implementation: Apache-2.0 (Rust) |
| **Stewardship** | The protocol is ownerless. Stewardship is an office, not an owner (§11). Transaction Science, Inc. is the inaugural 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. |

---

## 0. Self-Hosting Clause

This specification is governed by its own amendment model. Each published version is a content-addressed document; each new version is an attributed, reasoned, signed amendment chained to the digest of the version it amends (§15). No version of this standard depends on any person, organization, algorithm, or jurisdiction remaining in place: every named fixed point in this document is an **office or a parameter with a defined succession or migration rule**, not a dependency.

---

## 1. Design Principle: Inherit, Don't Invent

The three concerns this standard serves — energy optimization, safety, auditability — each have a mature, internationally recognized management-system standard. JouleContract does not replace them. It is the technical control object whose single signed receipt simultaneously discharges evidence for functional safety (IEC 61508), energy management (ISO 50001 with ISO/IEC 30134), and AI governance (ISO/IEC 42001) — three programs collapsed into three projections of one receipt log.

Where an inherited standard is superseded, the inheritance binds to the **current edition** of that standard or its formally designated successor; this specification names roles ("the functional-safety standard," "the energy-management system"), with current editions listed in the non-normative Register (§13), so the standard does not break when the canon revises.

---

## 2. Normative Inheritance

Conformant implementations MUST be expressible in terms of the following, by role:

### 2.1 Safety — the functional-safety standard (currently IEC 61508; sector derivations where applicable)
Goal-based assurance: risk-reduction targets demonstrated through structured evidence across a defined lifecycle, with formal methods (model checking, theorem proving) admitted as assurance techniques, graded by Safety Integrity Level (SIL 1–4). JouleContract inherits the assurance-case-as-evidence model (the receipt log *is* the assurance case), the SIL grade, and RFC 2119 normative discipline. The objective-based discipline of the avionics derivation (DO-178C/ED-12C: objectives outlive procedures) and its tool-qualification and formal-methods supplements (DO-330 tool qualification, DO-333 formal-methods soundness) are inherited where high assurance is claimed (§6.1, §10).

### 2.2 Energy — the energy-management system (currently ISO 50001) + the measurement-KPI series (currently ISO/IEC 30134)
The joule ceiling is an **Energy Performance Indicator (EnPI)** against a declared **Energy Baseline (EnB)**; the ratchet (§5.3) is the continual-improvement loop; the provenance tag (§4.2) is the measurement category, with `Unaccounted` bound to the series' unaccounted-energy rules.

### 2.3 Governance — the AI management system (currently ISO/IEC 42001 and family: 23894, 42005, 42006, 42007, 38507, 5338)
The AIMS is the wrapper JouleContract operates inside; the amendment model (§5.2) is its 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 (independent attestation reads the receipts) · eIDAS qualified signatures/seals/timestamps (EU legal effect) and FIPS 140-3 validated cryptography (US federal boundaries) · in-toto / SLSA / DSSE / Sigstore (supply-chain envelope at the recognized edge, §7) · NIST SP 800-218 SSDF and the 800-218A generative-AI community profile (the organizational practices the receipt log evidences) · ISO 19011 (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, declaring **five** obligations:

1. **Precondition (`pre`)** — MUST hold for the transition to be admissible.
2. **Postcondition (`post`)** — MUST hold once the transition completes.
3. **Invariant (`inv`)** — MUST hold throughout and survive the boundary unchanged.
4. **Frame (`frame`)** — the declared **mutable footprint**: the complete set of state the transition is permitted to touch. All state outside the frame is implicitly invariant. (See §3.4.)
5. **Joule ceiling (`ceiling`)** — maximum energy, in the EOC joule unit, expressed as an EnPI against a declared EnB.

### 3.1 Identity and cryptographic agility

A contract MUST be content-addressed by the digest of its canonical serialization. The digest MUST be **algorithm-prefixed** (multihash-style: `sha2-256:…`, `sha3-256:…`), and conformant implementations MUST support digest-algorithm migration: when an algorithm is deprecated by the steward (§11) on published cryptanalytic grounds, existing objects are re-anchored by a signed cross-digest amendment mapping old identity to new. No object's validity depends on the permanence of any single hash function or signature scheme.

### 3.2 Correctness stays the verifier's

A contract states a specification; it does not certify itself. A proof is not a specification: discharge establishes that an implementation satisfies the stated obligations, not that those were the right obligations. Conformant systems MUST keep correctness with an independent verifier of record (§6).

### 3.3 Composition

Contracts compose. A contract over a composed transition (a batch, a pipeline, a workflow) is the conjunction of its components' obligations with a ceiling no greater than the sum of component ceilings, and a frame no larger than the union of component frames. Composition is associative; receipts for a composed transition MUST reference the component receipts or carry the composed discharge directly. **Decomposition** — discharging one high-assurance obligation across redundant lower-rated elements (the ISO 26262 ASIL-decomposition pattern) — is expressed as conjunction over the composing contracts, not as new machinery; the profile (§10) records the rated contribution of each element.

### 3.4 The frame obligation — no unintended function

`pre`/`post`/`inv` establish what a transition guarantees; none of them bounds what it may *additionally* do. A transition can satisfy every stated obligation while mutating state nobody declared — the frame problem. The frame closes it: anything not named in `frame` is implicitly invariant, so an effect outside the declared footprint is a breach (§5.2) exactly as a violated postcondition is. This is the standard's form of two independently-evolved canon requirements — DO-178C's *absence of unintended function* (no dead, deactivated, or extraneous behavior) and ISO 26262's *freedom from interference* between partitions. Frame discharge MUST be recorded on the receipt at a tier (§5.1); where a transition's full footprint cannot be statically bounded, the frame MUST be declared `unbounded` with a reason, which is itself an auditable disclosure rather than a silent omission.

---

## 4. Energy as Coordinate

Energy is the coordinate system, not a feature. The joule is the only unit present in every transition in every domain; that shared unit is what places a refactor, a settlement, and a clinical handoff on one ledger under one audit.

### 4.1 The ceiling is the one measured clause
Correctness clauses are binary; the ceiling yields a **measured residual** (allowed − spent) — the continuous signal that improvement loops and energy disclosures (CSRD/ESRS E1) sum over.

### 4.2 Energy provenance = measurement category
Every joule figure MUST carry one of: **`Metered`** (hardware-measured) > **`ModelBased`** (anchored to a metered baseline for a comparable workload) > **`Unaccounted`** (estimated by published energy-traceability methods where the substrate exposes nothing). The tag MUST travel with the number; downstream consumers MUST NOT promote a category. The failure prevented is estimation laundering itself into apparent measurement.

### 4.3 Cross-domain ledger rule (resolved by principle)

The ledger is **additive across domains and comparative only within an EnB scope.**

The joule is an SI unit; sums of joules are physically meaningful regardless of domain, so a global ledger MAY total compute-joules and operational work-joules for aggregate disclosure. But an EnPI is meaningful only against its own baseline: a contract's residual is comparable to other residuals **under the same EnB**, and never constitutes an equivalence claim across EnBs. A handoff's joules and a refactor's joules add on the ledger; they are never exchanged, ranked, or netted against each other. Receipts MUST carry the EnB reference, and conformant ledgers MUST refuse cross-EnB comparison operations while permitting cross-EnB summation. (No false equivalence is possible by construction, because the comparison operation that would assert it is not defined.)

### 4.4 Resource-bound lineage (precise claim)
Resource-bound verification is not new: the functional-safety canon already verifies **time** (WCET) and **memory** (stack/heap bounds) as objectives. JouleContract does not claim to verify resources for the first time. It **generalizes resource-bound verification from time and memory to energy, and makes the bound a billed, receipted, ratcheting EnPI** rather than a one-time certification objective.

---

## 5. The Receipt, the Amendment, and the Ratchet

The contract is the promise; the receipt is the record that the promise held — the unit of evidence for all three inherited management systems at once. Any compliance report is a projection over the receipt log.

### 5.1 Required receipt fields
`contract` · `transition` · `generator` (§5.1.1) · `discharge` (per obligation — `pre`/`post`/`inv`/`frame` — each carrying: tier that closed it or `undischarged` + reason; the tier's **qualification** reference (§6.1); and an **independence** flag (§6.2)) · `execution` · `joules_spent` · `joules_allowed` · `residual` · `provenance` · `enb_ref` · `grid_mix` (OPTIONAL) · `verifier` · `profile` (§10) · `signature`.

#### 5.1.1 Generator identity
The receipt MUST identify the producer of the work: the AI system or human author (system/model identity + version digest), the generation context, and the human principals involved — AI-BOM-compatible, the same producer-identity that SLSA/in-toto carry for builders and OWASP AISVS requires for AI-generated artifacts. A correctness-and-energy receipt that names only its verifier and omits its generator would be weaker provenance than the plain supply-chain attestation it wraps; the `generator` field closes that.

### 5.2 Amendment model
Every amendment to a contract — including to its ceiling or its frame — is an attributed, reasoned, signed transition chained to the prior digest. The contract is its own amendment log. **Breach is deviation without a matching amendment**; a measured overrun, or an out-of-frame effect, with a signed, reasoned amendment is governed change. (This is functional-safety modification control and AIMS change control expressed as a ledger.)

### 5.3 Enforcement and ratchet
Enforcement is at receipt-time (observed), never compile-time (rigid): deviations are recorded, the system keeps running, resolution is amend-or-fix. Over successive transitions the ceiling MAY ratchet toward the measured floor and reject regressions, without touching correctness obligations.

### 5.4 Granularity (resolved by principle)

The standard fixes no transition granularity. Granularity is discovered economically by the cheapest-sufficient discharge cascade: where per-transition discharge is cheaper than the obligation's risk warrants, transitions stay fine-grained; where it is not, obligations batch by composition (§3.3) until discharge clears at an acceptable tier, and the receipt records the batch boundary. The cascade's disclosed escalation makes the chosen granularity itself auditable. Conformance to a named coding-rule ruleset (MISRA C/C++, CERT, NASA Power of Ten) is naturally a cheap deterministic discharge tier and is carried in the `discharge` tier field like any other; JouleContract neither replaces nor contains such rulesets.

---

## 6. Independent Verification — no single verifier as point of failure

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. At SIL-3 and above, the verifier of record MUST be replaceable without invalidating prior receipts (verification authority attaches to the *office and its published keys*, not the incumbent), and implementations SHOULD support **quorum verification** (k-of-n independent verifiers) so that no single verifier's compromise, capture, or disappearance is a point of failure. This one requirement discharges the independent functional-safety assessment (IEC 61508), effective challenge (SR 11-7), and independent attestation (ISAE 3000), and corresponds to receiver-confirmation ("synthesis by receiver") in clinical handoff protocols such as I-PASS.

### 6.1 Qualification of the discharge tiers
A discharge verdict trusted without subsequent re-verification makes the tier that produced it a **qualification target** — the DO-330 tool-qualification lesson (TQL-1..5) and the DO-333 requirement of *soundness evidence* that a formal method "will never provide unwarranted confidence," echoed by ISO 26262's tool confidence levels. Therefore each `discharge` entry on a receipt MUST reference the qualification or soundness attestation of the tier that closed it (e.g., the qualification record of an SMT backend, a type checker, a static analyzer, or a model checker). An unqualified tier MAY close an obligation, but the receipt MUST record it as unqualified; high-assurance profiles (§10) MAY require a qualified tier per obligation. The cascade is not exempt from the standard it serves.

### 6.2 Independence per obligation
Independence is declared **per discharge**, not only globally. The functional-safety canon requires independence (verifier ≠ developer) on specific objectives at the highest assurance levels (DO-178C DAL A/B), not uniformly. Each `discharge` entry therefore carries an independence flag; the profile (§10) states the independence required per obligation at a given safety class.

### 6.3 Security of the generation loop (security considerations)
JouleContract secures the *receipt* (signatures, amendment-flood resistance, estimator-laundering prevention) but the *generator* is itself an attack surface — goal hijacking, tool misuse, context/memory poisoning, rogue sub-agents (OWASP AISVS, OWASP Agentic Top 10). JouleContract does not ignore this surface; it **composes over it**: a generator is itself a transition-executing system and SHOULD operate under its own JouleContract, whose obligations bound tool scope, context integrity, and escalation authority, and whose receipts feed the same log. No new machinery is required — the producing agent is governed by the same object it produces.

---

## 7. Wire Format and Recognized-Edge Emission

Novel core, recognized edge. Contract and receipt serialize as canonical JSON (JSON Web Proof permitted 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 verify with standard tooling; eIDAS qualified signatures/seals for EU legal effect; FIPS 140-3 validated cryptography for US federal boundaries; signature schemes are algorithm-agile under §3.1. Governance mappings SHOULD emit as OSCAL; energy figures SHOULD be reportable as ISO/IEC 30134 KPIs and ISO 50001 EnPIs.

---

## 8. Regulatory and Standards Mapping

| JouleContract element | Recognized standard / control |
|---|---|
| Discharged obligation + SIL grade | IEC 61508 assurance case & SIL; ISO 26262 / IEC 62304 / EN 50128 / DO-178C (sector) |
| Frame (no unintended function) | DO-178C absence of unintended function; ISO 26262 freedom from interference |
| Discharge-tier qualification | DO-330 TQL; DO-333 formal-methods soundness; ISO 26262 TCL |
| Independent verifier / quorum / per-obligation independence | IEC 61508 FS assessment; DO-178C DAL-A/B independence; SR 11-7; ISAE 3000 |
| Generator identity (AI-BOM) | OWASP AISVS App. C; SLSA/in-toto builder identity; NIST SP 800-218A |
| Signed receipt per transition | 21 CFR Part 11; 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 |
| Generation-loop security | OWASP AISVS; OWASP Agentic Top 10 |
| Joule ceiling as EnPI vs EnB | ISO 50001 |
| Energy provenance category | ISO/IEC 30134 measurement categories & unaccounted-energy rules |
| Residual + grid-mix | CSRD / ESRS E1; ISO/IEC 30134-8 (CUE) |
| Governance wrapper | ISO/IEC 42001 AIMS (certifiable per 42006); NIST SP 800-218 SSDF |

---

## 9. Lineage

Hoare logic and Dijkstra's weakest precondition (the obligation generator) · Meyer's Design by Contract (pre/post/invariant in the signature; frame and joule ceiling are two more clauses) · the frame problem (McCarthy & Hayes) and separation logic's frame rule (the mutable-footprint discipline) · Knuth's literate programming (intent is the durable source; code is extracted) · the governance canon itself (IEC 61508 / DO-178C; ISO 50001; ISO/IEC 42001), composed rather than reinvented. The name "pseudocode" is declined as homage: *pseudo* means false, and this is the most rigorous artifact in the stack, not the least.

---

## 10. Conformance: a Composed Profile

```
JCAP = ⟨ Safety class, Energy class, Governance class ⟩
```

Safety class: SIL 1–4 (or sector equivalent; SIL 4 implies formal discharge by independent/quorum verification, qualified tiers per §6.1, frame discharge, and per-obligation independence per §6.2). Energy class: `Metered` > `ModelBased` > `Unaccounted`. Governance class: AIMS maturity from declared to certified. A `⟨SIL-3, Metered, certified⟩` transition is categorically stronger than `⟨SIL-3, Unaccounted, declared⟩`, and the profile says so. There is no single number to game.

### 10.1 The adequacy residual (named, not claimed closed)
JouleContract discharges *stated* obligations; it does not, and cannot, certify that the obligation set is complete against the behavior space. This residual is shared by the entire assurance canon — it is DO-178C's requirements-validation judgment and the ML-domain's operational-design-domain (ODD) coverage question, neither of which any standard fully mechanizes. A standard that silently implied completeness it cannot have would contain illogic; JouleContract instead **names the limit**. A contract MAY carry an optional ODD-style domain annex declaring the input/operating domain over which its obligations are asserted to hold, making the boundary of the claim itself auditable.

---

## 11. Stewardship Succession — no organization as point of failure

Stewardship is an **office**. The protocol is ownerless; the steward maintains the Register (§13), publishes algorithm deprecations (§3.1), and convenes amendment review. The office is bound by:

- **Fork-freedom.** The specification license (CC-BY-4.0) and reference implementation license (Apache-2.0) guarantee that any party may continue the standard if the steward fails, defects, or captures. The ultimate succession mechanism is the license itself.
- **Succession rule.** The steward MAY transfer the office by signed amendment to this specification. If the steward is dissolved or unresponsive for a published timeout, any party maintaining a conformant reference implementation MAY assume interim stewardship by signed public declaration; competing claims resolve by implementer adoption, which the amendment log makes auditable.
- **No retroactive authority.** A steward cannot invalidate prior receipts or prior versions; all authority is forward-looking and exercised only through traced amendments.

---

## 12. Security Considerations

Beyond the generation-loop surface (§6.3): amendment flooding is bounded by attribution and signature (an unsigned or unattributed amendment is not a valid transition); estimator abuse is bounded by the non-promotion rule (§4.2); verifier capture is bounded by office/key separation and quorum (§6); tool-trust inflation is bounded by mandatory tier-qualification disclosure (§6.1). The standard's security posture is that every trusted output names what makes it trustworthy, or is recorded as untrusted — there is no implicit trust anywhere in the receipt.

---

## 13. Register (non-normative)

Current editions of inherited standards as of this version: IEC 61508:2010 (Ed. 2) · DO-178C/ED-12C + DO-330/331/332/333 · ARP4754A; ED-324/ARP6983 (in development, first publication expected 2026) · ISO 26262 · IEC 62304 · EN 50128 · ISO 50001:2018 · ISO/IEC 30134-2:2026 · ISO/IEC 42001 (current edition; EN ISO/IEC 42001:2026 in the EU) · ISO/IEC 42005:2025, 42006:2025 · NIST SP 800-218 + 800-218A · OWASP AISVS + Agentic Top 10 (2026) · eIDAS (Reg. 910/2014 as amended) · FIPS 140-3 · SLSA v1.2 · RFC 2119/8174. The Register is updated by steward amendment and never alters normative text by itself.

---

## 14. Lineage of this document's own holes (informative)

v0.4 closes six gaps surfaced by diffing v0.3 against the global AI-coding and regulated-code canons. Recording where the holes came from is itself the self-hosting discipline: the regulated canon, older and bloodier, caught the forty-year-old lessons the AI-coding canon has not met (the frame problem; verifier-tool qualification); the AI-coding canon caught what the regulated canon has not yet faced (generator identity; the adversarial generation loop). The standard improves by being adversarially diffed, not by being defended.

---

## 15. Amendment Log

Each entry: version, amends-digest, change, reason. The log is normative history; the standard practices its own §5.2.

**v0.4.0** — amends `sha2-256:<digest of v0.3.0>`
1. **Added `frame` as the fifth core obligation (§3 item 4, §3.4); updated composition (§3.3) and the profile (§10).** *Reason:* pre/post/inv bound what a transition guarantees but not what it may additionally touch; a transition could satisfy every stated obligation and still cause arbitrary unstated effect (the frame problem). DO-178C "absence of unintended function" and ISO 26262 "freedom from interference" are two independent canon proofs that this clause is mandatory at high assurance. Deepest hole the v0.3 diff found.
2. **Added `generator` to required receipt fields (§5.1, §5.1.1).** *Reason:* OWASP AISVS and SLSA/in-toto both carry producer identity; a receipt that named only its verifier was weaker provenance than the plain attestation it wraps.
3. **Added discharge-tier qualification (§6.1); each `discharge` references the qualification/soundness attestation of its tier.** *Reason:* a verdict trusted without re-verification makes its producer a qualification target (DO-330 TQL, DO-333 soundness, ISO 26262 TCL); an unqualified cascade is an unqualified tool in every regulated reading. The cascade is not exempt from the standard it serves.
4. **Added per-obligation independence (§6.2); independence flag per discharge.** *Reason:* DAL-A/B independence is per-objective, not global; a single global verifier flag understated the requirement.
5. **Added generation-loop security as composition, not new machinery (§6.3), and a Security Considerations section (§12).** *Reason:* the producing agent is an attack surface (OWASP AISVS / Agentic Top 10); JouleContract composes over it by governing the generator under its own contract rather than ignoring it.
6. **Named the adequacy residual (§10.1) with an optional ODD-style domain annex.** *Reason:* obligation-set completeness against the behavior space is unmechanizable and shared by the whole canon (DO-178C requirements validation, ML ODD coverage); silently implying completeness would be illogic, so the limit is named rather than hidden.
7. **Minor:** added the resource-bound precise claim (§4.4); coding-rule rulesets (MISRA/CERT/Power of Ten) as a discharge tier (§5.4); ASIL-decomposition as a composition pattern (§3.3); NIST SP 800-218/218A and OWASP rows in §8; §14 recording the provenance of v0.4's own repairs; renumbered Register→§13, Amendment Log→§15 to admit §12 Security Considerations and §14.

**v0.3.0** — amends `sha2-256:<digest of v0.2.0>`. Added the Self-Hosting Clause; cryptographic agility (algorithm-prefixed digests + migration); cross-domain ledger rule (additive across domains, comparative only within an EnB); economic granularity; verifier office + quorum; stewardship as office with succession and fork-freedom; inheritance by role with a Register; removed market-timing content; added composition (§3.3).

**v0.2.0** — amends `sha2-256:<digest of v0.1.0>`. Re-founded all structure on the recognized canon (IEC 61508, ISO 50001/30134, ISO/IEC 42001); replaced the invented conformance ladder with the composed profile.

**v0.1.0** — genesis. Core object (pre/post/inv/ceiling), receipt, amendment-as-transition, breach redefinition, energy-as-coordinate, verifier-of-record, recognized-edge emission.

---

## Appendix A — Example (informative)

```json
{
  "joulecontract": "0.4.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"],
  "frame": ["ledger table", "settlement index"],
  "ceiling": { "enpi_joules": 3.0, "unit": "EOC-J", "enb_ref": "sha2-256:ab19…" },
  "amends": "sha2-256:9b2c…"
}
```

```json
{
  "ReceiptPayload": {
    "contract":  "sha2-256:1f4a…",
    "transition":"sha2-256:77de…",
    "generator": {
      "system": "joulecode-agent",
      "model": "claude-opus-4-8",
      "version_digest": "sha2-256:5c0d…",
      "human_principals": ["did:web:eng-a.example"],
      "context": "ticket SETL-4821"
    },
    "discharge": [
      { "obligation": "ledger balanced",     "tier": "JP-L1-typecheck", "result": "closed", "qualification": "sha2-256:q1…", "independent": true  },
      { "obligation": "no negative balance", "tier": "JP-L3-smt",       "result": "closed", "qualification": "sha2-256:q2…", "independent": true  },
      { "obligation": "frame: ledger+index", "tier": "JP-L2-separation","result": "closed", "qualification": "sha2-256:q3…", "independent": false }
    ],
    "execution": ["JC-L0-cache", "JC-L3-model"],
    "joules_spent": 2.1,
    "joules_allowed": 3.0,
    "residual": 0.9,
    "provenance": "Metered",
    "enb_ref": "sha2-256:ab19…",
    "grid_mix": { "renewable": 0.61, "region": "eu-w-1" },
    "verifier": ["did:web:audit-a.example", "did:web:audit-b.example"],
    "profile": { "safety": "SIL-3", "energy": "Metered", "governance": "certified" },
    "signature": "eIDAS-QES…"
  }
}
```

---

*End of v0.4.0 — a traced amendment of v0.3.0 under the standard's own §5.2.*