{ "schema": "org-writing@v1", "slug": "sovereignty-relocates-trust", "kg": { "id": "org:writing:sovereignty-relocates-trust", "type": "brick", "graph": "/kg.json" }, "title": "Sovereignty relocates trust", "subtitle": "Holding your own database moves the trust boundary from technical to legal, and the person who did not choose the tier pays the difference", "abstract": "What actually changes when an institution takes custody of its own data, argued from the section of our own architecture that concedes the point we would be assumed to resist. The canonical treatment of trust relocation.", "kind": "brick", "topics": [ "Privacy" ], "courseMemberships": [ { "course": "org:courses:privacy", "topic": "Privacy", "wall": "org:walls:engineering", "position": 5, "total": 6 } ], "publishedAt": "2026-08-03T00:00:00.000Z", "version": 1, "guidelinesVersion": 15, "brief": { "problem": { "text": "Letting an institution hold its own database is presented as strictly more private, but the threat models these systems ship with are built out of outside adversaries and never name the institution itself.", "claims": [ "has no adversary type for the data controller themselves" ] }, "mechanism": { "text": "Moving the database under the controller's own administration adds no adversary and removes none, but it converts the constraint on the party most able to read everything from a technical control into a legal obligation, and legal obligations bind after the query rather than during it.", "claims": [ "converts the constraint on the party most able to read everything from a technical control into a legal obligation" ] }, "move": { "text": "Disclose the tier to the people whose material is held under it, before onboarding rather than in the terms, and tell them plainly which of their rights the platform can still enforce.", "claims": [] } }, "sources": [ { "repo": "mnstry-monorepo", "path": "docs/10-platform/40-architecture/core/sovereign-database-architecture.md" } ], "canonicalPath": "/writing/sovereignty-relocates-trust/", "body": "Data sovereignty sells itself. Hold your own database, answer to nobody, and the vendor with the security team and the compliance department stops being a party to your clients' most private material. We build for this and we think it is often the right choice. It is also the argument we most want to state against ourselves, because the version of it that circulates is missing the party it most needs to name.\n\nEuropean law has been precise about who is responsible since 2018 and the precision matters here. Article 4 defines the controller as the party that determines the purposes and means of processing. Article 24 puts on that controller the duty to implement appropriate technical and organizational measures and to be able to demonstrate that the processing complies. Self-hosting changes none of it. An institution that moves the database under its own roof was already the controller and remains the controller, having simply become its own processor as well, and the erasure right a person exercises under Article 17 was always exercised against the controller rather than against whoever happened to be running the servers.\n\nWhich is where the honest accounting starts, and our own architecture notes make it in a section written to be uncomfortable. The threat model for a sovereign deployment treats the institution as the trusted role and has no adversary type for the data controller themselves. The mechanism, stated plainly, is that relocating the database adds no adversary to that model and removes none, but it converts the constraint on the party most able to read everything from a technical control into a legal obligation, and legal obligations bind after the query rather than during it. The comparison people reach for, a therapist opening a paper file, understates it by a wide margin. A filing cabinet imposes friction per file. A single statement over a client table returns every disclosure anyone ever made, in seconds, with nothing in the way, and the same notes concede that direct access of that kind sits outside what any application-layer audit log can see.\n\nThe cost of this does not land on whoever made the decision. The institution chose the tier; the people whose material is held under it were not asked and in most cases are not told. On a hosted tier a person who wants their data deleted asks the platform and the platform can enforce it, because the platform controls the database. On a sovereign tier that same person has to ask the institution directly, which is fine right up until the relationship is the thing they are trying to leave, and then their only remaining leverage is legal rather than technical. Sovereignty transfers a real power to the institution and transfers a real exposure to everyone downstream of it, and only one of those two parties was in the room.\n\nNone of that makes the sovereign choice wrong. It makes the sovereign claim narrower than it sounds, and our own conclusion is the narrow one: this option is not inherently more trustworthy, it is more controlled, and control is a good that some institutions genuinely need and some people genuinely want their practitioner to have. What the argument forbids is letting the word do work the architecture has not done. Say which tier holds someone's material during onboarding rather than in the terms. Say which of their rights survive it and which now depend on a letter to a regulator. Sovereignty is worth having, and it becomes worth trusting the moment the people who did not choose it are handed the same map as the person who did.", "apparatus": { "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.", "references": [ { "id": "org:references:sovereignty-relocates-trust:r01", "author": "European Union", "work": "General Data Protection Regulation, Articles 4(7), 17, and 24", "year": 2018, "relevance": "The legal frame that makes the relocation legible. Article 4(7) fixes controllership on whoever determines purposes and means, Article 24 puts the demonstrable-compliance duty on that party, and Article 17 directs the erasure right at the controller. Together they explain why self-hosting changes the topology without changing who is accountable." }, { "id": "org:references:sovereignty-relocates-trust:r02", "author": "MNSTRY platform documentation", "work": "Sovereign database architecture, unresolved design tensions", "year": 2026, "relevance": "The internal source, and an unusual one. It is a section of our own architecture written to argue against the position we would be assumed to hold, conceding that the threat model has no adversary type for the data controller, that SQL removes the friction paper files impose, and that the sovereign tier is more controlled rather than more trustworthy." } ], "claims": [ { "id": "org:claims:sovereignty-relocates-trust:c01", "claim": "GDPR Article 4(7) defines the controller as the party that, alone or jointly, determines the purposes and means of processing personal data.", "basis": "The regulation's own text, verified externally at authoring time.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c02", "claim": "GDPR Article 24 requires the controller to implement appropriate technical and organisational measures and to be able to demonstrate that processing complies with the regulation.", "basis": "The regulation's own text, verified externally at authoring time.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c03", "claim": "A person exercises the Article 17 erasure right against the controller, so where the controller holds its own infrastructure, enforcement runs through that controller rather than through a platform.", "basis": "The regulation's allocation of the duty, combined with the ordinary consequence that a party without access to the database cannot perform a deletion in it.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c04", "claim": "The unresolved-tensions section of our sovereign database architecture states that its threat model treats the institution as the data controller, a trusted role, and has no adversary type for the data controller themselves.", "basis": "The section's own opening claim, written as a self-criticism of the preceding architecture.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c05", "claim": "The same section states that a single SQL statement returns every client's disclosures in seconds where paper files impose friction, and that direct database access sits outside what application-layer audit logs record.", "basis": "The section's own text, including its rejection of the paper-file analogy as understating the risk.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c06", "claim": "The same section states that on the sovereign tier a person wishing to leave must ask the institution directly, because the platform cannot enforce deletion on a database it does not control, and that the person did not choose the tier.", "basis": "The section's client-exit and client-awareness subsections.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c07", "claim": "The same section concludes that the sovereign option is not inherently more trustworthy but more controlled.", "basis": "The section's own counter-narrative on tier positioning.", "confidence": "verified", "sources": [] }, { "id": "org:claims:sovereignty-relocates-trust:c08", "claim": "Relocating a database under the controller's own administration converts the constraint on the party most able to read everything from a technical control into a legal obligation.", "basis": "Follows from the controller definition plus the source's admission: on a hosted tier the institution's reading is bounded by a platform's access controls and audit surface, and on a sovereign tier those bounds are replaced by the institution's own legal duties. Not a claim that either arrangement is safer.", "confidence": "verified", "sources": [] } ], "concepts": [ { "id": "org:concepts:trust-relocation", "name": "Trust relocation", "definition": "What actually happens when an institution takes custody of its own database. The set of parties who can read the material does not shrink, and no adversary is added to or removed from the threat model. What changes is the kind of constraint on the party best placed to read all of it, which moves from a technical control enforced at the moment of the query to a legal obligation enforced after the fact. The exposure created by that move lands on the people whose material is held, who did not choose the tier and in most cases are not told which one they are under. Not an argument against sovereignty, which is often the right choice, but a bound on what the word alone establishes.", "provenance": "canonical" } ], "researchContext": "Harvested from one internal architecture document, and specifically from a\nsection that exists to state the case against the surrounding architecture.\nThat is the reason the brick was written. A document arguing against the\nposition its own authors would be assumed to hold is rare evidence, and the\nbrick's job was to carry that honesty out into public rather than smooth it.\n\nThe named practitioner and client personas in the source are removed under\nthe deidentification gate, and the argument is generalized from the\npractitioner case to institutions holding material about people they serve.\nThe generalization is safe because nothing in the mechanism depends on the\nprofessional relationship; it depends only on one party determining purposes\nand means while another party's material is what is held.\n\nDeliberately not used: the BYOM model-divergence tension, the network-effects\ntension, collective sovereignty, and the regulatory-asymmetry table. Each is\na real argument and none of them belongs to this one. Also deliberately not\nargued is any comparative security claim between tiers. The source gestures\nat managed infrastructure being objectively more secure in some respects,\nand no evidence available to us settles that, so the brick makes the narrow\nclaim about where trust sits and refuses the broad one about which tier is\nsafer." }, "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json", "releaseHash": "f498ddd55f9133b512d314baa0235113f21d8b2ba76553a22c3c4aa3471679ae", "versions": [ { "version": 1, "cutAt": "2026-08-03", "note": "Initial publication, privacy wave", "visibility": "published", "path": "/writing/sovereignty-relocates-trust/", "contentHash": "sha256:da2f2e1fd8eb5c98", "releaseHash": "f498ddd55f9133b512d314baa0235113f21d8b2ba76553a22c3c4aa3471679ae" } ] }