Hypermedia Security: Artifact Entry Specification
v1.0.0Hypermedia AuL0
Artifact Entry (evidence / derived artifact, hash-only)
The L0 artifact entry: the hash-only record of one piece of evidence (an original file, stored exactly as received and never changed) or one derived artifact (produced from evidence by processing) inside a CyberBench case. An artifact entry is not a document of its own — it is a CycloneDX component that lives inside the Case Provenance BOM (case-provenance/v1) as one element of its components array. It carries no signature: its integrity comes from the seal over the enclosing catalog, and each seal is independently time-anchored by an RFC 3161 token (timestamp-token/v1).
Validate against: /schemas/artifact-entry/v1.schema.json
Relationships
References
- target-standard →Hypermedia Security: Custody Chain Specification
- enclosingStandard →Hypermedia Security: Case Provenance BOM Specification
Referenced by
- Hypermedia Security: Case Provenance BOM Specification(component-standard)
Sources
- ecma-international.org
- ECMA-424 2nd edition (December 2025) — the CycloneDX 1.7 BOM specification
- cyclonedx.org
- CycloneDX 1.7 JSON reference — component type enumeration (includes file, data, machine-learning-model), hash algorithm enumeration, bom-ref rules, name/value properties
- github.com
- CycloneDX property taxonomy — namespaced property naming; the hyper-spec: namespace follows it
- www.iso.org
- ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence
- www.iso.org
- ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence (continuity, validity, reproducibility, repeatability)
- www.w3.org
- W3C PROV-DM — wasDerivedFrom: a derivation is a transformation of one entity into another
- www.law.cornell.edu
- US FRE 901(b)(9) — authentication via evidence describing a process or system and showing it produces an accurate result
- www.rfc-editor.org
- RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
- sec.hypermedia.au
- website
ART-001 CycloneDX Component Conformance MUST
An artifact entry MUST be a CycloneDX 1.7 component object. Its type MUST be 'file' for raw evidence or 'data' for a derived artifact; 'machine-learning-model' MAY be used where the artifact is itself a model. All three values are members of the CycloneDX 1.7 component type enumeration. An artifact entry MUST carry only the fields this standard defines: bom-ref, type, name, hashes and properties.
Using plain CycloneDX components keeps every artifact entry readable by standard BOM tooling. The entry is enumerated inside the Case Provenance BOM's components array; it is never a standalone document.
- allowed-values
- file
- allowed-values
- data
- allowed-values
- machine-learning-model
ART-002 BOM Reference Convention MUST NOT
An artifact entry MUST carry a bom-ref that is unique within the enclosing BOM. The bom-ref MUST follow the slug convention 'evidence-<ordinal>-<hashPrefix>' for evidence or 'derived-<sourceOrdinal>-<kind>' for derived artifacts, and MUST NOT begin with 'urn:cdx:' (reserved by CycloneDX for BOM-Links).
The bom-ref is the anchor that BOM-Links from other objects resolve to — custody events reference it, and a finding's analysis-provenance inputRefs bind to it. Every such cross-reference pairs the link with the target's content hash: the link locates, the hash proves.
- evidence-slug
- evidence-<ordinal>-<hashPrefix>
- derived-slug
- derived-<sourceOrdinal>-<kind>
ART-003 Hash Binding MUST
An artifact entry MUST contain at least one hash entry. Every hash entry 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. Both values are members of the CycloneDX hash algorithm enumeration.
For evidence this hash is the artifact's identity; for derived artifacts it is the integrity anchor of the persisted file. Only hashes enter the BOM — evidence bytes stay in the Vault and never leave the machine. This serves ISO/IEC 27037 integrity and preservation.
- allowed-algorithms
- SHA-384
- allowed-algorithms
- SHA-512
ART-004 Artifact Class Declaration MUST
An artifact entry MUST declare exactly one hyper-spec:artifactClass property with value 'evidence' or 'derived'. This is a closed set: no other values are valid in v1.
The class is the discriminator every other requirement in this standard conditions on. Evidence is an original file brought into the case; derived is something produced from evidence by processing. Domain properties use the hyper-spec: namespace per the CycloneDX property taxonomy convention.
- allowed-values
- evidence
- allowed-values
- derived
- vocabulary
- closed
ART-005 Evidence Identity
An evidence entry's bom-ref identifies it within its enclosing BOM. The bytes are identified by the labelled digest in the component's hashes array, which is the value that joins an entry to the same bytes in another document.
The identifier other objects resolve to, and the digest that proves the bytes behind it. Serves ISO/IEC 27037 identification.
- applies-to-class
- evidence
ART-006 Evidence Ordinal MUST
An evidence entry MUST carry a hyper-spec:ordinal property: a positive integer recording append-only ingest order within the case. Ordinals are assigned per case, beginning at 1 and increasing by one per evidence entry, so a case's evidence ordinals form a complete sequence with no repeats and no gaps.
The ordinal makes the ingest sequence explicit and gap-checkable, complementing the custody chain's strictly monotonic event sequence.
- applies-to-class
- evidence
ART-007 Evidence Immutability MUST
An evidence entry MUST carry a hyper-spec:immutable property with value 'true'. The original bytes MUST never be modified; all processing MUST produce new, separately hashed derived artifacts.
This is the ISO/IEC 27037 preservation posture stated on the record: originals are frozen at the door, and everything else in the case derives from them without touching them.
- applies-to-class
- evidence
ART-008 Derived Lineage MUST
A derived entry MUST carry hyper-spec:sourceEvidenceRef: the bom-ref of the evidence entry it was produced from. The enclosing Case Provenance BOM SHOULD mirror this edge in its dependencies array.
This is the lineage edge — the CycloneDX expression of a W3C PROV derivation (wasDerivedFrom: the transformation of one entity into another). Source and derived entries are enumerated in the same sealed catalog, so the seal binds both ends of the edge.
- applies-to-class
- derived
ART-009 Non-Reproducibility Disclosure MUST NOT
A derived entry MUST carry hyper-spec:reproducible with value 'false' and hyper-spec:integrity with value 'hash-at-rest'. The hash protects the persisted file and MUST NOT be treated as a re-derivation target.
The honest disclosure: ML-produced artifacts are method-repeatable, not byte-repeatable. Trust comes from the hash of the file as persisted plus the record of how it was made — never from re-making it. This serves the documented-process expectation of ISO/IEC 27042 and the process-or-system authentication route of US FRE 901(b)(9); a claim of byte-identical reproduction is never made.
- applies-to-class
- derived
ART-010 No Individual Signature MUST NOT
An artifact entry MUST NOT carry a signature of its own and MUST NOT embed artifact content. Its integrity is bound by the seal over the enclosing Case Provenance BOM; each seal is time-anchored by an external RFC 3161 token. Verifiers MUST NOT accept a per-entry signature as a substitute for the catalog seal.
The sealed catalog already binds every hash, and the seal's timestamp token time-anchors the batch — a per-file signature would add a signing round-trip and no trust. Hash-only entries are also privacy-preserving: only hashes ever leave the Vault.
- integrity-source
- case-provenance/v1 seal + timestamp-token/v1
ART-011 Artifact Classification MUST
An evidence entry SHOULD carry a hyper-spec:kind property with value 'audio', 'document', 'image' or 'other'. A derived entry MUST carry a hyper-spec:derivedKind property with value 'transcript' or 'extraction'. Both are closed sets: no other values are valid in v1.
Kinds drive processing dispatch. The evidence kind is what detection assigns to an incoming file; the derived kind is what a processor produces from it. Each set is bounded by capability, so a new value arrives with a new capability.
- allowed-kind-values
- audio
- allowed-kind-values
- document
- allowed-kind-values
- image
- allowed-kind-values
- other
- allowed-derived-kind-values
- transcript
- allowed-derived-kind-values
- extraction
- vocabulary
- closed
ART-012 Custody Event Linkage SHOULD
An artifact entry SHOULD carry a hyper-spec:collectedEventSeq property: the integer sequence number of the custody event (custody-chain/v1) that recorded the artifact's collection or derivation.
This joins the catalog view (what exists) to the custody log view (what happened to it), so a verifier can walk from an entry to the event that brought it into the case.
- target-standard
- https://sec.hypermedia.au/standards/custody-chain/v1