Estate: Detection & Governance

The Estate’s second half is everything that governs detection and oversight: the category taxonomy markers are classified against, the entity registry, the analysis plans and analyzers that drive the ingestion pipeline, the platform’s AI catalogue, and the legal-entity records behind ROPA reporting. Like everything in the Estate, these are managed once and read by every workspace.

Categories

Path: /estate/categories · Permissions: estate.categories:*

The sensitivity taxonomy: “Every workspace classifies markers against this list… Workspaces can re-weight individual categories but they all live in this catalogue.”

Each category carries a display name, a group (family such as Identity or Financial), a description, and three sensitivity axes scored 0–10: PII, CII (commercially sensitive), and Legal. Its effective sensitivity is, in the UI’s own words, “the highest of (PII + CII)/2 and Legal.” An LLM detection switch marks whether LLM-based detectors should look for the category. Categories also show a specificity value derived from their place in the taxonomy tree (more specific categories win when markers overlap).

The catalogue index shows findings by group, the most-found categories, and — usefully for tuning — a “defined but never fired” panel of categories that have never produced a marker. Categories are soft-discardable, and the estate weights here are the defaults that each workspace’s category scoring can override; overrides survive everything done here.

Sync from catalogue re-imports the shipped taxonomy: new categories are added and existing estate defaults (weights, group, parent) are reset to shipped values — workspace overrides are preserved. The Estate home’s Configuration badge points here when a deployment ships categories this installation hasn’t synced yet.

Entities

Paths: /estate/entities and /estate/entities/discovered · Permissions: estate.entities:* (including the distinct merge permission)

The registry of resolved identities — one record per name, of kind person, organisation, place, or other — built by the coreference stage of analysis rather than entered by hand. An entity’s page shows its kind, aliases (“surface forms that resolve to this entity — added by the coreference workflow and curators”), recent mentions, and a timeline; the page itself is read-only.

New entities arrive as pending and are curated in the Discovered entities queue (the card appears on the Estate home whenever anything is waiting). An entity seen often enough is confirmed automatically; everything else is a human call:

flowchart LR
    A["Detected during analysis<br/>(pending)"] --> Q{"Curation queue"}
    A -->|"observed 3+ times"| C
    Q -->|"Confirm"| C["Confirmed"]
    Q -->|"Narrow"| N["Confirmed, scoped to<br/>one workspace"]
    Q -->|"Merge into"| M["Absorbed as an alias<br/>of another entity"]
    Q -->|"Reject"| R["Discarded"]

Confirmation matters beyond tidiness: only confirmed entities feed the gazetteer detector, so curating this queue directly improves future detection. The queue supports keyboard pacing (j/k to move, c/x to confirm or dismiss).

Analysis plans

Path: /estate/analysis_plans · Permissions: estate.analysis_plan:*

The recipes that drive detection, described conceptually in The Ingestion Flow. A plan binds together, across a four-step form:

1. Details — name, description, and the minimum confidence floor (markers whose combined detector confidence falls below it are discarded).
2. Categories — which categories the plan detects; markers outside the list are set aside.
3. Custom rules — ad-hoc regex patterns mapped to categories, orderable by drag.
4. Analyzers — the detectors to run, the refiners in run order (drag to reorder — the top refiner runs first), and at most one coreference resolver (none disables entity resolution for the plan).

A plan’s page shows its category-group coverage, bound detectors, resolver, categories, custom rules, and a version history. Each plan is one of three kinds — lite (narrow and fast, used for real-time chat redaction; exactly one lite plan exists per installation), standard, or heavy (full chain plus coreference) — shown as a label on the plan; the kind is fixed when the plan is provisioned. Three plans ship with the platform: a Default Analysis Plan and Deep Scan Analysis Plan (both heavy) and a Chat Analysis Plan (lite).

Version pinning

A plan reads each linked analyzer as it was when the plan was last saved — in the form’s words: “editing an analyzer doesn’t reach existing plans until they’re re-saved.” This keeps detection reproducible: an analyzer change never silently alters a plan’s behaviour. Category sensitivities, by contrast, are always read live.

Analyzers

Path: /estate/content/analyzers · Permissions: estate.content.analyzer:*

The component catalogue analysis plans bind from, grouped into three families:

• Detectors find sensitive spans: Regex (pattern lists mapped to categories), Rules (named rule sets), spaCy and HuggingFace (machine-learning models, configured by family and model ID), and Agent (LLM-based detection). Two shipped gazetteer detectors — the Entity Gazetteer (matches confirmed entities) and the Substitution Gazetteer (keeps redaction consistent across re-scans) — appear in the catalogue and can be edited and bound to plans, but new ones aren’t created by hand.
• Refiners post-process detections in a plan-defined order (cross-label containment, list expansion, company-suffix and phone-country-code normalisation, address assembly, and geographic refinement of location spans). The last of these reclassifies a coarse detection into the most specific geographic category available — detection models label almost everything simply as a location — and shows as not found only where the install’s image lacks the address data set, which the published image carries (see Model data).
• Coreference resolvers (Fastcoref, TokenOverlap) cluster mentions into entities.

Each analyzer shows an availability status (ready / impaired / failed) from health checking, and its configuration. Sync from catalogue re-seeds the shipped analyzer set, like the category sync. Discarding an analyzer carries a warning worth taking seriously: “Plans that reference it will silently drop it from their effective stack.”

AI catalogue

Path: /estate/ai · Permissions: estate.ai.*

The platform-wide AI registry, with a dashboard whose Setup checklist walks the whole chain — “chats fail closed until every step is green.” Its surfaces:

• Providers — the vendor catalogue (OpenAI, Anthropic, …). A provider is Active once a credential is attached on its page (Attach a credential / detach); a provider without one can’t serve anything.
• Models — the model catalogue, with context windows, output limits, and per-million-token pricing. Refresh catalogue re-pulls the upstream model list.
• Credential wiring — a read-only view of which credential each provider uses; the credentials themselves live in the estate vault.
• Availability — the matrix of workspaces against providers and models, and the estate-side counterpart of each workspace’s own AI links. Two tiers of toggle: linking a provider to a workspace sets its defaults, and linking a model is the chat-creation clamp — a workspace can only start chats against models linked here.
• Reports — Usage (tokens, cost, latency over a selectable window) and Risk, which today focuses on detecting PII in prompts, with further finding types to come.

Organisations

Path: /estate/organisations · Permissions: estate.organisation:*

The legal entities operating the platform: “ROPA Article 30 attributes each processing activity to one of these.” Each organisation records its legal name, controller role (controller, joint controller, processor, or sub-processor), registration number, address, jurisdiction, and Data Protection Officer contact — the DPO’s name, email, and phone are encrypted at rest. Each card shows an Article 30 readiness score counting how many of the five required fields are complete, with missing details flagged on the record.

Caution

Unlike almost everything else in the Estate, deleting an organisation is permanent — “Delete this organisation? This cannot be undone.” There is no discard-and-restore here.

Review queue

Path: /estate/review · available to anyone with an estate permission

A single triage inbox for everything across the Estate awaiting a human verdict: suggested governing library books, discovered entities, jurisdiction placeholders, and lapsed country-adequacy reviews. Filter by stream, pace through with the keyboard (j/k to move, c/x to confirm or dismiss); each verdict is recorded against the owning record.