Compartments and delegated administration

A compartment is not a folder — it is a reach boundary. This page is for the two kinds of account that shape those boundaries: an administrator, and a clientadmin, the delegated compartment administrator an administrator can invite.

Where it is. Sign in to the portal and click Compartments in the left menu. It is a view in the portal, not a panel in the admin console — the portal is where a clientadmin lands and is the page that already knows which kind of account is signed in. The menu entry appears for an administrator and a clientadmin and for nobody else; that is presentation, and every route behind it re-decides authority on the server, per call.

A clientadmin holds exactly four powers over compartment structure — create, rename, merge and assign. An administrator holds the same four here, plus everything else the console does.

A clientadmin is also in charge of all users. It invites and creates accounts, resends and corrects invitations, disables and re-enables accounts, and reads the user list — the same account work an administrator does, and the reason the Invite, Emails and Users entries appear in its menu. Any number of clientadmins may exist, and a clientadmin may invite another one, so somebody can be a backup on the job.

What it can never do is create an administrator. That refusal is the vault's engine, not the page: an account able to mint an administrator could mint itself one, and then hold every power this list carefully does not give it. The console's own settings — the models, the mail relay, the retrieval dials, the sign-in policy — stay with an administrator too, because a setting is not a user.

create

Make a new compartment by naming it. Names are unique across the vault, so creating one that already exists is refused honestly and changes nothing — the refusal is the engine's own uniqueness rule, not a check this page performs first.

rename

Change a compartment's name. Choose the compartment from the pulldown and type the new name. Renaming moves nothing and widens nothing: the same people reach the same documents afterwards, under a different label. A name already in use is refused and the compartment keeps the name it had.

merge

Collapse a source compartment into a destination. Both the source's documents AND the source's people move; the source is then retired and its id resolves to nothing. This is the one power with consequences that outlive the operation — see 'Merging widens' below, and read the warning the page shows you before you press the button. It takes <strong>two steps</strong>: <em>Preview this merge</em> first, which counts what would move and names who would move, and only then <em>Merge compartments</em>. The vault refuses a merge that was not confirmed against a preview, and refuses one whose numbers have changed since.

assign

Give a person access to a compartment, or take it away again. Since the permissions surface unified (ADR-0045), this power is exercised on the <em>Permissions</em> view — the 🔑 entry — where access is a LEVEL: none, read, or write, and write always carries read. The compartments page keeps the three structural powers; it no longer carries an assign form of its own.

A clientadmin reads no document at all

This is the point of the account, not a limitation of it. A clientadmin holds zero compartment grants, so every document read is denied and audited — the same answer an administrator gets. It hands out reach and holds none.

The reason is merge. An account that could both merge compartments and read documents could merge any compartment into one it belonged to and then read everything that was inside it; merge would not be a structural power at all, it would be a universal read. So the compartment-permission truth table gives a clientadmin the same document reach as an administrator: none.

That is why the Compartments view shows compartment names, compartment ids, accounts and grants — and shows no document, no title, no size and no document count. There is no control there that asks for one, and there is not to be: the vault's own tests fail if a document-listing control ever appears on that surface.

Merging widens

Merging moves the source compartment's documents and its people into the destination, then retires the source. So everyone who belonged to the source compartment can afterwards reach everything already in the destination. That is not a side effect to apologize for — it is what merging means: two compartments becoming one is exactly the claim that their populations and their contents now share a boundary.

The page therefore states the widening before the click, naming both compartments — the source and the destination — by name. Read that sentence rather than the button. A warning that only said the act was permanent would be true and useless; the surprising part of a merge is not that it lasts, it is who can suddenly read what.

A merge is confirmed against what the preview counted. Preview this merge tells you how many people would move and names them, and — if you are the vault administrator — how many documents would move. A client administrator is not shown the document number, because a control reporting how much a compartment holds would be an inventory of documents that account cannot read; the vault still counts them, and still refuses the merge if the count has moved on. The confirmation the preview gives you is single-use and expires shortly, so a merge can never happen on numbers somebody read some time ago. If it expires, or if anything changed, preview again and read it again.

It is also irreversible through the interface. The source id resolves to nothing afterwards, and the boundary that existed before the merge is recoverable only from backups, where the engagement takes them — a bridge engagement takes none by design, so on one of those the boundary is not recoverable at all.

Who can be assigned a compartment

Assigning happens on the Permissions view (the 🔑 entry in the portal menu) since the grant surfaces unified (ADR-0045) — the compartments page keeps the three structural powers and carries no assign form of its own. The rule is unchanged wherever it is exercised: the vault refuses a grant to an administrator or a clientadmin, engine-side, on every call. Those accounts appear in the grid all the same, and the page says why setting a level on one will be refused rather than quietly removing them. Lowering a cell to no access takes the write away with the read, so there is no way to leave somebody able to file into a compartment they cannot open. A control that vanishes teaches nothing and a control that explains teaches the rule.

The rule includes your own account. A clientadmin cannot grant itself reach — one call, one read grant, and the 'reads no document' property everything above rests on would simply be gone. The power to widen other people's reach is only safe in an account that cannot widen its own.

Revoking is open to a clientadmin too, since migration 0022 widened it to the same authority as assigning. Revoking narrows, so it needs no counterpart to the refusal above — and a stray grant sitting on an administrator is exactly the thing revoke should be able to remove. On the unified surface, revoking is simply the none level: an assignment made there is undone there.

The permissions grid

A person's authority over one compartment is one of three levels, not two independent switches: no access, read (may ask questions of it), or write (may ask, and may upload into it). Read is the floor of write — somebody who can file a document into a compartment can always read it — so the pair of boxes in each cell moves together: ticking write ticks read, and unticking read unticks write. There is no fourth state, and the vault refuses one at the database itself, not only on the page.

Where it is. Sign in to the portal and click Permissions in the left menu, above Compartments. Rows are people, columns are compartments; a change to one cell is sent the moment you make it, and it is recorded on its own row of the audit trail.

Nothing on that page is paged or shortened. Every account and every compartment is in the table, because a permissions surface that hides rows teaches you that what you can see is the whole truth when it is not. The filter boxes narrow what you are looking at and change nothing about what is held.

Accounts that can hold no grant — an administrator, a clientadmin — appear in the grid with their boxes switched off and the reason written beside them, for the reason given above: a control that vanishes teaches nothing.

The grid shows no document, no title, no size and no count of them, exactly as the compartments page does not. A control reporting that a compartment held three hundred documents would hand an account that cannot read one an inventory of it.

What read-only means, and how access is changed

Read-only means you may ask, and may not add. With read on a compartment you can put questions to it and read the answers, with the documents behind them cited the same way they are for anybody else. What you do not get is a way to put anything in: the upload page says so in words rather than offering a form that could only be refused.

Read is the floor, not a lesser copy of write. Access to one compartment is a single level: no access, read, or write. Write is read plus the ability to upload, so anyone who can file a document into a compartment can always open it afterwards. Nobody holds write without read; the vault refuses that state in the database itself, not merely on the page.

Changing it is somebody else's act, and a visible one. You cannot raise your own level. An administrator or a clientadmin changes it on the Permissions view by setting your cell to a different level, and the change is audited with what the level was before it. Ask whoever administers your engagement; if you have been told your access was raised and the upload page still says otherwise, sign out and back in — the page decides what to offer from the authority the vault reports at sign-in.

Going the other way removes more than it names, on purpose. Taking read away takes write with it and leaves no access: an account that could file into a compartment it cannot open is exactly the state this vault does not allow.

Bulk apply, and why the preview comes first

Choose any set of people and any set of compartments and give every cell where they meet the same level. Shift-click a second box to take the whole range between it and the last one you clicked.

Preview is a separate step, and Apply is switched off until you take it. The preview states exactly what would change — how many cells would be raised, how many lowered, and how many are already correct — and writes nothing at all while it does. Change the selection or the level and Apply switches off again, because a preview of a selection you no longer have is not a preview of what Apply would do. A bulk change is the widest single act this product offers to an account that is not an administrator; the preview is not a courtesy.

It is a selection, not a group. Applying to thirty people and six compartments writes a hundred and eighty explicit cells, each separately visible, separately revocable and separately recorded. Nobody is a member of anything, so nobody quietly inherits reach months later because somebody else's list changed.

Recertifying access

A grant can be given an end date, and the recertification list on the Permissions view is every grant that reaches the end of one soon — soonest first, over the window this vault is configured with.

A grant with no end date is never on that list. It is not going to lapse, so a review that included it would be a review of the whole vault wearing a deadline's clothes. A grant that has already lapsed IS on it, marked expired: it reaches nothing — that is decided when access is worked out, not on this page — but the row is the record that the access existed, and the person reading the list is the person who should decide whether to renew it or take it away.

Extending is an act rather than a note. Every row of the cell moves together, so a read grant and the write grant it carries cannot come to disagree about when the access ends, and the trail records the date that was replaced as well as the date that was set — so it says what was recertified, not merely that something was. A cell holding no grant is refused instead of quietly doing nothing: extending access that is not there is a mistake about who can reach a compartment, and a verb that swallowed it would let a reviewer believe they had renewed something they had not.

Permission history

What access each person has held over time. It is a read of the audit trail rather than a second record of its own, so there is no possibility of it disagreeing with what happened, and each row names the level before the change as well as the level after it — hr: write → read is legible on its own, where a row naming only the result would make you replay the whole history to learn what changed.

A bulk apply appears as one row per cell, never as a single row for the batch, so revoking one person's reach is exactly as visible whether it happened alone or inside a change of a hundred and eighty.

The names are today's names. Compartments get renamed and merged and accounts get disabled, and the vault keeps no history of names — the trail stores ids. So the page says so in words, and shows the id beside every name. A history that silently painted a current name onto a past act would be a surface that lies quietly, which is worse than one that shows you an id.

Retention: how long a compartment keeps what it holds

A retention class is a rule with four parts: how long to keep something, which date to count from, what to do when that time is up, and a grace period before anything happens. A class is assigned to a compartment, so “how long do we keep this” is answered per compartment rather than once for the whole vault. Inside a compartment you can override the class for one kind of document, because “invoices seven years, everything else three” is the ordinary rule rather than an exotic one.

A compartment with no class keeps everything, for ever. Retention is something you switch on, one compartment at a time. This vault ships with no classes at all, so until somebody makes one, nothing in it is ever due for anything.

Nothing is destroyed until you have said so twice. A new class is set to review, which means the nightly run only ever produces a list: these versions have reached their age. Somebody reads that list and decides. Destroying on a schedule takes three separate, audited acts — create the class, assign it to a compartment, and then change it to dispose. A vault whose whole promise is the fidelity of a record should not delete on a timer that one click turned on.

A document nobody has dated is never disposed of by date. If a class counts from the document’s own date, and the vault did not read that date out of the document itself, the version goes onto the review list naming that as the reason instead. A date the vault guessed would destroy the wrong document and issue a certificate saying it was the right one. Counting from the day a document was admitted is the other choice, and it is always known.

The grace period exists so that changing a rule is never the same thing as acting on it: a version that becomes due waits out the grace before a disposal run will touch it, so a class edited this afternoon destroys nothing tonight. And a legal hold refuses a disposal exactly as it refuses any other purge — a held version is reported as held rather than quietly skipped, because a list that silently omitted it would read as though nothing were being preserved.

Nothing here is decided by the page

Every control calls a route that re-decides authority on the server, and every route rides an engine function that re-checks compartment-administration authority per call. An ordinary account does not see this surface — and is refused at the route and at the engine if it reaches past the page anyway. Each refusal is audited.