Permissions Are Corpus Design

ℹLeadership brief

What it is: deciding who may see which documents through the QA system, at corpus-design time — because retrieval quietly bypasses every access control your file systems already enforce.

What it buys: the QA system never becomes the path around your permissions. Without this, the system reads everything it indexed and repeats it to anyone who asks — the most common real-world failure of enterprise document AI, and one discovered by incident rather than by audit.

What to fund: an afternoon per question class with whoever owns the source documents’ access decisions, before the build — against the alternative of re-indexing the corpus after the incident.

Prompt first: map the permissions you are about to flatten

Here is the corpus manifest [paste], and for each source system the
documents came from, who can access it today [paste what you know].

Build the permission map this corpus must preserve:
  - for each document: who can open it TODAY, in its home system
  - group into ACCESS TIERS (all-staff / role-restricted / named-
    persons), tier per document
  - flag every document where you could not determine today's
    access - those are NEEDS-OWNER, not defaults
  - flag every document whose tier is MORE restrictive than the
    question class it serves - those are design conflicts to
    resolve before the build, not at serving time

Do not propose loosening anything. The map records what is, so the
corpus can preserve it.

The oversharing failure, mechanically

Your documents already have permissions. The filings live in a records system with roles; the field notes sit in an operations share; the board minutes are named-persons-only. Decades of access decisions, mostly right.

Indexing flattens all of it. The index is one artifact; retrieval searches all of it; the model reads whatever retrieval returns and repeats it to whoever asked. Every control in the home systems still works perfectly — and is no longer on the path. A junior analyst who could never open the board minutes asks a question, retrieval finds the relevant minute, and the answer quotes it, politely, with a citation.

Nothing malfunctioned. The system did exactly what it was built to do, because nobody told it that “in the corpus” and “visible to this asker” are different properties. This is the most common genuine failure of enterprise document AI — not hallucination, oversharing — and it is discovered by incident because no evaluation tested for it.

Decided here, because here is where it is cheap

The permission decision has exactly one cheap moment: now, while the corpus is being designed. The design outputs are simple:

A tier per document in the manifest — all-staff, role-restricted, named-persons — copied from what the home systems already enforce, not invented fresh.
A tier per question class — the failure-history class is all-staff; a contracts class serving named contract managers is not.
The conflict list resolved — a role-restricted document inside an all-staff class either moves tiers (with its owner’s sign-off), or leaves the class’s corpus slice. It does not stay as an exception someone will handle later.

One rule keeps the whole thing sane: the corpus slice for a class is no more sensitive than the class’s audience. When that cannot be satisfied, the class splits or the document leaves — the tension is resolved in design, where it costs a meeting, instead of at serving time, where it costs an incident.

One permission, followed through the training

Specification without enforcement is a label. Here is where each later module picks this up — the point of this lesson is that they can only enforce what you specify now:

Stage	What happens to the tier you set here
Module 3 (build)	retrieval filters candidate passages by asker-vs-tier, before anything reaches the model
Module 4 (evaluate)	the eval set gains permission questions: an asker outside the tier asks; the correct behavior is refusal
Module 5 (serve)	who-can-ask-what is enforced per class; opening a citation re-checks access to the underlying document
Module 6 (operate)	a tier change on any document is a re-eval trigger

⚠The failure mode of doing this later

Retrofitting permissions onto a built system means re-extracting the manifest, re-indexing with tier metadata, rewriting the retrieval filter, and re-running every evaluation — the full build, again, under incident pressure, with an executive asking why the analyst saw the minutes. Every one of those steps is a design column in the table above. “Later” is the same work at ten times the price plus the incident.

Stop and escalate when a document’s home-system access cannot be determined, or when preserving it would make a question class useless — both are decisions for the document’s owner and the service owner together. The builder’s authority here is exactly zero: copying an access decision is engineering; making one is not.

KNOWLEDGE CHECK

Every source system's permissions are intact and correctly configured. The QA system indexed everything, and an analyst's question returns a quote from a named-persons-only board minute. Which control failed?

Key takeaway

Indexing flattens decades of access decisions into one searchable artifact, and every existing control keeps working perfectly while no longer being on the path — which is why oversharing, not hallucination, is enterprise document AI’s most common real failure. Permissions are corpus design: a tier per document copied from the home systems, a tier per class, conflicts resolved where they cost a meeting instead of an incident. Everything downstream — the retrieval filter, the permission eval questions, citation re-checks, the re-eval trigger — enforces only what is specified here. Lesson 2.4 gives the manifest its final job: knowing its own version.

LEADERSHIP DECISION   fund the afternoon per class with the document
                      owners now, against re-indexing under incident
                      pressure later
PRACTITIONER ACTION   copy tiers from the home systems into the
                      manifest; resolve every tier-vs-class conflict
                      in design; never assign an access decision
                      yourself
SUCCESS MEASURE       zero documents indexed without a tier; zero
                      access decisions made by the builder; the
                      analyst who cannot open the minutes cannot be
                      quoted them either