Skip to main content

Estate Surface Registry

The surface registry closes the gap between repository/producer governance and the places where work is actually reviewed, edited, queued or acted on.

It is deliberately not a file census. Drive and Sheets may contain hundreds of durable artifacts while only a small number deserve operational identity.

Canonical source: estate/surfaces.json.

Validate with:

make surface-check

Why this exists​

The estate already distinguishes repositories from producers:

  • repositories own local code, domain contracts and runtime behavior;
  • projects owns cross-estate semantic declarations;
  • producers declare meaningful recurring or event-driven production independent of scheduler implementation;
  • office-auto-lab executes bounded operational compilation.

A missing layer remained: surfaces.

A surface is something a human or machine can independently consume, inspect, edit, queue against, or treat as current state. Examples include CRM/PERSONAS, ATS 2026, Office Front Registry, Carry State, Control Tower projections, the Sheets Estate Registry, and remediation queues.

Without an explicit surface contract, old workbooks, historical Docs, copies, dashboards and generated artifacts can silently compete with the current operating system.

Core rule​

Storage is not authority.

Moving a file to Drive — Active, Reference, Restricted or Archive changes navigation/lifecycle context. It does not by itself promote the file into an operational surface.

Promotion requires all of:

  1. a stable semantic role;
  2. an owner/authority rule;
  3. at least one real consumer;
  4. a mutation policy;
  5. a freshness expectation;
  6. a reason it must remain operationally visible.

If one of those is missing, the artifact remains ordinary reference/history or a candidate.

Promotion states​

The surface participates in the current operating system. It must have a real substrate and consumer.

Promotion does not necessarily mean canonical authority. A projection can be promoted while remaining explicitly projection_only.

candidate​

The role is useful and the contract is understood, but the surface is not yet materialized or adopted. Candidate surfaces must not create a second master.

The first candidates are the People, Opportunity, and Events & Institutions frontiers. Their outputs remain proposals until a human-owned authority accepts or rejects them.

remediation​

A temporary operational surface exists because something is wrong: secrets, unsafe sharing, unresolved collaboration permissions, etc.

A remediation surface is successful when it shrinks toward empty. It must not become a permanent archive by accident.

reference / hold​

The material may be useful or unresolved but should not participate in routine operational compilation.

Authority rules​

The registry enforces one active canonical surface per semantic concept.

Examples:

  • CRM/PERSONAS owns human relationship-state truth.
  • Relational Operations is staging and never resolves conflicts against CRM.
  • ATS 2026 owns current application/search state; old out_df generations are evidence, not a parallel ATS.
  • Office Front Registry owns operational front identity/expression; it does not replace the semantic project registry in projects.
  • Carry State owns current operational carry/horizon state.
  • Control Tower projections are human-facing projections, not semantic authority.
  • Drive Governance is current Drive policy, while historical drive indexes remain references.

Operational closure​

The intended closed loop is:

world / repos / sources / people
        ↓
producers + evidence
        ↓
proposal / state / authority surfaces
        ↓
office-auto-lab compilation
        ↓
Control Tower / briefs / queues
        ↓
human judgment and bounded action
        ↓
writeback to the owning authority
        ↓
next sensing cycle

A decision made in a chat, brief or projection is not durable state until it is written back to its owning authority.

Drive and Sheets​

Drive governance and Sheets governance remain substrate-specific working systems:

  • Drive Governance — Map & Rules governs Drive naming, lifecycle, root, privacy and permission policy.
  • Google Sheets Estate Registry governs Sheet lifecycle, lineage, permissions and structural hygiene.

projects stores only their contracts and identity as surfaces. It does not copy sensitive rows or replace the human working state in those tools.

Office boundary​

office-auto-lab may consume a generated surface-registry context as advisory governance context.

It may report:

  • active surface count;
  • candidate/promotion backlog;
  • remediation queues;
  • missing/unknown associations;
  • projection/authority conflicts already declared by the registry.

It must not infer new authority from file activity, mutate canonical state, or turn Drive location into semantics.

Drift classes​

The governance sweep should increasingly report these as first-class drift:

  • active surface with no consumer;
  • candidate that has silently become de-facto operational;
  • canonical concept with more than one active master;
  • projection used as authority;
  • remediation surface that is growing rather than shrinking;
  • current producer whose output has no governed surface or durable artifact;
  • active surface whose declared producer no longer exists;
  • historical artifact still linked from current operations;
  • surface freshness outside its declared expectation;
  • broad-sharing exception without explicit review status.

Demotion rule​

A promoted surface should be demoted when its consumer disappears, its successor is established, or it no longer needs independent operational identity.

Demotion should preserve evidence and lineage. It normally means REFERENCE, SUPERSEDED, or archive — not deletion.