Skip to main content

Developer Docs

Metadata​

  • Owner: Origo Engineering
  • Last updated: 2026-04-17

Purpose​

  • This section is the canonical developer and maintainer hub for Origo.
  • Read this page first if you need contributor workflows, governance reading order, release and maintenance routes, or the documentation system contract.
  • Governance authority remains machine-readable in AGENTS.md and contracts/governance/.
  • Developer docs explain how to work with Origo; they do not replace machine governance authority.

Reading paths​

New contributor​

  1. docs/Developer/Contributing.md
  2. docs/Developer/Local-Environment-And-Stack.md
  3. docs/Developer/Tests-And-Gates.md
  4. docs/Developer/Governance-Reading-Guide.md

Maintainer​

  1. docs/Developer/Release-And-Deployment.md
  2. docs/Developer/SQL-Migrations.md
  3. docs/Developer/Proof-And-Evidence-Workflow.md
  4. docs/Developer/Documentation-System.md

Documentation work​

  1. docs/Developer/Documentation-System.md
  2. docs/README.md
  3. docs/Reference/README.md
  4. docs/Packages/README.md

Canonical docs system​

  • Product home page:
    • README.md
  • Canonical public docs hub:
    • docs/README.md
  • Canonical reference index:
    • docs/Reference/README.md
  • Canonical package index:
    • docs/Packages/README.md
  • Documentation system contract:
    • docs/Developer/Documentation-System.md

Core developer workflows​

  • Contributor workflow:
    • docs/Developer/Contributing.md
  • Local stack and tooling:
    • docs/Developer/Local-Environment-And-Stack.md
  • Tests, CI gates, and review expectations:
    • docs/Developer/Tests-And-Gates.md
  • Governance reading order and contract routing:
    • docs/Developer/Governance-Reading-Guide.md
  • Release, deployment, and operational maintenance:
    • docs/Developer/Release-And-Deployment.md
  • SQL migration authoring and application:
    • docs/Developer/SQL-Migrations.md
  • Proof, observability, and evidence expectations:
    • docs/Developer/Proof-And-Evidence-Workflow.md

Canonical governance routing​

  • Task-type routing surface:
    • AGENTS.md
  • AGENTS router format:
    • json_document
  • Programmatic contract resolver:
    • from origo.governance.contract_loader import read_contracts
    • origo.governance.contract_loader.read_contracts
    • contracts = read_contracts(task_type='governance')
  • Canonical machine governance contracts:
    • contracts/governance/governance-authority.json
    • contracts/governance/master-doctrine.json
    • contracts/governance/governance-surface-analysis.json
    • contracts/governance/git-workflow-discipline.json
    • contracts/governance/venv-discipline.json
    • contracts/governance/release-closeout-discipline.json
    • contracts/governance/removed-authority-surface-eradication.json
    • contracts/governance/probe-discipline.json
    • contracts/governance/task-start-gate.json
    • contracts/governance/task-end-gate.json
    • contracts/governance/static-analysis.json
    • contracts/governance/documentation-contract.json
    • contracts/governance/github-issue-authoring.json
    • contracts/governance/slice-closeout.json
    • contracts/governance/pr-review-routing.json
    • contracts/governance/task-types.json
    • contracts/governance/task-decomposition.json
    • contracts/governance/slice-planning.json
    • contracts/governance/request-task-coverage.json
    • contracts/governance/contract-applicability.json
    • contracts/governance/dagster-authority.json
    • contracts/governance/failure-semantics.json
    • contracts/governance/ingest-throughput.json
    • contracts/governance/performance-sla.json
    • contracts/governance/platform-stack.json
    • contracts/governance/retention-capacity.json
    • contracts/governance/storage-sql-discipline.json
    • contracts/governance/historical-surface.json
    • contracts/governance/integrity-durability.json
    • contracts/governance/rights-secrets.json
    • contracts/governance/runtime-recovery.json
    • contracts/governance/observability-day-zero.json
    • contracts/governance/observability-as-proof.json
    • contracts/governance/raw-fidelity.json
    • contracts/governance/event-sourcing.json
    • contracts/governance/source-prioritization.json
    • contracts/governance/source-onboarding.json

Live runtime reference inventory​

  • Runtime API contract:
    • docs/raw-query-reference.md
    • docs/raw-export-reference.md
    • docs/aligned-reference.md
    • docs/data-taxonomy.md
    • docs/failure-semantics-reference.md
    • docs/observability-reference.md
    • docs/observability-as-proof-reference.md
    • docs/payload-schema-reference.md
    • docs/late-arrival-reference.md
    • docs/performance-reference.md
    • docs/source-pressure-reference.md
    • docs/retention-capacity-reference.md
  • Runtime observability contract:
    • docs/observability-reference.md
    • docs/Developer/observability-reference.md
    • docs/Developer/observability-as-proof-reference.md
    • docs/Developer/retention-capacity-reference.md
  • Event/runtime contract:
    • docs/event-serving-reference.md
    • docs/projection-rebuild-reference.md
    • docs/adapter-boundary-reference.md
    • docs/dedup-strategy-reference.md
    • docs/late-arrival-reference.md
    • docs/payload-schema-reference.md
    • docs/source-pressure-reference.md
    • docs/retention-capacity-reference.md
    • docs/source-authority-reference.md
    • docs/Developer/late-arrival-reference.md
    • docs/Developer/performance-reference.md
    • docs/Developer/payload-schema-reference.md
    • docs/Developer/source-pressure-reference.md
    • docs/Developer/retention-capacity-reference.md
    • docs/Developer/failure-semantics-reference.md
    • spec/slices/slice-14-event-sourcing-core.md
    • spec/slices/slice-21-canonical-aligned-contract.md
    • spec/slices/slice-34-full-canonical-backfill/docs/s34-canonical-backfill-runtime.md
    • spec/slices/slice-34-full-canonical-backfill/docs/s34-bitcoin-height-window-contract.md
    • canonical event rows are full-envelope rows with source identity, domain_event_type, schema_version, correlation_id, nullable causation_id, and producer provenance
    • unreplayed pre-S39 historical rows may keep those added metadata fields null until replay/rewrite completes; new writes must populate them
    • domain_event_type is canonical domain taxonomy and must not be confused with runtime-audit event_type
    • canonical storage ordering is per stream key (source_id, stream_id, partition_id) via stream_sequence, allocated at the store boundary against ClickHouse-backed head state
    • stream-head authority is ClickHouse-only; no second head store or lease service is allowed
    • authoritative head components are canonical_stream_sequence_heads, canonical_event_log_active_v1, and canonical_partition_reset_boundaries
    • every authoritative append must target exactly one canonical stream key; same-stream multi-row append is allowed, mixed-stream authoritative append is forbidden
    • authoritative append requires a lineage-aware expected head consisting of stream identity, reset-boundary lineage, and current-truth last_stream_sequence
    • unreplayed pre-S42 rows may still keep null stream_sequence until rewrite cutover completes, but any incremental write that would idempotently dedup against those rows must fail closed and requires replay/rewrite first
    • current-truth active views are read authority, but raw append-only event-log continuity is ordering/gap authority
    • exact duplicate identity short-circuits to duplicate before stale-head conflict evaluation; stale-head conflict is a fail-fast write conflict, not a duplicate
    • caller-visible automatic retries on write conflict are forbidden; bounded internal visibility verification without append reissue is allowed
    • projector fetch, resume, checkpoints, and watermarks must advance by stream_sequence, not by ingested_event_id or derived offset ordering
    • canonical source authority is frozen in contracts/canonical-source-authority-v1.json; selector-aware ETF and FRED families must pass structured authority claims and non-authoritative writes must fail before append
    • canonical timestamp semantics are frozen in contracts/canonical-source-timestamp-semantics-v1.json; source_event_time_utc now means the canonical family time reference, and the precision registry is subordinate numeric metadata rather than timing authority
    • canonical late-arrival and projection-time authority are frozen in contracts/canonical-late-arrival-v1.json; current data-serving projections remain event_time, but that governs bucket/window or record-timestamp semantics only while stream-sequence checkpoints and watermarks remain operational progression state
    • canonical dedup semantics are frozen in contracts/canonical-dedup-strategy-v1.json; canonical dedup is authoritative only at the write boundary, uses current-truth lineage after reset boundaries, and ETF/FRED identity excludes value fields
    • canonical payload-schema authority is frozen in contracts/canonical-payload-schema-v1.json; schema identity is (source_id, stream_id, schema_version), domain_event_type is taxonomy only, and both writer-mediated and direct insert paths must validate the final canonical payload_json before append
    • current-truth canonical event-log reads must use canonical_event_log_active_v1
    • raw append-only canonical event-log history must use canonical_event_log_history_v1
    • observability is derived-only and must render authoritative Dagster, ClickHouse, and audit truth rather than invent parallel status

Slice-specific developer records​

  • spec/slices.json records slice sequence, status, authority, and explicit structural inconsistencies only.
  • Historical completed slice records live under spec/slices/*.md.
  • Repo-resident slice authority ends at Slice 34.
  • New or replanned slices are authored and tracked in GitHub issues using .github/ISSUE_TEMPLATE/slice.yml.
  • New or replanned slices from Slice 35 onward are authoritative in GitHub issues created from .github/ISSUE_TEMPLATE/slice.yml.
  • Historical slice records are historical slice material unless they are explicitly listed above as live runtime contracts.
  • Version metadata in those records is a slice snapshot, not necessarily the current runtime version.
  • Any CLI examples, runner names, or controller names in those records are provenance only and must not be treated as live write-entrypoint authority.
  • When there is any mismatch, follow AGENTS.md plus contracts/governance/*.json for governance and the live runtime contracts above for runtime behavior.

Editing order​

  • Documentation change order:
    1. docs/Developer
    2. docs
  • If governance changes, update AGENTS.md routing first and then update the affected machine contracts in contracts/governance/.
  • Do not add governance contract mirror docs under docs/Developer/; governance meaning must live in AGENTS.md routing plus contracts/governance/*.json.
  • If runtime behavior changes, update the live runtime docs first.
  • Developer docs may then be updated as reference material, but they must not introduce parallel governance authority.
  • docs/Developer/Documentation-System.md
  • docs/Developer/Contributing.md
  • docs/Developer/Tests-And-Gates.md
  • docs/Developer/Governance-Reading-Guide.md
  • docs/README.md