Evidence kinds/Spec hash commitment

Spec hash commitment

cryptographic evidence

Every L12 entry includes a SHA-256 of the active RuntimeAISpec, making silent spec drift detectable.

What it is

When an operator changes a RuntimeAISpec (different model, different prompt, different reviewer gate, different output schema), the canonicaliseRuntimeAISpec function produces a different hash. The new hash gets committed into every subsequent L12 entry.

A regulator inspecting the chain can detect silent spec changes by walking the specHash field across entries — sudden value changes mean the operator swapped the spec. If the operator claims 'the model was unchanged for Q3' but the specHash transitioned mid-quarter, the chain shows the truth.

Spec hash commitment is the structural answer to 'how do we know the regulator-disclosed system is the same system actually running?'. Without it, regulators rely on operator attestation; with it, the chain itself is the proof.

What it guarantees

  • Detection of any change to spec fields (model, prompt template, output schema, reviewer-gate mode, fallback behavior).
  • Cryptographic uniqueness per spec version — collisions are computationally infeasible.
  • Cross-implementation byte-stability — same spec, same hash across languages.

What it does NOT guarantee

Honest limits. Every primitive has them.

  • That the spec is correct or appropriate for the use case — that's a design decision.
  • That the operator-side spec storage is unmodified — Promethean records the hash; verifying the hash against a claimed spec text is the operator's transparency obligation.

Regulations that engage this kind

EU AI Act Art. 11 + Annex IV

Technical documentation including changes over time

MDR Art. 83

Post-market surveillance — change history

GDPR Art. 5(2)

Accountability — demonstrable configuration

Sectors that rely on this kind

Related evidence kinds

L12 receipt chain

Hash-chained, Ed25519-signed log of every LLM-in-the-loop decision a Promethean-built product makes.

RuntimeAISpec (the spec)

The closed-enum contract one LLM-in-the-loop feature operates under.

Model identity pin

Each L12 entry binds the exact provider + model + version that decided.

FAQ

What's in the spec that gets hashed?

Every field of the RuntimeAISpec: specId, displayName, category, inputSchema, outputSchema, promptTemplate, modelIdentity (provider/model/version), reviewerGate, lowConfidenceThreshold, maxLatencyMs, fallbackBehavior, deterministicDefault. Whitespace-irrelevant canonical form ensures formatting changes don't produce hash changes.

If I A/B-test specs, do I get two hashes?

Yes — each variant has its own spec definition, hence its own hash. The chain shows interleaved entries with different specHashes corresponding to the two variants. Post-hoc analysis can segment by specHash to measure A/B outcomes.