By Andy Boura🪶 A note on how this was written. This article was co-authored with the support of Claude, Anthropic's AI assistant. It draws on the principles and documentation developed while building and running the real-world working examples it describes.
Part 2 covered the platform that carries the hosting and the patching. The second principle is about evidence: what the platform does, who can do what, and whose data it holds, kept current without anyone assembling it.
Compliance is generated so it remains evergreen
Evidence assembled by hand is stale the day after it's finished. The fix is to write each fact once, next to the thing it describes, and generate everything else from it.
Every access role in the platform is defined alongside a note of what it is for, what it can do and what it must never do. Every storage bucket and log states whose personal data it holds, why, the lawful basis and how long it is kept. A test fails if a note is missing, or if the stated retention differs from what the infrastructure actually enforces. From those notes the platform generates its access inventory, its record of processing required by UK GDPR Article 30 and its data inventory, and another test fails if any of them is out of date. It is assessed continuously against OWASP ASVS 5.0 and achieves Level 3, the highest. Each site's public trust page is written in plain words from the same reports: this blog's trust centre is one.
What a note looks like
Here is the note on the role that writes the weekly backup, in plain words. In the code it sits right beside the role it describes, so it can't be overlooked when the role changes:
| What it is for | Adding a copy of each code repository that has changed to the backup store, when the weekly backup runs. |
|---|---|
| What it can do | Add new copies to the store, and read its record of what was last backed up. |
| What it must never do | Read, list or delete a copy, or change the store. A new copy never replaces an old one, and only the account's owner could loosen the store's protection. |
The access inventory is built from notes like this one and from the permissions the infrastructure actually grants, so the two can't quietly part company. The last row is the one a reviewer reads most closely: it says what the role must not be able to do, and the permissions beside it are where that is enforced.
Keeping the note beside the code matters for review as much as for accuracy: whoever approves a change to someone's access sees what that access is meant to be for in the same diff. It's the same idea as the evergreen, close-to-the-source documents in Compositional Reporting, applied to compliance evidence instead of status updates.
Keep each annotation in the same file as the resource it describes, generate the reports from them, and add a check that fails when one is missing or a report is out of date.
Rule for your agent, from the companion skill
The trade-off: consistency is not correctness
Generated evidence shows the documents match the code; it doesn't show the code is right. Independent testing still matters.
In part 4 I turn to the agent itself, and how to decide what it may do alone.