# Library — the shared file server, with authority classes

The Library is the platform's shared storage: the SMB file server on the storage tier, served to the operator panel over the control plane's API and to every agent box over WebDAV. Nothing else stores files for the organisation — a box's private working files and the shared Library live on the same share.

What the Library adds is the authority model. Every file carries one of three authority classes, and every agent box is deployed with exactly one.

Authority accumulates: a higher class sees every lower one. c2 reads c1 as well, by the rule and not by an extra grant. system sits above every class an agent can hold and is readable only by the operator panel.

A box deployed with no class has no Library access at all. So does a box with no department: there is no tree behind it to read.

# Where a file lives

<org>/<department>/library/<c1|c2|c3|system>/<path>

The Library hangs off the department it belongs to, rather than living in a tree of its own. That keeps a department's whole footprint under one directory, so an export, a snapshot and a department's removal all cover the Library too — and the six information levels the older files module uses (public, internal, confidential, pii, financial, legal_privileged) are left untouched.

Because the directory is the class, a file's class is decided by where it is put. There is no per-file flag to disagree with the path.

# Choosing a class when you deploy

The deploy wizard has a Library step, right before the confirmation. It asks two things:

• Authority level — no access, c1, c2 or c3.
• Directories shared with it — a comma-separated list of departments (finance, hr). Every directory shared with an agent carries the same class: the one chosen above.

Both answers land on the box at deploy time — the class on the box row, one share row per directory — so the agent can read its Library from the moment it comes up, and the panel shows the same thing the agent sees.

A box with no department has no filesystem at all. An unanswered department falls back to the workload slug, so a box always gets one; set it deliberately when the department differs from the business function.

# Changing it afterwards

#/library in the panel is the operator's view:

• the tree of classes and departments, from the registry rather than a directory walk — a department shared before its first box exists is visible here;
• upload, download, folder creation and delete, at any class (the operator holds system);
• Access permissions, where a box's class and its shared directories are set and re-set. Dropping a box to no access withdraws its shares with it.

GET /api/v1/library/authorities serves the classes and what each one reads, so the wizard, the panel and this page cannot drift from the rule in rekan.services.library_policy.

# What an agent sees

A box mounts the Library read-write at ~/library over WebDAV (/api/v1/library/dav), and sees exactly its own grant:

~/library/                     every department it may read
~/library/<department>/        the classes inside it (c1, and c2/c3 if it reaches)
~/library/<department>/c1/     the files

Three things hold on that mount, and they are the rule, not a convention:

• the tree above a department is computed from the box's class and its share rows — the share is keyed by department, so there is nothing above one to walk;
• every entry is checked as it is listed, so a listing can never name a file the box could not read;
• writing stays in the box's own department. A directory shared with an agent is something it may consult, not something it may edit.

Every decision — granted or refused — is appended to the file audit with the box, the coordinates and the reason. The credential is the same per-box token the private files view uses, so revoking it in the panel closes both.

# Related

• Storage — the share's backend, layout and operations (docs/storage.md).
• Runbook — deploying the storage tier and the boxes (docs/runbook.md).