CrawlQStudio

Product field note · Current as of 27 July 2026

Article 50: why compliance needs replayable memory, not just logs.

Every team facing Article 50 reaches for the same answer: we have logs. Logging is genuinely useful and it is genuinely the wrong shape. A log tells you that something happened. Article 50 asks how a specific piece of content came to exist — answered months later, to someone who has no reason to trust you. That is a different artefact, and it is worth naming the difference before you build against the wrong one.

This is not legal advice. There is no EU AI Act certification, and no tool can make you “compliant” or make a legal determination for you. What follows is an engineering argument about the shape of the record, plus a plain ledger of what is anchored today and what is not. Compliance outcomes depend on your specific AI use cases and context. Current as of 27 July 2026.

Logs versus replayable records

  • Answers the question

    A log

    What happened, in the order our system chose to write it down.

    A replayable record

    How this specific artefact was produced — the inputs, the constraints, and the decision path behind it.

  • Survives a dispute

    A log

    Only as far as the reader trusts the party holding the file.

    A replayable record

    The record carries a cryptographic receipt whose inclusion can be checked against a public transparency log.

  • Behaves under time

    A log

    Rotates, re-indexes, and is written for the engineer debugging today.

    A replayable record

    Written once, hash-committed, and designed to be re-read by a stranger in eighteen months.

  • Handles context decay

    A log

    The reasoning is gone; the surviving line is the outcome.

    A replayable record

    The evidence and the constraints that were in force stay attached to the artefact itself.

The question a regulator actually asks

From 2 August 2026, Article 50 of the EU AI Act requires businesses deploying AI systems that generate synthetic content to mark and disclose that content in EU-facing communications. For the dates and the fine tiers behind that, see the companion piece, the EU AI Act is a 2026 problem, not a 2027 one. If you want the obligation broken into checkpoints rather than argued about, the Article 50 compliance checklist is the practical companion to this piece.

The obligation is usually read as a labelling exercise. Mark the output, disclose the system, move on. But the labelling is the easy half. The hard half arrives later, when someone asks you to stand behind a specific label on a specific asset — and the honest version of that question is not did you mark it? but can you show, now, how this was made, in a form I can check without taking your word for it?

Once you write the question that way, the shape of the required artefact falls out of it. It has to be durable, because the question arrives long after the work. It has to be self-explanatory, because the person asking was not in the room. And it has to be checkable by an adversary, because a record only a friendly reader accepts is not a record — it is a claim.

Why a log is the wrong shape

An application log is written for the engineer debugging the system this week. It is chronological, it is operationally scoped, and it is optimised for volume. All three properties work against you eighteen months later.

Chronology is not causation: a log tells you what the system did, in the order it wrote things down, but the reasoning behind a generation is not a timestamped event and usually does not survive the write. This is what we mean by context decay — the outcome persists while the evidence and the constraints around it quietly stop travelling with it. And operational logs rotate. A retention window written for storage economics is not a retention window written for a regulatory horizon.

The deepest problem is trust. A log file is a document you maintain, on infrastructure you control, in a format you can rewrite. That is fine for debugging and weak for disputes, because its evidentiary value rests entirely on the reader believing that you did not touch it. Article 50 questions are exactly the situation where that assumption is not free.

What “replayable” means

A replayable record inverts each of those properties. It attaches to the artefact rather than to the timeline. It keeps the inputs and the constraints that were in force alongside the output, so the decision path can be re-read rather than reconstructed. And it commits to itself cryptographically, so that a later edit is detectable by someone who was never given access to the system that produced it. On what such a record contains in practice — across the seven regimes that ask for one, with Merkle chains explained in plain words — see what regulators expect from an AI content audit trail.

This is the distinction between what an organisation says and what its AI does. Brand memory governs the first — the corpus, the voice rules, the evidence a generation is grounded in; you can read how that is modelled on the knowledge graph page. The record described here governs the second: a replayable account of the constraints, the participating components, and the decision path behind a governed output — the mechanics of which are walked through on how GraQle works. Together they are what we mean by institutional memory for AI — and the second half is the one an auditor cares about.

The ledger: what is anchored today, and what is not

Here is where most vendor writing on this topic becomes vague, so we will be specific instead. There are four layers in the design. Two are shipped. Two are not. The table states which is which, and nothing in this article rests on the two that are not.

  • Layer 1

    Merkle receipt

    Shipped

    Governed decisions get a cryptographic receipt — canonical JSON, a Merkle tree, and an ed25519 signature. The receipt commits to the content, so a later edit does not go unnoticed, provided the original receipt is retained and compared against the record.

  • Layer 2

    Public Rekor anchor

    Shipped

    That receipt is anchored to the public Sigstore Rekor transparency log — infrastructure operated by the Linux Foundation, not by us. Anchored entries are publicly searchable by log index.

  • Layer 3

    AFER

    Roadmap — not shipped

    A richer evidence-record format is on the roadmap. It is not shipped, so nothing on this page depends on it. If your obligation needs it today, plan around the gap rather than assuming the capability.

  • Layer 4

    C2PA embedded credential

    Roadmap — not shipped

    An embedded, C2PA-style credential travelling inside the media file itself is on the roadmap, not shipped. What exists today is a record and an export — not a credential burned into the pixels.

The anchor is not a diagram. A real entry sits in the public Sigstore Rekor transparency log at log index 2195088939, on infrastructure the Linux Foundation operates and we do not. The controls behind it are described on our trust page, and the governance machinery itself is open to inspection — the engineering substrate is documented on the GraQle engineering page, where the compliance mapping documents can be read at the file level rather than taken on faith.

The partition worth stating precisely

There is a claim adjacent to this one that is tempting and wrong, and it is worth marking the boundary before someone else does.

The tempting version is that the whole chain is independent of CrawlQ. It is not. The export originates from your own CrawlQ tenant — you produce the record from the platform, and that first step involves our software by definition. What is genuinely free of CrawlQ is the step after the anchor: once a receipt has been anchored, its inclusion in the Sigstore Rekor transparency log can be verified against public infrastructure we do not run, with tooling we do not control, by someone who has never spoken to us.

So the accurate sentence is a narrow one: the post-anchor verification step is independent of CrawlQ; the end-to-end journey is not. That narrower claim is still the useful one — it is precisely the step where a sceptical auditor stops needing your cooperation. But precision here is not modesty for its own sake. A vendor who overstates the boundary once has told you what their other claims are worth.

What this means for your programme

If you are scoping Article 50 work now, the practical move is to separate two questions that usually get merged. First: are we marking and disclosing AI-generated content in EU-facing communications? That is the labelling half, and it is comparatively tractable. Second: for any given asset, can we produce a record of how it was made that a sceptical outsider can check? That is the records half, and it is where the log-shaped answer quietly fails.

The reason to care about the second now rather than later is that records cannot be back-filled. A replayable record has to be written at the moment of generation, because the evidence and the constraints that make it meaningful are only available then. An organisation that starts anchoring in August has an anchored record from August — and for everything before it, a reconstruction. For a fuller map of the obligations to specific mechanisms, with the limits of each one stated, see how brand memory changes your EU AI Act exposure.

None of this substitutes for counsel, and none of it is a certification. It is a claim about engineering: the records half of Article 50 can be made a property of the system rather than a promise about it — and the difference shows up on the day someone asks you to prove it.

Questions we get asked

What is the difference between an audit log and a replayable record?
A log is a stream of events written for whoever is operating the system. A replayable record is written for a stranger who arrives later and does not trust you: it keeps the inputs, the constraints in force, and the decision path attached to the artefact, and it commits to them cryptographically. The practical test is simple. If an auditor asks how a specific piece of content was produced eighteen months ago, a log gives you material to reconstruct a story from. A replayable record gives you a file you can hand over. Article 50 transparency is closer to the second question than the first.
Which parts of this are actually shipped today?
Two of four layers. Layer 1, the Merkle receipt — canonical JSON, Merkle tree, ed25519 signature — is shipped. Layer 2, anchoring that receipt to the public Sigstore Rekor transparency log, is shipped and publicly citable: log index 2195088939. Layer 3 (AFER) and Layer 4 (a C2PA-style credential embedded in the media file) are on the roadmap and are not shipped. We would rather publish the ledger than let you assume four layers where there are two.
Can an auditor verify the record without CrawlQ's cooperation?
Partly, and the partition matters. The export itself originates from your own CrawlQ tenant — you produce it from the platform, so that first step is not independent of CrawlQ. What is independent of CrawlQ is everything after the anchor: once a receipt is anchored, its presence in the Sigstore Rekor transparency log can be checked against public infrastructure we do not operate, using tooling we do not control. So the accurate claim is narrow and worth stating precisely: the post-anchor verification step is CrawlQ-free, not the whole chain. Anyone telling you the end-to-end journey is vendor-independent is overstating it.
Does anchoring to a public log expose my content publicly?
No — your content is not exposed. What is anchored is a cryptographic commitment: hashes and a signature, plus whatever metadata fields the signed envelope carries, which are public by design — so confirm those fields are ones you are content to disclose. The transparency log demonstrates that a particular record existed in a particular form at a particular time. It does not publish the underlying material, and someone reading the log entry does not thereby read your brand corpus or your drafts.
Does this make my organisation EU AI Act compliant?
No, and treat any vendor who says otherwise with suspicion. There is no EU AI Act certification, and no software can make a legal determination on your behalf. What a replayable record does is make the records half of Article 50 an engineering property rather than a promise — which is the part software can genuinely carry. Whether your specific records satisfy a specific obligation is a judgement for your counsel. This is not legal advice.

See the controls, not the claims.

The trust page lists what is anchored, what is open to inspection, and where each claim stops. Read it before you take our word for any of this.