Dekimu Hub now generates a Record of Processing Activities under GDPR Article 30 straight from the Compass data map, the processing a workspace actually records, and bundles it by hash into a signed ar.compliance.v1 receipt. Every field in the register is marked by how it is backed: proven by a receipt, asserted by you, or required and still missing. The explainer lives at dekimu.com/ropa and the register ships inside Hub's Comply set.
Article 30 asks for a written record of each processing activity: who the controller is, the purposes, the categories of data subjects and data, the recipients, any transfer outside the EU, the retention envisaged and the security measures. The under-250-employee exemption is narrow and falls away the moment processing is regular or touches special categories, which covers most active businesses. When a supervisory authority asks, the register is the first document it requests.
Compass does not ask you to describe your business in a questionnaire. Every Hub module that touches personal data declares what it processes, why and for how long in a shared PII map, and the register is compiled from that map plus the receipts the workspace has already minted. Each field carries one of three marks. A tick means a verifiable receipt backs it, a recorded retention period or a completed erasure for instance. A dot means you asserted it: true if your input is true. A warning means Article 30 requires it and nothing has recorded it yet. The register flags the gap instead of inventing a value.
The register is canonicalised and hashed on every compile. Two versions diff into a field-by-field change set whose hash is bound into a signed version receipt, and consecutive version receipts form an append-only chain that a verifier can walk end to end. Exporting gives you a readable Markdown register for review or filing and a ropa.register.v1 receipt signed with the workspace key, so the version you handed over can be checked later at verify.dekimu.com as exactly what Compass produced on that date.
The register flags what is missing instead of inventing it, so an auditor can tell proven from asserted from absent at a glance.
The compliance bundle is the twenty-first family in the Anchored Receipts register: a workspace-level Proof-of-Compliance snapshot. It references the RoPA register by its hash and embeds the signed register receipt; it references the impact-assessment receipts that evidence a DPIA, or records a not-applicable declaration with its basis when no Article 35 trigger exists; and it references obligation evidence from the Compass engine. If no register has been generated, the bundle records a gap, not a blank. The bundle references its constituents and does not re-derive compliance from them, which keeps it honest about what it is: a snapshot with provenance, not a verdict.
RoPA is a compliance-management tool, not legal advice. The register reflects the information and activity recorded in your Hub workspace; you own the accuracy and completeness of the entries, it does not cover processing that happens elsewhere, and legal review is recommended.
Everything Dekimu publishes as open source now lives on one page, dekimu.com/open-source: the Anchored Receipts specification (anchors-spec, CC0) and the append-only anchors-trusted-issuers-chain, the dekimu-mcp server and the agents.txt package on npm, regulation-as-code (legal obligations as typed predicates over an evidence corpus), and claude-memory (decaying file-based memory for Claude Code). All of it is MIT, Apache-2.0 or CC0; all of it interoperates with Dekimu Hub as the reference implementation; and verify.dekimu.com is the public verifier for the receipts Hub issues.
This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.
← Back to blog