Skip to main content

GitHub estate operating model

Authority​

projects is authoritative for portfolio registry, lifecycle vocabulary, topology, lineage, maintenance queues, and cross-repository authority decisions.

It does not become the runtime home of the systems it describes.

Evidence model​

Every material field should be understood through one of three states:

  • observed — obtained directly from current GitHub metadata or executed evidence;
  • declared — explicitly accepted by Matías or a merged governing decision;
  • proposed — a working interpretation that requires semantic or runtime confirmation.

Unknown values remain unknown. Recent pushes are not releases, workflow files are not successful runs, and deployment instructions are not proof of an online current service.

Responsibilities​

Matías​

Matías owns final semantic authority:

  • lifecycle approval where historical or institutional meaning matters;
  • repository rename, archive, delete, and visibility changes;
  • secrets, deployment settings, domains, and billing-enabled APIs;
  • acceptance and merge of PRs;
  • decisions to revive research or consolidate systems.

AI agent​

The AI agent owns evidence synthesis and documentation-first movement:

  • inspect accessible repository metadata and text;
  • maintain the estate registry and reports;
  • repair READMEs and lifecycle banners;
  • draft authority, rename, truth-audit, and settings packets;
  • open and revise draft PRs;
  • review Codex output against the declared boundary.

Codex or local execution​

Codex owns bounded implementation requiring iterative local evidence:

  • whole-codebase inspection;
  • tests, builds, CI, containers, and dependency work;
  • data-pipeline execution;
  • command adapters and schema validators;
  • cross-repository extraction after an authority decision;
  • reproducibility checks for notebooks and historical outputs.

Required sequence​

  1. Observe current evidence.
  2. Represent it in the registry.
  3. Decide lifecycle, authority, or bounded next action.
  4. Execute only the approved change.
  5. Verify the resulting claim.
  6. Update the registry and generated reports.

Inspection alone never authorizes modernization, migration, or revival.

Change discipline​

Each PR should have one dominant purpose. Estate metadata, README repair, settings preparation, runtime repair, and repository consolidation should normally be separate changes.

Generated reports must be reproducible from canonical inputs. Product code, large datasets, secrets, and binary outputs do not belong in this control plane.