{
  "schema": "org-writing@v1",
  "slug": "custody-is-not-visibility",
  "kg": {
    "id": "org:writing:custody-is-not-visibility",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "Custody is not visibility",
  "subtitle": "Holding duties for a container of someone else's material and being allowed to read inside it are two different powers",
  "abstract": "Why the party responsible for a shared container is not thereby entitled to read what is inside it, and the schema rule that keeps the two powers apart. The canonical treatment of the custody axis.",
  "kind": "brick",
  "topics": [
    "Privacy"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:privacy",
      "topic": "Privacy",
      "wall": "org:walls:engineering",
      "position": 3,
      "total": 6
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "Systems express organizational responsibility for a shared container by giving the responsible party ownership of it, which hands them read access as a side effect nobody decided to grant.",
      "claims": [
        "shall not process those data except on instructions from the controller"
      ]
    },
    "mechanism": {
      "text": "Custody answers who owes duties when a container has to be concluded and visibility answers who may read inside it, so a schema that derives reading from responsibility has collapsed two independent questions into one column and can no longer answer either separately.",
      "claims": [
        "grants zero read access and no read policy may reference the custodian"
      ]
    },
    "move": {
      "text": "Model custody and visibility as separate axes, and forbid any read policy from naming the custodian at all, so the separation is a property of the schema rather than a habit of the people writing queries.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/40-architecture/decisions/ADR-019-space-scope-and-custody-axes.md"
    },
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/40-architecture/decisions/ADR-023-audience-scoped-projection-engine.md"
    },
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/50-database/00-principles/architectural-rationale.md"
    }
  ],
  "canonicalPath": "/writing/custody-is-not-visibility/",
  "body": "Somebody has to hold the room. When a group has a shared container, a therapeutic space, a cohort, a family archive, one party carries the duties that only make sense at the level of the whole thing. Concluding it. Suspending it. Answering when a member leaves and something has to be done about what they left behind. Initiating erasure when erasure is owed. That party is the custodian, and the question almost every schema answers wrongly is what else the role comes with.\n\nEuropean data law has held the two powers apart for years without anyone calling it an architecture. Article 29 of the General Data Protection Regulation says that a processor, and any person acting under the authority of a controller or processor who has access to personal data, shall not process those data except on instructions from the controller. Access and entitlement are treated as different facts about the same person. Holding the material is a position; reading it is an act that needs its own authorization, and the law declines to let the first imply the second.\n\nSoftware collapses them constantly, and usually by accident rather than by decision. There is no column for the custodial container, so the product fakes one by giving the container to a member and adding an exception list on top, and now the party carrying the duties also carries a read path they were never separately granted. The mechanism of the failure is that custody answers who owes duties when the container has to be concluded and visibility answers who may read what is inside it, so a schema that derives reading from responsibility has folded two independent questions into one column and can no longer answer either of them on its own terms. What makes this worse than an ordinary permissions bug is that it never surfaces as one. Nobody filed a ticket asking for the custodian to be able to read the room. The read path arrived attached to the duty, and it is invisible precisely because it was never requested.\n\nThe correction we adopted is dull to describe and load-bearing to have. Custody became its own column, and the rule written next to it is that the column grants zero read access and no read policy may reference the custodian. Not that the custodian is denied by default and may be permitted later. That the read policies are forbidden from mentioning the role at all, which removes the shortcut rather than closing it. Downstream, where visibility is actually decided, the custodian is one audience key among many, and absent an explicit rule naming it, a custodian is refused exactly like a stranger. The duties still transfer when they have to, including the case where the custodian deletes their account and the container would otherwise be left with nobody answering for it. What does not transfer with them is a view inside.\n\nThe reason to hold this line has nothing to do with distrusting custodians, most of whom would never look. It is that a role which quietly includes reading cannot be given to anyone the group has not already decided to expose themselves to, which means the duties end up concentrated in whoever is most trusted rather than whoever is best placed to carry them. Separate the axes and custody becomes a job instead of a privilege, delegable to a person, an institution, or eventually a process, without anyone having to weigh whether that party deserves to read the room in order to keep it. A group that can name a keeper without naming a reader has more ways to be safe together than one that cannot.",
  "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:custody-is-not-visibility:r01",
        "author": "European Union",
        "work": "General Data Protection Regulation, Article 29 (processing under the authority of the controller or processor)",
        "year": 2018,
        "relevance": "The public precedent for the separation. A party with access to personal data is not thereby entitled to process it; the entitlement has to come separately, from instructions. The law treats holding and reading as different facts, which is the brick's whole claim in older language."
      },
      {
        "id": "org:references:custody-is-not-visibility:r02",
        "author": "MNSTRY platform documentation",
        "work": "ADR-019 (space scope and custody axes) and ADR-023 (audience-scoped projection engine)",
        "year": 2026,
        "relevance": "The internal decisions. ADR-019 introduces custody as its own axis and states the zero-read rule; ADR-023 is where visibility is actually decided and confirms that a custodian is denied like anyone else absent an explicit rule naming them."
      },
      {
        "id": "org:references:custody-is-not-visibility:r03",
        "author": "MNSTRY platform documentation",
        "work": "Database architectural rationale, Appendix A (historical design debates)",
        "year": 2026,
        "relevance": "The lineage of custody as a role rather than an ownership claim, including the orphan-adoption case in which custody of a shared document transfers when the original custodian's account is deleted. Evidence that duties move without a view moving with them."
      }
    ],
    "claims": [
      {
        "id": "org:claims:custody-is-not-visibility:c01",
        "claim": "GDPR Article 29 provides that a processor, and any person acting under the authority of a controller or processor who has access to personal data, shall not process those data except on instructions from the controller, unless required to do so by Union or Member State law.",
        "basis": "The regulation's own text, verified externally at authoring time.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:custody-is-not-visibility:c02",
        "claim": "Our space-scope decision record introduces a custody column that grants zero read access and no read policy may reference the custodian.",
        "basis": "ADR-019, which states the rule as a constraint on policy authorship rather than as a default that policies may override.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:custody-is-not-visibility:c03",
        "claim": "In our projection engine, custodian is one audience key among others, and absent an explicit custodian rule in a disclosure specification a custodian recipient is denied like any other recipient.",
        "basis": "ADR-023, which restates the separation concretely at the layer where visibility is computed.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:custody-is-not-visibility:c04",
        "claim": "Before the custody axis existed, organization-held containers were expressed by assigning them to a member's own scope plus an allow-list, which conflated custody with visibility.",
        "basis": "The context section of ADR-019, which names the conflation as the reason for the decision.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:custody-is-not-visibility:c05",
        "claim": "In our schema the scope columns are immutable after insert while custody is transferable, and the custodian reference restricts deletion so a container cannot be left silently without a custodian.",
        "basis": "ADR-019's immutability and referential rules, with the stated preference that failing closed beats vacant custody.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:custody-is-not-visibility:c06",
        "claim": "A historical design debate in our database rationale added orphan adoption, in which custody of a shared document can transfer when the original custodian deletes their account.",
        "basis": "Appendix A of the architectural rationale, recording the evolution from the earlier soft-delete-only answer.",
        "confidence": "verified",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:custody-axis",
        "name": "The custody axis",
        "definition": "Custody and visibility modeled as separate properties of a shared container rather than as one. Custody names who owes the terminal duties, concluding the container, suspending it, answering for a departing member, initiating erasure when erasure is owed. Visibility names who may read what is inside. The separation is structural rather than conventional only when read policies are forbidden from referencing the custodian at all, which removes the shortcut instead of denying it by default and permitting it later. Where the two collapse into one column, a read path arrives attached to a duty nobody requested it with, and the role becomes a privilege that can only be given to whoever the group already trusts to read rather than to whoever is best placed to keep.",
        "provenance": "canonical"
      }
    ],
    "researchContext": "Harvested from two architecture decision records and one appendix, none of\nthem citable, so the public anchor was added at authoring time. Article 29\nis the right anchor rather than Article 28 because Article 29 is the one\nthat speaks about persons with access rather than about contracts between\norganizations, and access without entitlement is the exact shape the brick\nis describing.\n\nThe deidentification gate did real work here. The source ADRs are written\nagainst a named tenant product with named container types, and none of that\nvocabulary survives into the brick. The generalized version is faithful\nbecause the ADR itself insists the axes are a primitive with no tenant\nvocabulary anywhere in them, which is the sentence that made the\ngeneralization safe rather than convenient.\n\nTwo things in the sources are deliberately unused. The interim fail-closed\nsemantics for non-ministry scopes are migration detail with no argument in\nthem, and the error-code allocation is internal instrumentation. What the\nbrick keeps is the rule and the reason a schema-level rule beats a habit."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "29079bfac2a5ec535f28ee8de7632f6977025b09302ecabc1d4713296ea3bd3b",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, privacy wave",
      "visibility": "published",
      "path": "/writing/custody-is-not-visibility/",
      "contentHash": "sha256:32cafd758082d71e",
      "releaseHash": "29079bfac2a5ec535f28ee8de7632f6977025b09302ecabc1d4713296ea3bd3b"
    }
  ]
}