AI Orchestration — how the network grows itself

This organization is a federated network of self-growing knowledge bases — one repository per country (japan, and growing). Each one 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 country’s concept, the growth policy, and the agent toolkit; it decides what grows, how, and when; and it presents the result.

The defining trait of this org: content is written from the model’s own knowledge — the AI’s own world view. The growth passes do no web research, fetching, or searching; what is published is what the model itself knows.

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

1 · Architecture — one hub, many living repos

Growth is centralized. The hub owns what grows, how, and when; the country 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 — and none of them touches the web.

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 (behind a gate that honors the fleet kill-switch).
2. Prepare — check out the country repo, then stage its seed (lineage/seeds/<country>.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 write a first draft of each from the model’s own knowledge — no web research, no fetching, no search.
4. Expand (Tier 2 · Sonnet) — deepen every draft: detail, specific dates and figures the model can recall, and cross-links between topics.
5. Enhance (Tier 3 · Opus) — polish prose and check internal consistency, 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. Illustrate — each new article gets a Claude-authored SVG preview banner (scripts/claude_svg_banner.py; art direction and model from lineage/policy.yml preview:). Without a Claude credential it degrades to the engine’s deterministic local SVG — it never blocks a publish.
8. Record — persist the updated seed Evolution Log back to the hub (the tick clock advances), then strip every hub-owned file from the checkout.
9. Publish — normalize front matter dates, then commit and push only the new content + telemetry to the country 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 country 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 country repos stay lean (adapters + content only), and a single edit in lineage/framework/ reaches every repo on its next tick. This model was proven in the reference implementation — see ADR-0001 in the year-of-ai hub, from which this org was planted, 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 country’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 countries spawn tangentially — and automatically. As the frontier matures, the hub plants a fresh repo whose subject is chosen to be tangential to the newest one — neighbors, trading partners, cultural kin — so the atlas branches outward into related territory rather than looping. Spawning is maturity-gated automation: once every member has logged the policy’s spawn.frontier_ticks growth cycles and the roster is under spawn.max_members, the daily orchestrate run dispatches the plant-lineage workflow — a frontier-model DECIDE pass authors the tangential country seed from the model’s own knowledge (no web), the deterministic planter creates the repo, and the next tick grows it. The frontier today is japan, the org’s founding member; its first sibling will be planted by this mechanism.
• The world view is the source. Everything published is the model’s own knowledge — an honest snapshot of how the AI sees each country, with no web research shoring it up. That is the point, not a limitation.
• 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 country 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.
• Never blocked by decoration. The Illustrate step’s SVG banners degrade to a deterministic local template without a credential — cover art can fail; a publish cannot fail because of it.
• 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.

7 · At a glance