obsign-verify 0.1.0__tar.gz

obsign_verify-0.1.0/LICENSE

@@ -0,0 +1,206 @@
+SPDX-License-Identifier: Apache-2.0
+
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+
+   Copyright 2026 Coherence Energy Labs

obsign_verify-0.1.0/MANIFEST.in

@@ -0,0 +1,7 @@
+# The sdist must be self-contained: someone auditing the source should get the
+# tests and the artifacts those tests judge against, not just the modules.
+include LICENSE README.md
+recursive-include src/obsign_verify/data *
+recursive-include tests *.py
+recursive-include docs *.md
+recursive-include tools *.py

obsign_verify-0.1.0/PKG-INFO

@@ -0,0 +1,144 @@
+Metadata-Version: 2.4
+Name: obsign-verify
+Version: 0.1.0
+Summary: Re-derive an Obsign receipt's claim on your own machine, offline.
+Author: Coherence Energy Labs
+License-Expression: Apache-2.0
+Keywords: provenance,receipts,verification,determinism,reproducibility
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: numpy>=1.24
+Provides-Extra: sig
+Requires-Dist: cryptography>=41; extra == "sig"
+Provides-Extra: dev
+Requires-Dist: pytest>=7; extra == "dev"
+Requires-Dist: cryptography>=41; extra == "dev"
+Dynamic: license-file
+
+# obsign-verify
+
+**Re-derive the number yourself. Offline. On your hardware.**
+
+A signature tells you a claim is *unmodified*. It never tells you the claim is *true*.
+This verifier re-runs the computation and compares bits.
+
+```console
+$ pip install obsign-verify
+$ obsign-verify receipt.json
+
+  [VERIFIED] receipt.json
+      integrity   ok
+      re-derived  ok
+      signature   absent (integrity and re-derivation still hold)
+
+1/1 receipt(s) verified on THIS machine.
+```
+
+Exit code `0` if every receipt verified, `1` otherwise. That is the whole interface.
+
+## It imports nothing from the producer
+
+Zero code is shared with the engine that mints these receipts. If it imported the
+producer, *"it verifies"* would mean *"the producer agrees with itself"* — which is
+not a claim worth making. The kernel here was written separately against the
+published spec, so a bug in one cannot cancel a bug in the other.
+
+Dependencies: **numpy**. That is it. Signature checking is an optional extra
+(`pip install 'obsign-verify[sig]'`) *by design* — the two steps that make this more
+than attestation, integrity and re-derivation, need no cryptography library at all.
+
+## What it checks
+
+| Step | Question | Status |
+|---|---|---|
+| 1 · integrity | does `receipt_sha256` recompute from the claim? | checked |
+| 2 · reproduced | does re-running the kernel reproduce `output.sha256`? | checked |
+| 3 · signature | does the signature verify, and cover what it claims to? | checked (optional dep) |
+| 4 · issuer trust | *should* you trust this key? | **out of scope, deliberately** |
+
+Step 4 is an identity question. A verifier that answered it from a bundled list
+would be asserting a social fact as a cryptographic one. `verified` means steps 1–3.
+
+**`VERIFIED` without a signature is not a weaker result.** It means integrity holds
+and the number re-derived on your machine — you did not have to trust anyone. A
+signature adds *who*, not *whether*.
+
+## Two things it will not do
+
+**It will not name a signer the signature did not cover.** Legacy
+`obsign/signature/v1` signs the bare receipt hash, so it covers neither the signer
+nor the case block — the name in the file can be rewritten by anyone with a text
+editor and no key. Such receipts still verify, and are reported
+`identity_bound: false`, `attributed_signer: null`. Only `obsign/signature/v2`
+puts the signer inside the signed bytes.
+
+**It will not crash instead of refusing.** A verifier that raises on a hostile
+receipt has failed open in the eyes of whoever handed it the file. Malformed input
+returns `verified: false`.
+
+## Verify it against us
+
+The package ships the same `conformance_vectors.json` the engine is judged against.
+
+```console
+$ pip install 'obsign-verify[dev]' && pytest
+```
+
+**The forgeries ship inside the package.** One command, no files of your own, no
+login, no request:
+
+```console
+$ obsign-verify --self-check
+
+  ok  env_only_change_must_still_verify   VERIFIED (expected VERIFIED)
+  ok  forged_input_hash                   REFUSED  (expected REFUSED)
+  ok  resealed_tampered_claim             REFUSED  (expected REFUSED)
+  ...
+9/9 bundles behaved as declared.
+```
+
+Exit `0` means every bundle got the verdict it declares — the two honest receipts
+verified and **all seven forgeries refused.** Refusing them is the job, so a clean
+run is not "9 verified".
+
+The one to look at is `resealed_tampered_claim`. Its output was edited, its receipt
+re-hashed, its signature re-applied — so it passes the integrity check cleanly and
+fails only on re-derivation. That single bundle is the entire argument for step 2.
+
+## Why the number is the same on your machine
+
+Integer fixed-point. Floating point is non-associative and vendor-dependent, so the
+same float kernel on two chips can differ in the last bits; int64 arithmetic is
+exact and identical on every machine that has it. The only float builds the initial
+source term, and it is rounded to int64 before any evolution — so a last-ulp libm
+difference is absorbed rather than compounded.
+
+Honest residual risk, stated rather than hidden: a source value sitting exactly on a
+`.5` rounding boundary could round differently under a different libm. **Not proven
+impossible** — but now genuinely measured rather than assumed.
+
+CI runs the conformance vectors on **x86_64 Linux, ARM64 macOS and Windows**, across
+four Python versions, and prints the actual output hashes on every runner. The
+architecture split is the load-bearing part: `aarch64` and `x86_64` ship different libm
+implementations, and if that risk were going to bite, that is where it would.
+
+When this sentence was first written it said "not observed across the platforms tested"
+and exactly one platform had been tested — true, and nearly empty. If the hashes ever
+diverge between two runners, the job fails and says so, because that divergence is the
+finding, not an inconvenience.
+
+## Status
+
+**Apache-2.0.** Permissive on purpose: this is the artifact we ask strangers to run in
+order to check us, and a licence that adds friction to that would defeat its own point.
+It matches what the estate's other public "check our work" repos already carry.
+
+`BUILT`. Publication is a single decision away — the package name `obsign-verify` was
+verified available on PyPI on 2026-08-01, and everything here installs and passes today.
+
+**A note on the name.** The bare `obsign` name is not available and is not ours: a PyPI
+placeholder reading *"Reserved for the Obsign project — cryptographic proof of AI agent
+actions"* was uploaded on 2026-07-30, seventeen minutes after the GitHub org it points at
+was created. This package is the verifier rather than the engine, so the longer name is
+the accurate one in any case.

obsign_verify-0.1.0/README.md

@@ -0,0 +1,126 @@
+# obsign-verify
+
+**Re-derive the number yourself. Offline. On your hardware.**
+
+A signature tells you a claim is *unmodified*. It never tells you the claim is *true*.
+This verifier re-runs the computation and compares bits.
+
+```console
+$ pip install obsign-verify
+$ obsign-verify receipt.json
+
+  [VERIFIED] receipt.json
+      integrity   ok
+      re-derived  ok
+      signature   absent (integrity and re-derivation still hold)
+
+1/1 receipt(s) verified on THIS machine.
+```
+
+Exit code `0` if every receipt verified, `1` otherwise. That is the whole interface.
+
+## It imports nothing from the producer
+
+Zero code is shared with the engine that mints these receipts. If it imported the
+producer, *"it verifies"* would mean *"the producer agrees with itself"* — which is
+not a claim worth making. The kernel here was written separately against the
+published spec, so a bug in one cannot cancel a bug in the other.
+
+Dependencies: **numpy**. That is it. Signature checking is an optional extra
+(`pip install 'obsign-verify[sig]'`) *by design* — the two steps that make this more
+than attestation, integrity and re-derivation, need no cryptography library at all.
+
+## What it checks
+
+| Step | Question | Status |
+|---|---|---|
+| 1 · integrity | does `receipt_sha256` recompute from the claim? | checked |
+| 2 · reproduced | does re-running the kernel reproduce `output.sha256`? | checked |
+| 3 · signature | does the signature verify, and cover what it claims to? | checked (optional dep) |
+| 4 · issuer trust | *should* you trust this key? | **out of scope, deliberately** |
+
+Step 4 is an identity question. A verifier that answered it from a bundled list
+would be asserting a social fact as a cryptographic one. `verified` means steps 1–3.
+
+**`VERIFIED` without a signature is not a weaker result.** It means integrity holds
+and the number re-derived on your machine — you did not have to trust anyone. A
+signature adds *who*, not *whether*.
+
+## Two things it will not do
+
+**It will not name a signer the signature did not cover.** Legacy
+`obsign/signature/v1` signs the bare receipt hash, so it covers neither the signer
+nor the case block — the name in the file can be rewritten by anyone with a text
+editor and no key. Such receipts still verify, and are reported
+`identity_bound: false`, `attributed_signer: null`. Only `obsign/signature/v2`
+puts the signer inside the signed bytes.
+
+**It will not crash instead of refusing.** A verifier that raises on a hostile
+receipt has failed open in the eyes of whoever handed it the file. Malformed input
+returns `verified: false`.
+
+## Verify it against us
+
+The package ships the same `conformance_vectors.json` the engine is judged against.
+
+```console
+$ pip install 'obsign-verify[dev]' && pytest
+```
+
+**The forgeries ship inside the package.** One command, no files of your own, no
+login, no request:
+
+```console
+$ obsign-verify --self-check
+
+  ok  env_only_change_must_still_verify   VERIFIED (expected VERIFIED)
+  ok  forged_input_hash                   REFUSED  (expected REFUSED)
+  ok  resealed_tampered_claim             REFUSED  (expected REFUSED)
+  ...
+9/9 bundles behaved as declared.
+```
+
+Exit `0` means every bundle got the verdict it declares — the two honest receipts
+verified and **all seven forgeries refused.** Refusing them is the job, so a clean
+run is not "9 verified".
+
+The one to look at is `resealed_tampered_claim`. Its output was edited, its receipt
+re-hashed, its signature re-applied — so it passes the integrity check cleanly and
+fails only on re-derivation. That single bundle is the entire argument for step 2.
+
+## Why the number is the same on your machine
+
+Integer fixed-point. Floating point is non-associative and vendor-dependent, so the
+same float kernel on two chips can differ in the last bits; int64 arithmetic is
+exact and identical on every machine that has it. The only float builds the initial
+source term, and it is rounded to int64 before any evolution — so a last-ulp libm
+difference is absorbed rather than compounded.
+
+Honest residual risk, stated rather than hidden: a source value sitting exactly on a
+`.5` rounding boundary could round differently under a different libm. **Not proven
+impossible** — but now genuinely measured rather than assumed.
+
+CI runs the conformance vectors on **x86_64 Linux, ARM64 macOS and Windows**, across
+four Python versions, and prints the actual output hashes on every runner. The
+architecture split is the load-bearing part: `aarch64` and `x86_64` ship different libm
+implementations, and if that risk were going to bite, that is where it would.
+
+When this sentence was first written it said "not observed across the platforms tested"
+and exactly one platform had been tested — true, and nearly empty. If the hashes ever
+diverge between two runners, the job fails and says so, because that divergence is the
+finding, not an inconvenience.
+
+## Status
+
+**Apache-2.0.** Permissive on purpose: this is the artifact we ask strangers to run in
+order to check us, and a licence that adds friction to that would defeat its own point.
+It matches what the estate's other public "check our work" repos already carry.
+
+`BUILT`. Publication is a single decision away — the package name `obsign-verify` was
+verified available on PyPI on 2026-08-01, and everything here installs and passes today.
+
+**A note on the name.** The bare `obsign` name is not available and is not ours: a PyPI
+placeholder reading *"Reserved for the Obsign project — cryptographic proof of AI agent
+actions"* was uploaded on 2026-07-30, seventeen minutes after the GitHub org it points at
+was created. This package is the verifier rather than the engine, so the longer name is
+the accurate one in any case.

obsign_verify-0.1.0/docs/COMPLIANCE.md

@@ -0,0 +1,141 @@
+# What a replay receipt is evidence of
+
+**For the people whose job is to say no.**
+
+This maps one capability — *the claimed number can be re-derived, bit-for-bit, by
+someone who does not trust us* — to the controls an auditor already has to satisfy.
+
+**It is technical-evidence mapping to support an audit. It is not a legal compliance
+certification, and it is not advice.** The tables below are generated from
+`tools/compliance_map.py`; a gate fails the build if this document and that module
+disagree. The hand-written version of this artifact in a sibling repo had already
+gone stale against its own code, which is why it is derived here rather than typed.
+
+---
+
+## The change in evidence class
+
+Most controls in this space are satisfied *procedurally*: you assert that validation
+happened, and the auditor assesses your process for asserting it. The reviewer's
+question is **do I believe this organisation's process?**
+
+A replay receipt changes what is handed over. The artifact is not a statement that
+the number was checked — it is the number, plus a program that regenerates it. The
+reviewer's question becomes **did I get the same bytes?**, which they answer
+themselves, offline, in one command.
+
+That converts a procedural control into a technical one. It is the only claim in this
+document, and everything below is a consequence of it.
+
+**A signature does not do this.** Signing proves a claim is *unmodified*; it never
+proves the claim is *true*. The public challenge ships a **resealed forgery** — output
+edited, receipt re-hashed, signature re-applied — precisely so the distinction is
+demonstrable rather than argued. It passes the integrity check and fails re-derivation.
+
+---
+
+## Frameworks cited
+
+<!-- BEGIN GENERATED: frameworks -- edit tools/compliance_map.py, not this block -->
+| Framework | Edition cited |
+|---|---|
+| **EU AI Act** | Reg. (EU) 2024/1689, as amended by the 2026 Digital Omnibus |
+| **ISO/IEC 42001** | 2023 |
+| **NIST AI RMF** | 1.0 |
+| **SOC 2** | AICPA Trust Services Criteria |
+| **SR 11-7** | Fed/OCC supervisory guidance on model risk management |
+<!-- END GENERATED: frameworks -->
+
+Control identifiers are **edition-sensitive**. Article numbers, Annex A controls and
+Trust Services Criteria references are cited as of the editions above; an auditor
+working from a different edition must re-check the numbering. The stable part is the
+capability-to-requirement argument. The identifier is a pointer, and pointers rot.
+
+## Controls a receipt provides technical evidence for
+
+<!-- BEGIN GENERATED: controls-evidenced -- edit tools/compliance_map.py, not this block -->
+| Capability | Framework | Control | Requirement |
+|---|---|---|---|
+| declared accuracy that can be checked | EU AI Act | `Art. 15(1)` | Declared level of accuracy, with the metric stated |
+| declared accuracy that can be checked | NIST AI RMF | `MEASURE 2.5` | Uncertainty and performance quantified per claim |
+| declared accuracy that can be checked | SR 11-7 | `Outcomes Analysis` | Decisions carry a quantified, checkable claim |
+| exact identification of what produced the value | EU AI Act | `Annex IV(1)` | Identification of the AI system and its exact version |
+| exact identification of what produced the value | SOC 2 | `PI1.3` | Processing is authorised and attributable to a defined version |
+| exact identification of what produced the value | SR 11-7 | `Model Development` | Model versioning bound to each result |
+| independent re-derivation of the claimed value | EU AI Act | `Annex IV(2)` | Technical documentation of the system's development and validation |
+| independent re-derivation of the claimed value | ISO/IEC 42001 | `A.6.2.4` | AI system verification and validation of intended behaviour |
+| independent re-derivation of the claimed value | NIST AI RMF | `MEASURE 2.5` | Validity and reliability demonstrated and documented |
+| independent re-derivation of the claimed value | SOC 2 | `PI1.4` | Output is complete and accurate -- evidenced by re-derivation rather than by attestation |
+| independent re-derivation of the claimed value | SR 11-7 | `Model Validation` | Results are replicable by a party independent of the model's developer |
+| resilience of the record against alteration | EU AI Act | `Art. 15(5)` | Cybersecurity; resilience against data or model manipulation |
+| resilience of the record against alteration | NIST AI RMF | `MEASURE 2.7` | Robustness and security of the system evaluated |
+| resilience of the record against alteration | SOC 2 | `PI1.5` | Stored output is protected from unauthorised change |
+| tamper-evident record of the operation | EU AI Act | `Art. 12` | Automatic recording of events over the system's lifetime |
+| tamper-evident record of the operation | EU AI Act | `Art. 26(6)` | Deployer retains automatically generated logs |
+| tamper-evident record of the operation | ISO/IEC 42001 | `A.6.2.8` | Recording of event logs for AI system operation |
+| tamper-evident record of the operation | NIST AI RMF | `GOVERN 1.5` | Traceability and accountability for system decisions |
+| tamper-evident record of the operation | SOC 2 | `CC7.2` | System operation is monitored and anomalies detected |
+| tamper-evident record of the operation | SR 11-7 | `Documentation` | Audit trail sufficient for independent review |
+<!-- END GENERATED: controls-evidenced -->
+
+The strongest row is **SOC 2 `PI1.4`**. Processing Integrity asks whether output is
+complete and accurate. Every other technology in this space answers it by
+*attestation* — someone with a key says so. A receipt answers it by *demonstration*.
+That is the difference between showing and saying, and it is the entire product
+argument in one control reference.
+
+## Controls a receipt does NOT address
+
+<!-- BEGIN GENERATED: controls-not-covered -- edit tools/compliance_map.py, not this block -->
+| Framework | Control | Why a receipt does not address it |
+|---|---|---|
+| EU AI Act | `Art. 10` | Data and data governance; training-data quality and representativeness |
+| EU AI Act | `Art. 14` | Human oversight design (a computed-claim receipt evidences no oversight step) |
+| EU AI Act | `Art. 9` | Risk-management system across the lifecycle (process) |
+| ISO/IEC 42001 | `A.5.2` | AI system impact assessment (process-level) |
+| ISO/IEC 42001 | `A.7.2` | Data governance for AI systems |
+| NIST AI RMF | `MEASURE 2.11` | Fairness and harmful-bias evaluation (needs a bias audit) |
+| SOC 2 | `A1.x` | Availability commitments and capacity management (organisational) |
+| SOC 2 | `CC6.x` | Logical access controls over the issuing system (organisational) |
+| SOC 2 | `CC8.1` | Change management for the model and its deployment (process) |
+| SR 11-7 | `Conceptual Soundness` | Justification of model design and assumptions |
+<!-- END GENERATED: controls-not-covered -->
+
+This list is why the previous one is credible. Every entry is process-level or
+organisational, and a mapping that quietly omitted them would be the kind of overreach
+that costs an auditor's trust in the rows that *are* evidenced. The self-test enforces
+it structurally: **no framework may appear in the evidenced table without also
+appearing here.** A framework claimed without its limits stated fails the build.
+
+---
+
+## Scope, stated before you ask
+
+**Only the claimed number must live in the deterministic core — not your pipeline.**
+This is the objection that decides adoption, so it is answered first rather than
+defended later. You do not port your training stack. You identify the handful of
+numbers that are actually in dispute — the ones a validator currently re-implements by
+hand — and put those on the replay path.
+
+If that scope cannot be shrunk to a short list on the first conversation, this is not
+the right time for that organisation, and saying so early is cheaper for both sides.
+
+**Cryptography stops at the sensor**, and for computed claims it stops at the input.
+A receipt proves the stated inputs produce the stated output. It cannot prove the
+inputs describe reality. Anyone who tells you otherwise is selling.
+
+**Key custody is a separate question.** An unsigned receipt whose number re-derives is
+still fully verified in the sense that matters here: integrity holds and you recomputed
+the value. A signature adds *who*, not *whether* — and this verifier will not name a
+signer the signature did not cryptographically cover.
+
+---
+
+## What to hand an examiner
+
+1. The receipt.
+2. `pip install` and one command.
+3. This mapping, with the not-covered table intact.
+
+The third item is the one that makes the first two land. An examiner who has been
+handed only cryptography has been handed homework.