Hypermedia Security: Analysis Provenance Specification
v1.0.0Hypermedia Au
Analysis Provenance (the FRE 901 authentication set; frozen at promotion)
The analysis-provenance attestation: the authentication set for an AI-produced finding. Signed by the finding's author, created with the analysis and frozen at promotion. It records what produced the finding (model identity), from which exact inputs (bound by hash into the sealed catalog), under which conditions (prompt and parameters), and discloses honestly what reproduces: the method, not the bytes. ISO/IEC 27042 §6.4 sets the bar it implements — records sufficiently detailed to allow another similarly competent person to repeat those actions and achieve the same result; §3.18 defines reproducibility as the same results in a different environment, never byte-identical output. US FRE 901(b)(9) authentication of a process or system maps field-for-field onto the same set. The method's reliability is carried separately by method-validation/v1, reached through the methodRef gate.
Machine attestation: /attestations/analysis-provenance/v1
Relationships
References
- target-standard →Hypermedia Security: Case Provenance BOM Specification
- target-requirement →Hypermedia Security: Method Validation Specification
- references →Hypermedia Security: Case Provenance BOM Specification
- references →Hypermedia Security: Method Validation Specification
- references →Hypermedia Security: Finding BOM Specification
Referenced by
- Hypermedia Security: Finding BOM Specification(references)
- Hypermedia Security: Finding Approval Specification(references)
- Hypermedia Security: Finding BOM Specification(target-standard)
About this standard
- artifact-kind
- attestation (declarations document; one per promoted finding; L2)
- claim-predicate
- produced-from-declared-evidence
Sources
- www.iso.org
- ISO/IEC 27042:2015 — verified against the standard text 2026-07-11 (SPEC-9 note): §3.17 repeatability (same results, same testing environment) / §3.18 reproducibility (same results, a different testing environment) — both 'same results', never same bytes; §5.2 continuity (rigorous, complete, contemporaneous records; ties to the 27037 chain of custody); §5.3 repeatability and reproducibility (methods failing these are highly susceptible to challenge; validation per ISO/IEC 27041 demonstrates a method reliably and reproducibly produces results); §5.5 uncertainty (findings should disclose areas of uncertainty); §6.4 record keeping (contemporaneous notes sufficiently detailed to allow another similarly competent person to repeat those actions and achieve the same result, including decisions taken and reasons)
- www.law.cornell.edu
- US FRE 901(b)(9) — authentication via evidence describing a process or system and showing it produces an accurate result; the authentication factors (system identity + version, input-data integrity, run conditions) map field-for-field onto the prov-inputs set. In force
- www.uscourts.gov
- Proposed FRE 707 (machine-generated evidence held to Rule 702 reliability) — as of the Advisory Committee meeting of 2026-05-07 the proposal was NOT approved: no action recommended, the proposal revised, further study scheduled (alongside deepfakes). Cited as a pending, deferred proposal only; the authentication mapping rests on FRE 901, which is in force
- www.rfc-editor.org
- RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
- sec.hypermedia.au
- website
APRV-001 Model Identity MUST
The prov-inputs evidence MUST record modelId, modelVersion, weightsDigest {alg, content}, quantization, and kvBits. The weightsDigest MUST pin the exact weights used.
This is the 'system identity + version' factor of US FRE 901(b)(9) authentication, and the ISO/IEC 27042 §6.4 record of 'relevant information received' that lets another competent person reproduce the analysis. weightsDigest is what distinguishes a named model from the exact bytes that produced this finding — two builds of the same model version are different systems for authentication purposes.
- required-fields
- modelIdmodelVersionweightsDigestquantizationkvBits
- iso-basis
- ISO/IEC 27042 §6.4 (record keeping)
- legal-basis
- US FRE 901(b)(9) — system identity + version
APRV-002 Input Binding MUST NOT
The prov-inputs evidence MUST carry inputRefs[], one entry per input the analysis consumed, each a BOM-Link and paired hash resolving to a specific evidence or derived entry in the sealed Case Provenance catalog. An analysis with no declared inputs MUST NOT back a finding.
This edge is the difference between 'the finding used this evidence' and 'the finding sits near it': inputRefs bind to the specific catalog entries consumed, by hash, so the inputs are the seal-verified bytes and nothing else. It is the 'input-data integrity' factor of FRE 901(b)(9) authentication and the ISO/IEC 27042 §6.4 record of the information the analysis was performed on.
- target-standard
- https://sec.hypermedia.au/standards/case-provenance/v1
- legal-basis
- US FRE 901(b)(9) — input-data integrity
APRV-003 Method Parameters MUST
The prov-inputs evidence MUST record promptHash and params, and params MUST include temperature, topP, seed, and maxTokens.
The exact run conditions — the 'run conditions' factor of FRE 901(b)(9) authentication. ISO/IEC 27042 §6.4 requires the record to capture 'decisions taken, including reasons'; the parameters are the machine-checkable form of the run's decisions, and are what let another competent person repeat the actions and achieve the same result (§6.4's bar).
- required-params
- temperaturetopPseedmaxTokens
- iso-basis
- ISO/IEC 27042 §6.4
- legal-basis
- US FRE 901(b)(9) — run conditions
APRV-004 Non-Reproducibility Disclosure MUST NOT
The prov-nonrepro evidence MUST state outputByteReproducible=false, methodReproducible=true, integrityBasis=hash-at-rest, and the outputHash of the produced finding. Byte-identical re-derivation of the output MUST NOT be claimed anywhere in the case record.
ISO/IEC 27042 defines reproducibility (§3.18) as a process getting the same results in a different testing environment, and repeatability (§3.17) as the same results in the same environment — both are 'same results', and the standard nowhere requires byte-identical output. So declaring the output not byte-reproducible while asserting the method reproducible is a precise articulation of 27042's own definitions, not a departure from them. §5.5 requires findings to disclose their areas of uncertainty, and §5.3 warns that methods failing repeatability/reproducibility are highly susceptible to challenge and impugn the team's competence — the honest, precise posture here is exactly the challenge-resistance 27042 calls for. Integrity is carried by the hash of the persisted output, not by re-running the model.
- required-values
- outputByteReproducible=falsemethodReproducible=trueintegrityBasis=hash-at-restoutputHash
- iso-basis
- ISO/IEC 27042 §3.17/§3.18 (same results, not same bytes), §5.5 (uncertainty), §5.3 (challenge resistance)
APRV-005 Cache Signature SHOULD
The prov-inputs evidence SHOULD record a cacheSignature — the KV-cache and build signature string that contextualises the run for reproducibility.
SHOULD, not MUST: the cache/build signature sharpens the reproducibility record but is not itself an authentication factor. Where available it strengthens the ISO/IEC 27042 §6.4 record of the conditions under which the result was produced.
- level
- SHOULD
APRV-006 Method Gate MUST NOT
The claim MUST carry the methodRef edge — an externalReference of type attestation marked cyberbench:role = methodRef — and it MUST resolve per method-validation/v1 #validation-gate: a current method-validated claim whose status is fully-validated and whose validUntil window covers the time of promotion. A finding whose methodRef does not so resolve MUST NOT be disclosed.
This is the analysis-provenance side of the reliability gate; the method-validation side is method-validation/v1 #validation-gate (METH-007). It is also ISO-grounded on both sides: ISO/IEC 27042 §5.3 states that when a method is devised, validation per ISO/IEC 27041 is how one demonstrates the method reliably and reproducibly produces results — so the methodRef edge from this attestation into method-validation is the CyberBench realisation of 27042's own cross-reference to 27041. Provenance answers what produced this finding; method-validation answers whether the technique is reliable — this edge binds the two.
- target-requirement
- https://sec.hypermedia.au/standards/method-validation/v1#validation-gate
- iso-basis
- ISO/IEC 27042 §5.3 (validation per 27041 demonstrates reliable, reproducible results)
APRV-007 Author Identity MUST
assessors[] MUST identify the author (author A), the attestation MUST be signed by that identity (Fulcio-verified), and it MUST be the same identity that signs the L2 Finding. Approval of the finding MUST be signed by a different identity (maker-checker; finding-approval/v1).
This attestation is the maker side of maker-checker: the author asserts how the finding was produced and signs it. ISO/IEC 27042 §6.4 requires each person carrying out a process to keep contemporaneous notes of their actions — attribution of the analysis to a named handler. The checker side, a distinct identity, is finding-approval/v1.
- iso-basis
- ISO/IEC 27042 §6.4 (contemporaneous notes attributed to a named person)
APRV-008 Claim and Target MUST
The attestation MUST carry exactly one claim whose target is the L2 Finding by BOM-Link and paired hash, and whose predicate is produced-from-declared-evidence. The attestation freezes at promotion; if the finding is revised under changes-requested it is superseded by a new attestation, never edited in place.
The claim binds the authentication set to one specific finding. Freezing at promotion is what makes the provenance a fixed record of how that finding was produced; a revised finding is a new object (finding/v1) with its own frozen provenance, and the superseded one is kept, marked superseded — nothing is edited, nothing is deleted.
- predicate
- produced-from-declared-evidence