EVIDE Artifacts

Evidentiary material can enter EVIDE through two structurally different paths, and both are described using the word "artifact." The two paths do not overlap and are not interchangeable:

• External Artifacts (the evidence_references extension, available through the API and MCP) — a declared pointer to material that stays outside EVIDE. EVIDE anchors the declaration; it never requests, receives, or stores the material itself.
• Human-submitted intakes (FILE, ZIP, URL or TEXT, through HumanArtifactIntakeService) — FILE and ZIP submissions provide bytes that EVIDE receives, stores and hashes server-side. URL and TEXT submissions produce captured records but are not materialized binary artifacts in the same sense.

Sections 2 and 3 document each mechanism on its own terms, from the code that implements it. Section 4 puts them side by side.

The evidence_references array, introduced in Schema 2.1, lets a submitter declare that supporting material exists elsewhere — a screenshot, a document, a video, a sensor log — without transmitting it. Each entry is a declaration, not a transfer.

• artifact_type — free-text declared type (e.g. screenshot, pdf, sensor_log). Not an enum: EVIDE does not constrain or interpret its vocabulary.
• pointer — an implementation-specific reference. May not represent a file path or URL; EVIDE does not resolve, dereference, or validate it.
• declared_origin — free-text description of where the artifact came from.
• declared_relationship — free-text description of how the artifact relates to the record.
• declared_description — free-text human-readable description.
• declared_retention_status — persistent_storage · rolling_buffer · unknown.

Every field is individually optional. An entry with none of them is structurally valid but carries no information.

A hash may be declared alongside the reference — hash.algorithm, hash.value, hash_scope (full_file · segment · frame · archive), and hashed_by. If any of the four is present, all four become required together; a partial hash declaration is rejected.

External Artifacts can be declared together with ANCHOR declarations in the same intake — an artifact anchored alongside the operational perimeter that was in effect when it was produced. The two extensions are independent of one another.

Human-submitted intakes are processed through HumanArtifactIntakeService, the counterpart to the structured-data intake path. For FILE and ZIP submissions, EVIDE receives, stores and hashes the submitted bytes. URL and TEXT submissions follow the same intake service but are not materialized binary artifacts in the same sense.

• For FILE and ZIP submissions, the uploaded content is written to storage, and EVIDE computes its SHA-256 hash itself, server-side, over the bytes actually written to disk — not over the client-reported size or a client-supplied hash.
• The file size recorded is measured on the file as actually stored (filesize() on the written path), not the size the browser reported during upload — closing any gap between a declared size and what was really written.
• Original filename, stored filename, MIME type, file size, storage path and the computed SHA-256 are recorded together in a single request_files row.
• For URL and TEXT submissions, the same intake path applies, but the record is not treated as a materialized binary artifact in the same sense as FILE or ZIP.

A FILE or ZIP intake produces a "RECEIVED ARTIFACT" section in the Evidentiary Artifact Record. The name shown there is not the name the submitter gave the file — it is a name EVIDE itself derives, matching exactly what a downstream party retrieves when they actually download the artifact through the platform. The distinction is deliberate: what the EAR reports as the artifact's identity is the identity of the bytes EVIDE can actually hand back, not a claim taken on trust from the upload.

Both mechanisms describe evidentiary material. They differ on every dimension that determines what EVIDE can actually attest to afterward.

• ANCHOR — External Artifacts and ANCHOR declarations are independent extensions and can be declared together in the same intake. Neither requires the other.
• EAR (Evidentiary Artifact Record) — the two mechanisms surface differently in the EAR. External Artifacts appear as listed evidence references, exactly as declared. A human-uploaded FILE or ZIP produces its own "RECEIVED ARTIFACT" section, with an EVIDE-derived identity for the stored file.
• FEDIS — neither mechanism constitutes a FEDIS certification. Declaring an External Artifact or uploading a file is preservation, not certification; FEDIS is a separate, explicitly requested step.

• EVIDE does not verify that a declared External Artifact reference is accurate, current, or that the material it points to still exists.
• EVIDE's receipt record and server-computed hash document the bytes received; retrievability remains subject to the applicable retention period. Neither establishes that the file's content depicts what the submitter claims.
• EVIDE does not compare or reconcile an External Artifact's declared hash against a human-uploaded copy of the same material, even if records concerning both exist within EVIDE.
• Neither mechanism is a certification, an endorsement, or a determination of evidentiary weight. Both preserve an evidentiary record, but at different levels: External Artifacts preserve the declaration and any declared digest; Human-uploaded FILE/ZIP Artifacts preserve the received bytes and their EVIDE-computed digest. What a preserved artifact is later found to prove is a separate question, decided outside EVIDE.
• Stored human-uploaded artifacts are retained for a limited, configurable period, not indefinitely — this page does not state a specific duration, since that setting can change independently of this documentation.

EVIDE JSON Schema — evidence_references fields: app.certifywebcontent.com/json

EVIDE Intake Schema Documentation: Intake schema reference

EVIDE ANCHOR: Declared operational perimeter

EVIDE EAR (Evidentiary Artifact Record): Canonical reference page

EVIDE MCP Server: MCP Server documentation

Why Buy EVIDE — Chapter 03: EVIDE ANCHOR & External Artifacts