CMP42 // TRUST // GDPR-NATIVEDEEP DIVE 01 OF 03
// Trust · GDPR-native

COMPLIANT BY
CONSTRUCTION.

Most CRMs bolt data protection on afterwards: a consent plugin, an export script, a retention setting three tabs deep. CMP42 starts from the other end. Collect less, record every write, make every object findable — and GDPR duties become ordinary operations.

// What "by construction" means

NOT A PLUGIN.
A PROPERTY.

Art. 25 GDPR asks for data protection by design and by default. In practice that is hard to retrofit: if a CRM ships with two hundred fields on a contact, every one of them is an invitation to collect data you have no purpose for. If writes are not attributed, accountability depends on someone remembering who changed what.

CMP42 is built so that the compliant path is the default path. The data model is lean until you extend it. The audit trail is not a feature you switch on — it is how writes work. And because every object in the graph is addressable, questions like "what do we hold about this person?" have a structural answer.

// Four mechanisms

HOW THE ARCHITECTURE DOES THE WORK.

Art. 5(1)(c) · Minimisation

Lean defaults

Default models cover the CRM primitives — contact, company, deal, task, activity — and nothing more. Extension is explicit and versioned in git. If a field is not on your ontology, it is not on your contact. Validation at write-time rejects fields that were never declared.

Art. 5(2) · Accountability

Audit trail on every write

Every object is versioned and every write records the human or agent that produced it. Processes log each transition and can be replayed against a past snapshot. You can show what happened, not just assert it.

Art. 20 · Portability

Export

Your data is typed objects with typed edges, not a proprietary blob. If you leave the Alpha, your data is exported to you in a standard format: JSONL for every record (one object per line), JSON for the Model schemas and Process definitions, and CSV as a convenience layer for tabular views. Edges are preserved as IDs and re-resolve on import.

Art. 17 · Erasure

Deletion

If you drop out of the Alpha, your data is exported to you and deleted from our side within 30 days. Because every object sits in one graph instead of five silos, deletion does not depend on hunting through disconnected tools.

// Who is responsible for what

CONTROLLER, PROCESSOR, YOUR MODEL.

GDPR assigns responsibility by role, not by who owns the server. In a CRM, the roles are clear once you name them — and with AI agents in the loop there is a third party worth naming explicitly.

PartyRole under GDPRWhat that means in practice
You, the customerController (Art. 4(7))You decide why and how personal data is processed: which models exist, which data goes in, which agents and processes act on it. Data subject requests are addressed to you.
protagx, on the managed tierProcessor (Art. 4(8), Art. 28)protagx processes the data on your behalf and on your instructions. The data processing agreement (AVV / DPA) under Art. 28 is available on request.
The AI model provider you connectYour choice, your contractCMP42 ships no proprietary model. When you connect an agent, the context it reads goes to the provider you selected. That relationship is yours to assess and contract.
Self-hosted deploymentsYou operate everythingCMP42 runs on your Postgres and object store. Nothing leaves your environment, so there is no hosting relationship with protagx for that data.

Current sub-processors on the managed tier: Hetzner Online GmbH (hosting, Germany), Google Ireland Limited (Google Workspace, mailbox operations), and Twilio Ireland Limited (SendGrid, transactional mail). The full list and the AVV / DPA template — modelled on the EU Commission Standard Contractual Clauses (Module 2) — are handed to Design Partners as PDFs during onboarding. Changes to the sub-processor set are announced in writing at least 30 days before they take effect.

// Data subject rights

ART. 15–22, ANSWERABLE.

A data subject request is really a graph question: start at this person and find everything connected. In a CRM made of silos, that means searching five tools and hoping. In CMP42, a contact is a node with typed edges to the deals it owns, the documents it authored, the notes written about it — each addressable by URI, each versioned.

That structure is what makes the rights below operationally realistic for a small team.

The shape below illustrates the idea using the Context tools get_context and list_related. It is not the final API; the concrete surface is shaped with the Design Partners.

Art. 15 request · as a graph walkIllustrative
# "What do you hold about Dana R.?"
get_context   cmp42://contact/…          # the person
list_related  cmp42://contact/…
  owns     → deal:  cmp42://deal/…       # "Aspen · Q4 renewal"
  authored → doc:   cmp42://doc/…        # "Renewal plan v3"
  about    ← note:  cmp42://note/…       # written_by: agent:claude
versions: every object · attributed · exportable
Art. 15AccessWalk the graph from the contact and list every related object, with its versions.
Art. 16RectificationCorrect the object; the version history shows who changed what, and when.
Art. 17ErasureTyped edges show what is linked to the person, so nothing is missed in a forgotten silo.
Art. 18RestrictionProcesses are explicit and logged, so you can see which runs touch the data.
Art. 20PortabilityStructured, typed objects export cleanly — no screen-scraping a UI.
Art. 21ObjectionNamed processes make it clear which processing a person can object to.
Art. 22Automated decisionsHuman-in-the-loop approval hooks put a person in front of consequential agent writes.

In the Alpha, data subject requests are handled manually through the admin data table: filter by email or contact ID, walk the typed edges to gather every related object, export the result as JSONL, delete with an audit-trail entry recording who requested and who executed the deletion. A dedicated DSR tool with a one-click export, a signed download link and a documented deletion receipt ships at GA. Between now and then, the same outcome is reachable — it just takes a few more steps.

// During the Alpha

WHAT WE COMMIT TO NOW.

  • AVV / DPA on request for Design Partners on the managed tier.
  • Export on exit. If you drop out of the Alpha, your data is exported to you in a standard format.
  • Deletion within 30 days. On exit, your data is deleted from our side within 30 days.
  • No training on your data. CMP42 does not train on customer data.
  • No third-party analytics, fingerprinting or session replay in the product.

The rights above are answerable today with the tools described in this section. Where the answer is manual in the Alpha — for example the per-person export in Art. 20 — the automated equivalent lands at GA (see the deep dive on Zero Tracking for the same pattern applied to the product’s own telemetry).

// And this website?

ZERO COOKIES. NO BANNER.

The site you are reading follows the same posture. It sets no cookies, runs no analytics and loads no third-party scripts, so there is nothing to consent to. The only personal data we receive is what you send us — by email or through the Design Partner application.

Read the privacy policy → · How zero tracking is enforced →