AI Orchestration

This organization is a federated network of self-growing knowledge bases — one repository per year (1776, 1777, 1778, the 2005–2011 lineage, …). Each one researches and writes its own encyclopedic content, one daily tick at a time, and publishes its own GitHub Pages site. This hub is the brain that drives them all. It holds every year’s concept, the growth policy, and the agent toolkit; it decides what grows, how, and when; and it presents the result.

This page documents the whole model, the growth process, and the strategy.

1 · The model — one hub, many living repos

Growth is centralized. The hub owns what grows, how, and when; the year repos own only their content and their published site. Nothing that grows a repo lives in the repo — it lives here, so there is a single source of truth and a single place to schedule, throttle, or evolve the whole network.

2 · The process — anatomy of a growth tick

A tick is one unit of growth. The hub runs the same pipeline for every repo: schedule → prepare → a three-model escalation → record → publish. The three AI passes share one working tree, so each builds on the last one’s drafts.

Step by step, the engine (grow-lineage.yml) does this for a single repo:

1. Schedule — orchestrate.yml runs on a daily cron, refreshes the lineage ledger, and dispatches one tick per repo.
2. Prepare — check out the year repo, then stage its seed (lineage/seeds/<year>.md → seed.md) and the canonical framework (lineage/framework/* → .github/) from the hub.
3. Generate (Tier 1 · Haiku) — pick 1–3 topics not yet covered, then research and write a first draft of each.
4. Expand (Tier 2 · Sonnet) — deepen every draft: detail, specific dates and figures, sourced facts, and cross-links between topics.
5. Enhance (Tier 3 · Opus) — polish prose and verify sources, rebuild the indices and timeline, regenerate the seed, and append a new Tick N entry to the seed’s Evolution Log.
6. Fallback — if the OAuth passes produced nothing (empty tree, or an authentication error), one complete pass runs on the API key instead.
7. Record — persist the updated seed Evolution Log back to the hub (the tick clock advances), then strip every hub-owned file from the checkout.
8. Publish — commit and push only the new content + telemetry to the year repo, which rebuilds its own Pages site.

3 · The three-model escalation

A single model writing a finished article in one shot is expensive and uneven. Instead, work climbs a ladder — each rung handing more capable (and more costly) models a better-formed draft, so the frontier model spends its budget on judgment, not first drafts. The model for each rung is read from lineage/policy.yml, so tiers can be retuned in one place.

4 · How the toolkit reaches each repo (adapter + staging)

A subtle but load-bearing design choice: the year repos carry only thin adapters in .claude/, while the canonical procedures live in the hub. This keeps every repo lean and keeps the hub the single source of truth for how growth works.

The effect: the hub is genuinely authoritative for every procedure, the year repos stay lean (adapters + content only), and a single edit in lineage/framework/ reaches every repo on its next tick. See ADR-0001 for the alternatives weighed and why this one was chosen.

5 · The strategy — perpetual, self-referential growth

• Grow forever. Every repo grows perpetually. Nothing is consolidated, archived, or deleted — the network only ever gets larger and deeper.
• The seed is the clock. Each year’s seed carries an Evolution Log (§8). Every published tick appends a Tick N entry; that log is how the system knows what a repo already covers and how many times it has grown.
• One scheduler, many repos. A single daily cron on the hub paces the whole org. There are no per-repo schedules to drift or collide, and growth can be paused org-wide simply by not dispatching.
• Escalate, don’t repeat. Cheap models do the broad first-draft work; the frontier model is reserved for the judgment-heavy finish.
• New eras spawn tangentially. As the frontier matures, the hub plants a fresh repo whose subject is chosen to be tangential to the newest one — so the lineage branches outward into related territory rather than looping. (Now live: 2012 was the first tangentially-spawned era, extending the modern arc one year past the 2005–2011 frontier — see ADR-0002.)
• Self-referential. Repos cross-link their own topics and, increasingly, each other — a knowledge base that builds on and refers back to itself.

6 · Guardrails & trust

• Authentication. Model passes use a Claude subscription token (CLAUDE_CODE_OAUTH_TOKEN), with an ANTHROPIC_API_KEY fallback; cross-repo pushes use a scoped LIFECYCLE_PAT. Secrets live in the org, never in code.
• Clean repos by construction. The strip step guarantees a year repo only ever receives content + telemetry — never the hub’s seed, framework, or scratch files.
• Deterministic when idle. If nothing changed, the ledger refresh makes no commit and a tick that writes no content publishes nothing.
• Observable. Every run uploads its agent telemetry, and the lineage dashboard shows each repo’s growth state and tick count.

Watching and improving itself. Growth is only half the system. A separate routine agent fleet reviews, fixes, aligns, learns from, and evolves the hub and framework — a self-monitoring, continuously improving loop. See Self-Improvement.

At a glance