Inside the Artemis evidence architecture: marking, anchoring, and why it survives an audit

When a regulator asks for an audit, "trust us" is not an acceptable answer — and Artemis is designed so it never has to be. This article walks through the pipeline end to end: how content gets marked, how every operation becomes tamper-evident evidence, and why that evidence holds up even against a skeptic who trusts neither you nor us.

Step 1 — Marking, in your infrastructure

The marking plane runs where your content lives — your cloud, your cluster, deployed from our public images via Helm or Compose. For every asset it produces two bound artifacts:

• A C2PA manifest: a signed Content Credential stating what the asset is, who produced it, and how. It is signed with your keys, held in your KMS or HSM (AWS, GCP, Azure KMS or any PKCS#11 device). Artemis never holds — or sees — your private key.

• An invisible watermark, matched to the modality: TrustMark for images, VideoSeal for video, AudioSeal for audio. The watermark is embedded in the signal itself, so it survives resizing, re-encoding and cropping to a degree metadata never can.

The two are complementary by design. Manifests are precise but strippable — re-encode a file and the metadata may be gone. Watermarks persist but carry little data. Together, a watermark detection that leads back to a signed manifest reconstructs provenance even for a file that has been through three messaging apps.

Step 2 — Every operation becomes a chained event

Each marking operation emits an event containing, among other fields, the hash of the previous event. Chains are kept per legal entity, so each of your entities has its own independently verifiable history from its genesis record onward.

This structure is append-only in the strong sense: alter any historical event — change a field, delete a record, reorder two entries — and every subsequent hash in the chain stops matching. There is no quiet edit.

A hash chain alone, however, is still stored by someone. If that someone is also the party being audited, we are back to self-attestation. Which is why the chain is only the middle of the story.

Step 3 — Daily anchoring to an independent timestamp authority

Once a day, for every entity, Artemis builds a Merkle tree over that day's events and submits the root to an independent RFC 3161 timestamp authority. The TSA returns a signed timestamp token that cryptographically binds the root to a point in time — under the TSA's signature, not ours.

That token, the TSA's certificate chain, the anchor summary and the full event log are then written to write-once (WORM) object storage with an enforced retention policy. Every individual event retains its inclusion proof — the hash path from the event up to the anchored root.

Why it cannot be altered

Consider what an attacker — including a malicious insider, and including Artemis itself — would have to do:

• Alter one event? The per-entity hash chain breaks, and the recomputed Merkle root no longer matches the anchored root.

• Rebuild the whole chain to hide the edit? The rebuilt root does not match the root inside the TSA's signed token, which sits in write-once storage.

• Backdate content marked today? That requires a TSA signature over yesterday's date — meaning forging the timestamp authority's private key. The timestamps are issued by an independent third party precisely so that we cannot do this either.

• Delete the inconvenient day entirely? The WORM bucket rejects overwrites and deletions within its retention window, and a missing day in an otherwise continuous anchor history is itself evidence.

This is the property behind a line we use deliberately: nobody can backdate or rewrite the evidence — including us.

Verification fails closed

Evidence that verifies against nothing is theater, so Artemis verification is fail-closed: timestamp tokens are only reported as verified when they validate against a pinned TSA certificate chain. If no trust anchor is available, verification fails loudly rather than passing silently — and audit reports state the verification status of every anchor explicitly.

Audit day

What the regulator actually receives:

• A generated audit report covering the period in question: every asset, its marking events, its inclusion proofs, and the anchors they roll up to — with per-anchor timestamp verification status.

• Self-contained evidence artifacts from write-once storage: the event log, the Merkle data, the raw RFC 3161 token and the TSA certificate chain. The token is a standard format — it can be inspected with stock OpenSSL, with no Artemis software in the loop.

• Independent verifiability: an auditor can recompute the chain, recompute the tree, check the inclusion proofs and validate the TSA signature entirely offline. At no point does the verdict depend on trusting Artemis, or trusting you.

The short version

Artemis marks with open standards (C2PA plus invisible watermarking), chains every operation per legal entity, seals each day with a SHA-256 Merkle root, anchors it via RFC 3161 to an independent timestamp authority, and preserves everything in write-once storage behind fail-closed verification.

The system is built so that the honest answer to "why should we trust this?" is: you don't have to. Check it.