Filing standards

Admin → Filing standards is where a workspace admin sets the estate-wide conventions that every project’s Files page inherits. It’s an admin surface — project teams use the standards, they don’t edit them here.

Folder templates

A template is the standard folder skeleton a new project starts from. It’s edited as an indented outline — one folder per line, indentation for nesting — with a live preview that parses as you type and flags any bad lines. You can:

• Keep a draft while you work on it.
• Activate a template so new projects use it.

A folder line can carry bracketed flags:

Flag	Effect
[internal] / [admin-only]	Documents filed here default to a narrower clearance: [internal] adds the Internal (ddx) compartment, [admin-only] classes at the Client admin band.
[custom-children]	Projects may add their own subfolders here (under the add only policy).
[cde]	The controlled-document subtree root — gains the WIP/Shared/Published state machine. One per template.
[workflow]	Ordinary documents filed here keep the draft → issued step. Everywhere else the default is file-and-done: uploads land live. Use it for formal management folders (contracts, approvals).

Each template also sets Folder changes on projects — locked (folders change only through the template), add only (projects add and manage their own folders; the template’s standard folders stay fixed — the right setting for an estate standard), or full (standard folders may be changed per project, tracked on the Drift tab). To change a standard folder everywhere, edit it here and activate — never project by project.

What happens to existing projects when you activate

Activating a version reconciles every project on that template — live trees are never rebuilt, they’re diffed:

• Safe changes (new folders, renames) can apply automatically — if the fan-out setting on the Reviews tab says auto-apply safe-only changes. The default is to queue a review for every project.
• Anything that removes folders or changes who can see what always waits for a human: it appears on the Reviews tab with the full change list.
• A folder a project added itself is never touched — unless the new version retires the folder it lives in, which is flagged as a conflict: move the project’s folder first, then apply.

The Reviews tab

Each queued review shows the project, the version jump, and every step with its classification: green (applies as-is), amber (needs your acknowledgement — e.g. a move that changes partner visibility), red (needs a decision — a retired folder still holding documents: move the contents or keep them in place read-only). Tick the acknowledgements, pick the dispositions, Apply — or Dismiss to keep the project on its current version.

The Drift tab

One row per project: which template version it’s on, which is active, how many of its own amendments it carries, and whether a review is waiting. This is the “who is behind” view across the estate — and where you act on it:

• Dismissing a review parks it. The project stays on its version and shows here as behind; nothing re-queues by itself until the next template version is activated.
• Queue review (on any behind row) re-plans that project against the active version — if the diff turns out empty it fast-forwards silently; otherwise the review appears on the Reviews tab.
• Queue all behind does the same for every behind project at once, honouring the fan-out setting (safe-only diffs may auto-apply).

The naming registers

The coded container names (see Working with files) are assembled from four registers you control here:

• Type codes — drawing, model, schedule, report…
• Discipline (role) codes — architecture, structure, MEP…
• Suitability codes — the S0–S4 / A / B / CR lifecycle markers.
• Typology codes — the volume / room-type vocabulary.

You can add a code and retire or reinstate one — but never delete: a filed document’s name must keep resolving forever, so retired codes stay readable, they just stop being offered for new documents.

Backfilling existing projects

Projects created before the filing standard existed have no folder tree yet — their Files page and partner grant editors will be empty. The Instantiate filing for existing projects action builds the standard tree for every such project at once, from each project’s methodology template. It reports how many projects it set up, and skips any that already have folders.

Run this once after adopting the standard, or after activating a template for an estate that predates it. It’s safe to run again — projects that already have a tree are left untouched.

Backfill picks each project’s methodology default. If that guessed wrong, the project can switch template while it’s still empty — see Switching a project to a different template.