Skip to main content

Estate Producer Registry

The producer registry is the scheduler-neutral authority map for recurring, event-driven and bounded manual production across the estate.

It does not replace GitHub Actions, systemd, ChatGPT automations, manual scientific runs, or external runtimes. It declares what each producer is, what it is allowed to mean, what it consumes and produces, and where execution evidence should be reconciled.

Core distinction​

A scheduler answers when and where something runs.

A producer answers what semantic work is performed and what artifact or judgment it produces.

One producer declaration therefore remains stable even if its scheduler implementation changes. Conversely, two schedulers attempting the same semantic production should surface as an authority conflict rather than silently coexist.

Canonical sources​

  • estate/producers.yaml — compact core producer seed.
  • estate/producers.d/*.yaml — bounded producer-family shards loaded as one registry.
  • estate/schemas/producer.schema.json — producer declaration contract.
  • estate/schemas/producer-shard.schema.json — shard envelope contract.
  • estate/schemas/producer-run-receipt.schema.json — observed run evidence contract.
  • estate/producer-observability.yaml — observation strategy for each governed producer.
  • estate/schemas/producer-observability.schema.json — observability-policy contract.
  • scripts/producer_registry.py — cross-shard structural invariants.
  • scripts/producer_observability.py — deterministic observability validation/projection.

Validate with:

make producer-check
make producer-summary
make producer-observability-check
make producer-observability-summary

make check includes both the producer registry and producer-observability checks. See Producer observability for the observation modes and privacy boundary.

Admission rule​

The registry is intentionally not a census of every script, Make target, workflow job, or pipeline stage.

Admit a producer when at least one of these is true:

  1. it emits an artifact, release, projection, judgment or evidence packet with independently meaningful identity;
  2. another component can consume or reason about its output without needing the producer's internal implementation;
  3. it is an operationally meaningful sentinel or terminal acceptance boundary whose state matters independently;
  4. it is a mutation/publication authority that must remain visible even while held, broken or superseded.

Do not admit an internal helper merely because it computes something. Helpers remain capabilities/stages until a reusable or governable output boundary exists.

A composed pipeline may therefore expose multiple semantic producers even when they currently execute inside one workflow. Such coupled producers should use stable event or manual references when they have distinct output identity rather than pretending that one scheduler job is multiple independent schedulers.

Producer roles​

A producer may declare more than one role:

  • sense — observe external or estate state and identify changes.
  • acquire — obtain an external source.
  • materialize — turn an input into a governed artifact.
  • transform — produce a derived artifact.
  • synthesize — produce evidence-grounded interpretation.
  • release — create durable candidate/canonical transport.
  • publish — expose a current human- or machine-facing product.
  • verify — test maturity, integrity, freshness, or acceptance.
  • maintain — perform bounded maintenance work.
  • govern — classify state, closure, waiting, or required judgment.
  • project — compile a current operational projection.
  • route — move or route material without redefining its semantics.

Authority is not health​

authority.state describes intended semantic ownership:

  • canonical
  • candidate
  • duplicate
  • superseded
  • hold

It does not say whether the latest run was green.

Live observations belong in producer run receipts. This prevents a temporary infrastructure failure from rewriting semantic ownership and allows failures to be represented precisely.

A real but known-broken producer may therefore remain visible as unresolved/hold. This is preferable to deleting evidence of a still-configured mutation-capable scheduler.

Multi-axis run state​

A run receipt separates:

  • scheduler_state — did the trigger/runtime behave as expected?
  • execution_state — did the producer computation execute?
  • artifact_state — was a valid/fresh artifact produced?
  • terminal_state — did the real downstream/public acceptance boundary work?
  • authority_state — which semantic authority classification applied to this run?

This is deliberately richer than a single red/green workflow status. A public deployment can succeed while anonymous endpoint verification fails; a maturity gate can fail while a candidate release remains valid; a healthy scheduler can be executing a superseded producer.

Durability vocabulary​

Producer outputs must declare one of:

  • ephemeral
  • run_evidence
  • rebuildable
  • candidate_release
  • canonical_release
  • served_current
  • judgment_artifact

Cross-repository parents should not depend accidentally on short-lived runner state. If an artifact becomes a durable cross-repository dependency, its transport must be promoted explicitly.

A producer-local content-derived identity is not, by itself, proof of durable cross-repository transport. The registry may therefore call an immutable/replayable output rebuildable or run_evidence until its storage/transport contract is proven.

Cross-substrate reconciliation​

The registry may contain producers scheduled by:

  • GitHub Actions;
  • user or system systemd;
  • ChatGPT automations;
  • manual/event-driven execution;
  • external systems.

Substrate-specific observers are responsible for emitting or reconstructing producer-run-receipt@1 evidence. projects owns the common declaration and evidence semantics, not execution.

For local systemd, prefer a bounded host snapshot or receipt exporter over remote control of the host. For ChatGPT automations, stable public registry aliases should be used rather than private/internal task identifiers.

Coupled producers and composition​

The registry should make useful composition visible without prematurely extracting shared infrastructure.

Examples already present in the estate include:

  • official speech sources → immutable speech corpus release → deterministic chunks → Knowledge Inspect lexical consumer;
  • paper corpus → paper review/catalog projections → immutable review snapshot or knowledge experience release;
  • governed media channels → stable media items/text/segments/appearance indexes → monitored-media product surfaces;
  • governed geography source work → versioned geography/relation/crosswalk releases → downstream research consumers;
  • accounting evidence → canonical accounting transformations → report/catalog/professional-pack artifacts.

These are producer relationships even when execution is currently manual or embedded in a larger repository workflow. The registry records the semantic seam first; extraction into a shared package/runtime remains evidence-driven.

Human gates​

The registry records three independent gates:

  • external person-directed action;
  • publication;
  • mutation.

A sensing or synthesis producer may therefore run autonomously while consequential external action remains human-authorized.

V1 scope​

V1 begins with clear cross-substrate producers and then admits hidden/coupled producers only when their output boundary is already evidenced. It intentionally does not enumerate every historical timer, legacy declaration, helper script, or speculative future capability.

Local scheduler hygiene and live health should enter as observed evidence after reconciliation, not as guessed registry facts.