Repository estate vs work estate

Status

Declared cross-system authority note.

Purpose

Prevent repository identity, operational fronts, carry state, Office compilation, and Ops execution from collapsing into one overloaded notion of "project".

Canonical distinction

Repository

A repository is a technical GitHub-estate object.

• Canonical identity: stable estate repo_id bound to GitHub repository identity.
• Semantic owner: projects.
• Typical state: lifecycle, topology, lineage, readiness, observed GitHub metadata, repository-governance exceptions.
• A repository is not an operational front and does not inherit Office carry posture.

Operational front

An operational front is a unit of ongoing work, responsibility, commitment, or objective.

• Canonical identity: Office/front identity (front_id; legacy implementations may still use project_id).
• Semantic owner: Office.
• Typical state: carry posture, horizon, principal involvement, support needs, expected execution, escalation.
• A front may reference zero, one, or many repositories.
• A repository may support zero, one, or many fronts.

Repository/front relationships are many-to-many context, never identity equivalence.

Carry state

Carry state is the current operational posture of a front across time.

• Semantic owner: Office.
• It does not encode GitHub repository lifecycle.
• Repository readiness may inform Office, but it does not automatically determine carry posture.

Office compile

Office compile selects and prepares a bounded subset of the work estate for human judgment and execution.

• Semantic owner: Office.
• Inputs may include Front Registry, Carry State, capture/context inputs, constraints, and optional repository context.
• Outputs may include principal briefs, support queues, escalations, block candidates, and clock/today compilations.

Ops execution

Ops governs execution discipline after selection.

• Semantic owner: Ops doctrine/runtime surfaces.
• It owns block/session execution, evidence, stop rules, closure, next-touch and re-entry discipline.
• It does not own the canonical Front Registry, Carry State, or repository registry.

Human governance projection

Weekly boards, route cards, printables, and support indexes are interaction/documentation surfaces over canonical state.

• They may collect human annotations and decisions.
• They do not become a second canonical state store merely because they render or route that state.

Authority matrix

Concept	Canonical semantic owner	Producer / implementation	Consumers / projections	Must not be confused with
Repository identity	projects	GitHub estate registry/sensing	estate reports, Office context	operational front identity
Repository lifecycle/topology/readiness	projects	estate declarations + observations	maintainers, Office context	carry posture
Operational front identity	Office	Front Registry	Office compile, weekly human surfaces, Ops	repo_id
Carry state	Office	Carry State	Office compile, weekly human surfaces, Ops	repository lifecycle
Office compile	Office	office-auto-lab or successor runtime	Principal, Ops, review surfaces	weekly documentation
Ops execution + closure	Ops	human/agent execution process	Office reingest, evidence surfaces	Office selection
Weekly governance docs/surfaces	weekly-ops-governance	docs/site/printables	human operator	canonical weekly state
Ops doctrine/manual	ops-wiki	docs/site	human/agents	runtime state store

Cross-system rules

1. projects is authoritative for the GitHub repository estate, not for the operational work estate.
2. Office is authoritative for operational fronts and carry posture.
3. Repo identifiers and front identifiers are independent namespaces.
4. Cross-references between fronts and repositories are optional many-to-many relations.
5. Repository observations are advisory inputs to Office unless an explicit Office rule promotes them into work-state consequences.
6. Weekly governance surfaces project and route state; they do not supersede Office state.
7. Ops starts from an Office-compiled subset by default and returns evidence/closure recommendations; it does not reconstruct repository or front authority.
8. Physical implementation location may temporarily differ from semantic ownership during migration. Semantic authority moves first; code movement follows only after interfaces are explicit and validated.

Migration consequence

Repository-health semantics belong with the repository estate even if compatibility execution temporarily remains in office-auto-lab. This note does not itself move runtime code.