Evidence

An attestation is a recorded, dated statement by a person: “our chatbot tells users it is an AI at the start of every conversation”, or “we reviewed the labelling of generated images before release”. On a system's Evidence page, Record a manual attestation asks which requirement you are addressing and, where the requirement lists specific points to cover, which of those points your statement covers.

Use it when the proof lives in a practice or a decision rather than in a file.

How Clause50 reads it afterwards:

• The requirement lists no specific pointsAny statement satisfies it.
• The requirement lists specific pointsCovering all of them — across one statement or several — reads satisfied. Covering some reads partial. Covering none reads missing: a statement that addresses nothing on the list proves nothing.
• Requirements that must be repeatedSome duties have to be confirmed on a recurring basis. A statement that has aged out of the current window reads stale — it satisfied the requirement once and needs refreshing.

An attestation is your word, recorded and time-stamped. Clause50 does not verify it and never claims to. Its value is that it is on the record, attributable, and unalterable afterwards.

Upload evidence, on the same page, takes any file: a policy, a model card, a risk assessment, a screenshot of a disclosure banner, a signed contract, a test report. Use it when the proof is a document.

What happens is worth knowing, because it is what makes an upload usable as proof:

1. Your browser computes a digest of the file — a short fingerprint derived from its exact contents, where changing a single byte changes the fingerprint completely.
2. Clause50 issues a short-lived, single-purpose upload address.
3. Your browser sends the file straight to storage. Clause50's own servers never handle the contents.
4. Clause50 then reads the stored file back, recomputes the fingerprint itself, and compares it with the one your browser reported. If they differ, the upload is rejected and no evidence is recorded at all.
5. Only once that check passes is the evidence recorded, carrying the verified fingerprint.

The effect is that your record does not merely say “a file was uploaded”. It commits to the exact contents of that file. A document swapped afterwards no longer matches the fingerprint the record committed to.

A connector is an automated way to collect evidence instead of typing it in every time. You set one up once on a system's Connectors page, and from then on Clause50 collects from it every hour — and on demand when you press Sync now.

Use one when the fact is already logged by a system you operate and re-typing it would be tedious and error-prone.

• OpenAI and AnthropicDaily usage totals — how many tokens were processed, by which models, over which period. Never the content of any conversation.
• GitHubA reference to each new change committed to the code repository you name — its identifier and the repository it came from, not the code itself.
• Log lakePoints at a bucket your own systems already export logs to, and reads new files as they land. For teams whose evidence is already being written somewhere, in a format they describe to Clause50 once.
• ManualNot automated at all: a way to bulk-import a spreadsheet of historical records. It needs no credentials.

Connectors covers credentials, formats and syncing in full — including why an ordinary OpenAI or Anthropic key will not work.

Expectation worth setting. Connecting OpenAI or Anthropic does not by itself improve your Article 50 score. Those services report totals, not conversations, so what the connector records is honest operational activity — not proof that a disclosure was shown to a user. To evidence what someone was actually shown you need a statement, a document, or interaction samples sent in through the API — no credential-based connector can produce them.

The fourth route, and the other machine one. A connector means Clause50 goes and fetches from a service it knows how to speak to; the API is the reverse — your own code pushes evidence in, from wherever it already knows the facts. A build pipeline can report the evaluation it just ran; a service can report the configuration it started with; a nightly job can send a batch of real interactions.

You generate a key on a system's API keys page and post JSON to it. Retrying a failed call is safe — a repeat of the same payload is recognised and recorded once, not twice. API has the endpoint, the limits and copy-paste examples.

If you cannot change the application's code — a vendor product, a CMS, something nobody wants to touch — you do not have to. There are documented patterns for tapping the traffic instead: a reverse proxy or edge worker in front of the app, an API gateway you already run, or a WordPress publish hook that reports each post after it goes live. Each is a copy-paste snippet that runs on your own infrastructure, never ours.

• The proof is a decision, a practice, or a reviewRecord a statement.
• The proof is written down in a documentUpload it.
• The proof is already logged by a service Clause50 speaks toUse a connector.
• The proof is in your own systemsPush it in through the API, point a log-lake connector at the bucket you already export to, or — if you cannot change the code — tap the traffic. A manual bulk import covers the one-off historical case.

The coverage page removes most of the guesswork: an unproved requirement carries a Fix link that points at the evidence page or the connectors page depending on what that particular requirement will actually accept.

Each requirement declares which kind of evidence it accepts, which is why recording the right kind matters — a statement does not satisfy a requirement that wants a code reference, and the reverse is also true. The kinds are fixed:

• AttestationA person stating that a requirement is met.
• Document uploadA file you uploaded.
• Usage statisticAggregate operational activity over a period.
• Commit referenceA pointer to a specific change in your source code.
• Interaction sampleA batch of real interactions. No credential-based connector produces these — they arrive through the API, from a log-lake connector, or from one of the traffic-tap patterns. This is the kind that can evidence what a user was actually shown, which the usage connectors cannot.
• Evaluation resultThe outcome of a test or evaluation run.
• Configuration snapshotA capture of how the system was set up at a point in time.

Every piece of evidence is added to the end of a per-system log, and nothing anywhere in Clause50 can change or remove an entry. This is enforced in the software and checked automatically every time it is built — it is not left to discipline.

That still holds even after a retraction (below). Retracting an item adds a new entry saying the earlier one no longer counts; it does not touch, hide, or remove the earlier entry's bytes, its fingerprint, or its position in the chain. “Voided” and “deleted” are different claims, and Clause50 only ever makes the first one.

The mechanism is a hash chain. A hash is a short fingerprint computed from a piece of content, where any change to the content produces a completely different fingerprint. Clause50 fingerprints each entry, and then folds the previous entry's fingerprint into the next one, so every entry is cryptographically linked to the one before it, back to the very first.

The consequence is that any change breaks the links. Alter an entry, remove one, reorder two, or insert one after the fact, and every link from that point onwards stops matching. Re-checking the chain identifies the exact position at which it broke.

Entries are added one at a time in a strict order, so two things recording evidence at the same instant cannot produce a duplicate position, a gap, or a broken link.

The chain also reaches your documents: every evidence pack Clause50 signs records where the chain stood at the moment it was produced, anchoring the document to a specific state of your record. Re-running the chain check is currently an operator-side action rather than a button on your own evidence page — Artifacts explains what you and your auditor can verify independently.

It depends what was wrong. If the evidence itself was wrong — the wrong file, a statement made against the wrong requirement — retract it (below): a short, mandatory reason and the entry stops counting towards anything, on the record as a correction rather than left to look like proof that never was.

If nothing was wrong and your system genuinely changed — you added a capability, changed how it operates — that is a different situation from a mistake, and retraction is the wrong tool for it: the evidence was true when it was recorded, it has simply been overtaken by events.

Either way, you add — recording a right statement, a new upload, or a retraction. Nothing is ever edited in place. Imported the same spreadsheet twice? The duplicates stay; retract the ones that shouldn't count.

This is deliberate, and it is the honest trade. An evidence record that can be tidied up after the fact is one an auditor has to take on trust. One that cannot be tidied up is occasionally untidy — and worth something. Duplicated evidence is a safe failure; lost evidence is not.

The practical consequence, worth planning around before you start: do not put anything into a statement or an uploaded file that you may later need to erase. A retraction voids an entry's effect; it does not remove the bytes, the fingerprint, or the fact that it was once said. Removing a single entry on request is not something Clause50 can do.

Retraction is for “I recorded the wrong thing” — an uploaded file that turns out to be the wrong one, a statement filed against the wrong requirement. On a system's Evidence page, an owner sees a Retract action next to any item that has not already been retracted. It asks for one thing: a reason, at least 12 characters, and mandatory — there is no way to retract without saying why, because the reason is what separates a correction from quietly tidying up the record.

What happens when you retract:

• A new entry is added, not an old one changedThe retracted item stays exactly as it was; a new, later entry records that it is voided and why. Nothing about the earlier entry — its content, its fingerprint, its position in the chain — is touched.
• The requirement it was evidencing is re-scored immediatelyYour coverage score reflects the retraction as soon as you confirm it — not on the next artifact you generate.
• A requirement that needed both a document and a statement needs both againRetracting the document half of a two-part requirement drops it back to missing, not to “statement only” — the requirement asks for a document and a statement about it, and one of the two has just been withdrawn.
• It shows up in every artifact generated afterwardsA retracted item leaves the main evidence register and appears instead in its own appendix — original entry, when it was retracted, and the reason in full. An artifact generated before the retraction is untouched and still verifies; the honest move is to generate a fresh one, not to withdraw the old one.
• It is permanentA retraction cannot itself be retracted. If you retracted the wrong item, record the right evidence again and explain the sequence in your next attestation — the record stays honest either way.

Retraction is not the same statement as “my system changed.” Retraction says a past entry was wrong from the moment it was recorded. A system that has genuinely changed since — a new capability, a different way of operating — is not a mistake to retract; that is a separate correction with its own mechanism, kept distinct so the wrong statement never lands in an otherwise honest ledger.