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
- hyper-spec:artifactKind
- attestation (declarations document; one per promoted finding; L2)
- hyper-spec:claimPredicate
- produced-from-declared-evidence
Sources
- www.iso.org
- ISO/IEC 27042:2015: §3.17 repeatability (same result, same testing environment) / §3.18 reproducibility (same result, a different testing environment — different computer, hard drive, operator) — both 'same result', never same bytes; §5.2 continuity (rigorous and complete records of all processes applied, contemporaneous notes highly beneficial; expressly tied to the ISO/IEC 27037 chain of custody); §5.3 repeatability and reproducibility (methods failing these are highly susceptible to challenge and can call into question the team's competence and proficiency; validation per ISO/IEC 27041 can assist in demonstrating that methods reliably and reproducibly produce results); §5.5 uncertainty (investigators should be aware of areas of uncertainty in findings); §6.4 record keeping (each person carrying out any process should keep accurate and detailed contemporaneous notes, sufficiently detailed to allow another similarly competent person to repeat those actions and achieve the same results, including relevant information received and decisions taken with 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 — at its 2026-05-07 meeting the Advisory Committee on Evidence Rules did not recommend action: it revised the proposed Rule and scheduled further study alongside the deepfakes issue for its next meeting (Report to the Standing Committee, 2026-05-17). The revision refocuses the Rule from 'machine-generated' information onto evidence produced by artificial intelligence offered without an expert witness, with a presumption that an expert foundation is required. 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. Every digest in the prov-inputs and prov-nonrepro evidence MUST carry alg 'SHA-384' or 'SHA-512' and lowercase hexadecimal content whose length matches the algorithm: 96 characters for SHA-384, 128 for SHA-512.
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
- modelId
- required-fields
- modelVersion
- required-fields
- weightsDigest
- required-fields
- quantization
- required-fields
- kvBits
- 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 provides that the notes should include 'decisions taken, including reasons for the decision'; the parameters are the machine-checkable form of the run's decisions, and are what let another similarly competent person repeat the actions and achieve the same results (§6.4's bar).
- required-fields
- temperature
- required-fields
- topP
- required-fields
- seed
- required-fields
- maxTokens
- 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 asks investigators to be aware of areas of uncertainty in their findings; this requirement makes that awareness explicit and machine-readable rather than leaving it to judgement. §5.3 warns that methods failing repeatability/reproducibility are highly susceptible to challenge and can call into question the investigative team's competence and proficiency. 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.
- 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 hyper-spec:role = methodRef — and it MUST resolve per method-validation/v1 #validation-gate: a current claim whose predicate is method-validated and whose validUntil window covers this attestation's metadata.timestamp, 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 where new methods are devised during an investigation, proper validation per ISO/IEC 27041 can assist in demonstrating that methods reliably and reproducibly produce results which satisfy an investigative need — 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 can assist in demonstrating reliable, reproducible results)
APRV-007 Author Identity MUST
assessors[] MUST identify the author (author A), the attestation MUST carry an enveloped JSF signature by that Fulcio identity using ES384, ES512, or ML-DSA-65 or ML-DSA-87 identified by their FIPS 204 OIDs, 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 provides that each person carrying out any process should keep accurate and detailed 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 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's evidence array MUST list exactly the bom-refs of the entries in declarations.evidence: every cited bom-ref resolves to a carried entry, and every carried entry is cited.
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