open-standards/joulecontract/provenance/joulecontract-diff-v0.3-global.md

JouleContract v0.3 — Global Diff

Part A: against the global AI-coding standards & practice landscape. Part B: against the code standards of the highest-regulated ecosystems. Output: convergences (credited), JC-only differentiators (claimed precisely), gaps in JC (admitted), and proposed v0.4 amendments under the standard's own §5.2 traced-amendment model.

Method note: a diff that only finds wins is marketing. This one was run to find holes. It found three.

---

PART A — Diff vs. Global AI-Coding Standards & Practice

A1. Spec-Driven Development (GitHub Spec Kit, AWS Kiro, OpenSpec, BMAD, Tessl, Cursor rules, Augment Cosmos, Google Antigravity)

	Finding
Converges	Intent as source of truth; code as last-mile output; versioned spec; constitution/rules files as persistent constraints. JC's contract is the same move with teeth.
JC-only	The spec is enforced (receipt-time), checkable (obligations discharged by a cascade), energy-bearing (EnPI ceiling), and non-drifting by construction (a transition without a matching contract digest is a recorded deviation; SDD's known failure is spec/implementation drift within hours). SDD specs are prose; JC contracts are content-addressed obligations.
Gap in JC	None structural. SDD's superior ergonomics (EARS notation, requirements→design→tasks decomposition) are an authoring layer JC deliberately does not standardize; they can target JC as a compile target.

A2. Supply-Chain Provenance (SLSA v1.2, in-toto, Sigstore/cosign, DSSE, GitHub artifact attestations)

	Finding
Converges	Content-addressing, signed attestations, DSSE envelopes, identity-bound trust. JC mandates emission in exactly these formats at the recognized edge (§7).
JC-only	These attest origin (who/how/from-what), never correctness (no discharged obligation) and never cost (no energy). A SLSA provenance says the artifact came from this workflow; a JC receipt additionally says the transition held its invariants and what it spent.
Gap in JC	GAP-1: Generator identity. OWASP AISVS Appendix C requires AI-generated artifacts to carry signed metadata identifying the AI system that produced them, the generation context, and the humans involved (AI-BOM). The v0.3 receipt names the verifier but not the generator. SLSA/in-toto carry builder identity natively. JC must add a generator field (model/system identity + version digest + human principals) or its receipts are weaker provenance objects than the baseline they wrap.

A3. AI-Codegen Security Verification (OWASP AISVS; OWASP Agentic Top 10 ASI01–ASI10)

	Finding
Converges	Pipeline gating on signed metadata before promotion; trusted-verifier checks; audit records of human involvement.
JC-only	AISVS verifies the artifact and pipeline; JC additionally contracts the transition semantics (obligations + ceiling).
Gap in JC	GAP-2 (partial): Adversarial surface of the generation loop. AISVS/Agentic Top 10 enumerate attacks on the producing agent itself — goal hijacking, tool misuse, memory/context poisoning, rogue agents. JC §11 secures the receipt (signatures, amendment flooding, estimator abuse) but not the generator. Resolution: the generator is itself a transition-executing system and SHOULD operate under its own JouleContract (obligations on tool scope, context integrity, escalation); the diff makes explicit that JC composes over the generation loop rather than ignoring it. Security-considerations extension required.

A4. NIST SP 800-218A (SSDF Community Profile for Generative AI), EU AI Act logging, ISO/IEC 5338 / 42001 family

	Finding
Converges	800-218A augments the SSDF with AI-specific practices across the lifecycle for model producers, system producers, and acquirers. These are organizational practices; JC receipts are precisely the evidence objects those practices call for. Complementary, not competing: a JC receipt log is how an organization demonstrates 218A/EU-AI-Act record-keeping continuously instead of episodically.
JC-only	218A and the AI Act demand logging and traceability but define no signed, content-addressed, energy-accounted evidence unit. JC supplies the unit.
Gap in JC	None — by design JC is the artifact layer under these practice layers. The §8 mapping table should add the 218A row explicitly (minor amendment).

A5. Net of Part A

The AI-coding world has split intent (SDD) from origin (SLSA/in-toto) from practice (218A/42001). No instrument binds intent + origin + correctness + energy into one signed object per transition. JC's claim to that seam survives the diff, conditional on closing GAP-1 (generator identity) — without it, JC receipts are paradoxically weaker provenance than plain SLSA.

---

PART B — Diff vs. Highest-Regulated Code Ecosystems

B1. Avionics — DO-178C/ED-12C + DO-330/331/332/333; ARP4754A; incoming ED-324/ARP6983

The most evolved assurance regime in existence: objective-based (71 objectives at DAL A down to 26 at DAL D), consequence-graded (DAL A–E), with bidirectional requirements↔design↔code↔test traceability, structural coverage up to MC/DC with independence at Level A, configuration management, problem reporting, and certification liaison.

	Finding
Converges	Objective-based assurance ("objectives are more essential and stable than procedures") = JC's obligations-not-procedures stance. Bidirectional traceability = JC's contract→transition→receipt chain. DO-333's requirement of soundness evidence for any formal method = JouleProof's disclosed escalation with tier identity on the receipt. Consequence-graded rigor (DAL) = JC's SIL axis in the composed profile.
JC-only	(1) Energy: DO-178C verifies time and memory budgets (WCET, stack bounds) as objectives — the canon's nearest cousin — but has no energy objective, no billing unit, no residual, no ratchet. Precise claim: JC generalizes resource-bound verification from time/memory to energy and makes the bound a receipted, ratcheting EnPI. (2) Receipt-time amendment-matched breach: DO-178C change control exists (problem reports, baselines) but breach-as-deviation-without-amendment as a ledger primitive does not. (3) Continuous evidence: DO-178C evidence is assembled toward Stage-of-Involvement audits; JC evidence is emitted per transition. (4) Domain reach: DO-178C stops at airborne software; JC's transition covers non-code interface crossings.
Gaps in JC	GAP-3: Frame conditions / no unintended function. DO-178C requires demonstrating the software performs its intended function and only that — absence of unintended functionality, no dead/extraneous code. JC's pre/post/inv prove what is stated; nothing in v0.3 states what must NOT change. This is the frame problem, and it is the deepest hole the diff found: a transition can satisfy all stated obligations while doing arbitrary unstated harm. v0.4 MUST add a frame clause (the set of state the transition may touch; everything outside is implicitly invariant). GAP-4: Qualification of the verifier toolchain. DO-330 requires qualifying any tool whose output is trusted without subsequent verification (TQL-1..5); DO-333 demands soundness evidence that a formal method "will never provide unwarranted confidence." JouleProof's discharge verdict is exactly such trusted output — so the cascade tiers are qualification targets, and v0.3 never attests them. v0.4 MUST add tier attestation: each discharge on a receipt carries the qualification/soundness reference of the tier that produced it. GAP-5: Independence per obligation. DO-178C requires independence on specific objectives at DAL A/B (verifier ≠ developer, per objective). JC has a verifier-of-record and optional quorum globally, not per-obligation. Minor: the profile should permit an independence flag per discharge. GAP-6 (noted, not fully closable): coverage adequacy. MC/DC measures test adequacy against code structure; ED-324/ARP6983's ODD measures input-domain coverage for ML constituents. JC measures discharge of stated obligations and has no adequacy measure of the obligation set itself against the behavior space. Honest position: obligation-set adequacy is the residual human/assessor judgment in any assurance regime (DO-178C's requirements validation is the same residual); JC should name this limit rather than claim to close it, and admit ODD-style domain declarations as an optional contract annex.
Timing	ED-324/ARP6983 — the process standard for certifying AI in safety-related aeronautical products — first publication expected 2026, with EASA's learning-assurance (W-shaped) framework behind it and auditability among its High-Level Properties. The most regulated domain is, right now, defining what AI-produced work must carry to be certifiable. The receipt that answers it does not exist in their draft canon.

B2. Automotive — ISO 26262 (ASIL A–D)

	Finding
Converges	Safety case as structured evidence; tool confidence levels (TCL — same lesson as GAP-4); consequence grading.
JC-only	As B1; additionally, 26262's freedom from interference between criticality partitions is a frame-condition cousin — which 26262 has and JC v0.3 lacks (reinforces GAP-3).
Gap in JC	ASIL decomposition (splitting a high requirement across redundant lower-rated elements) has no JC analogue; resolution: composition (§3.3) already permits conjunction — v0.4 should note decomposition as a profile-level pattern, not invent new machinery.

B3. Medical — IEC 62304 + FDA software guidance

	Finding
Converges	Safety classes (A/B/C) = profile grading; 21 CFR Part 11 already in JC's §8 map.
JC-only / reframe	62304's SOUP (Software Of Unknown Provenance) regime is the sleeper finding: AI-generated code is definitionally SOUP unless provenance attaches. A JC receipt converts SOUP into known-provenance software with a discharged obligation and an energy cost — i.e., JC is the instrument by which AI-generated code becomes admissible at all under 62304 without per-line human re-derivation. This is an advantage to state, not a gap to fix.
Gap in JC	None beyond GAP-3/4 (which apply across all of Part B).

B4. Rail — EN 50128/50657

	Finding
Converges	The technique tables — formal proof "Highly Recommended" at SIL 3–4 — are the canon's existing endorsement of JC's discharge cascade at high assurance.
JC-only	As B1.
Gap in JC	None new.

B5. Coding-rule layer — MISRA C/C++, CERT, NASA Power of Ten

	Finding
Relation	Orthogonal layer: language-subset and pattern rules. JC neither replaces nor contains them; static-analysis conformance to a named ruleset is naturally a JouleProof discharge tier (cheap, deterministic), and the receipt's tier field already carries it. No amendment needed; one explanatory sentence in §5.4.

B6. Federal — NIST 800-53/FedRAMP/CMMC, NIST SSDF 800-218

Already mapped in §8; the diff confirms the mapping and adds 800-218A (Part A4).

---

Synthesis: the two diffs agree

Across both worlds the same three-way split recurs — intent instruments, origin instruments, practice instruments — and the same absences recur: no energy anywhere (only its time/memory cousins), no amendment-matched breach, no continuous receipt, no cross-domain reach. JC's seam claim survives both diffs.

And both diffs converge on the same repair list. The regulated canon, being older and bloodier, catches what the AI-coding canon misses: the frame problem (GAP-3) and verifier-tool qualification (GAP-4) are forty-year-old lessons paid for in incidents. The AI-coding canon catches what the regulated canon hasn't met yet: generator identity (GAP-1) and the adversarial generation loop (GAP-2).

---

Proposed v0.4 Amendments (for adoption under §5.2 — attributed, reasoned, chained)

1. Add frame as the fifth obligation (GAP-3): the declared mutable footprint of the transition; all state outside the frame is implicitly invariant; receipts record frame verification at a discharge tier. Reason: pre/post/inv without frame permits arbitrary unstated effect; DO-178C "no unintended function" and ISO 26262 "freedom from interference" are the canon's two independent proofs that this clause is mandatory at high assurance.
2. Add generator to required receipt fields (GAP-1): AI-system identity + version digest + human principals + generation context, AI-BOM-compatible. Reason: OWASP AISVS and SLSA both carry producer identity; a correctness-and-energy receipt that omits producer identity is weaker provenance than the baseline it wraps.
3. Add tier attestation (GAP-4): each discharge entry MUST reference the qualification/soundness attestation of the tier that closed it (DO-330 TQL / DO-333 soundness analogue; ISO 26262 TCL). Reason: a verdict trusted without subsequent verification makes the verdict-producer a qualification target; otherwise the cascade is an unqualified tool in every regulated reading.
4. Permit per-obligation independence flags in the profile (GAP-5). Reason: DAL-A/B independence is per-objective, not global.
5. Security-considerations extension for the generation loop (GAP-2): the generator operates under its own JouleContract; reference AISVS/Agentic Top 10 threat classes. Reason: JC composes over the producing agent; saying so closes the adversarial gap without new machinery.
6. Name the adequacy limit (GAP-6): a normative note that obligation-set adequacy against the behavior space is the residual assessor judgment (as requirements validation is in DO-178C), with optional ODD-style domain annex. Reason: a standard that silently claims completeness it cannot have contains illogic; naming the limit is the logically sound form.
7. Minor: add NIST SP 800-218A row to §8; one sentence in §5.4 admitting coding-rule conformance (MISRA/CERT) as a discharge tier; note ASIL-decomposition as a composition pattern under §3.3.

Precise-claims register (for all public materials): JC does not "verify resources for the first time" — WCET/memory objectives predate it; JC generalizes resource-bound verification from time and memory to energy and makes the bound a billed, receipted, ratcheting EnPI. JC does not eliminate assurance judgment — it names the adequacy residual the entire canon shares.

---

Diff executed against: GitHub Spec Kit / Kiro / OpenSpec / BMAD / Tessl / Cursor / Augment Cosmos; SLSA v1.2 / in-toto / Sigstore / DSSE / GitHub attestations; OWASP AISVS App. C + Agentic Top 10 (2026); NIST SP 800-218 & 800-218A; EU AI Act logging; ISO/IEC 42001 family & 5338; DO-178C + DO-330/331/332/333 + ARP4754A; ED-324/ARP6983 (in development, exp. 2026) + EASA learning assurance; ISO 26262; IEC 62304 + FDA; EN 50128; MISRA/CERT/Power of Ten; NIST 800-53 / FedRAMP / CMMC.