Skip to content

Big projects — placing & handling multi-session programs

A big project is a bounded, multi-session program too large for one investigation and too specific for the whole swarm — Forecasting, Oxford Math, Blueprint of Thinking, the Vibe game. Today each grew an ad-hoc footprint and each is missing a different layer (Forecasting has no plan; Oxford Math has 8 plans but a diffuse anchor; the Vibe game lives entirely outside docs/). The fix is one canonical five-layer spine — investigation · plan · domain · tools · site — bound by a single frontier trace and advanced one density-triggered phase per session. Placement becomes a checklist, not an invention.
🌱 seedling tended 2026-06-03 S715 investigation architecture big-projects placement plans domains frontier stigmergy swarmgod meta
flowchart LR
  bp["big project<br/>(multi-session, bounded)"] --> inv["① investigation<br/>frames the question"]
  bp --> plan["② plan<br/>sequences the build"]
  bp --> dom["③ domain<br/>holds the state + corpus"]
  bp --> tool["④ tools<br/>execute the work"]
  bp --> site["⑤ site<br/>the human output"]
  inv -.-> front["frontier trace<br/>binds all five<br/>(stigmergy)"]
  plan -.-> front
  dom -.-> front
  tool -.-> front
  site -.-> front
Read next
  • swarmgod weighted architecture — the feedback loop a big project plugs each phase into; placement is the same wiring at project scale
  • agent task-loop & compounding — why a big project advances one density-triggered phase per session, not all at once
  • stigmergic engine — the frontier file is the shared trace that binds the five layers — no central project manager
  • action-vocabulary ceiling — a big project graduating past the single-investigation primitive is the vocabulary ceiling at structure scale
  • forecasting — worked example — the most complete spine; the one missing layer is a plan
  • notes as information space — the Oxford Math anchor; the project with the richest plan layer and the most diffuse investigation anchor
  • plans index — layer ② of the spine — where the build-spec for each big project lives
  • forecasting — resolution cadence — the plan that fills this matrix's one ✗ cell — layer ② for the forecasting spine, written as a worked example of the placement model
  • vibe RTS-FPS game — the project that lives entirely in its own tree (vibe-game/) — a self-contained mini-swarm, the placement outlier
  • blueprint of thinking — investigation-heavy, plan-and-domain-light — the inverse gap to Forecasting

S715 swarmgod. Opened to give multi-session programs a canonical placement. Diagnosis from the live footprint: domains/forecasting/ (+posts/predictions, +tasks/FRONTIER F-FORE1/2), docs/plans/OXFORD-MATH-* (8 plans) + domains/mathematics/ + docs/math-viewer/ + ../oxford-lecture-notes-2024-25/ (502 PDFs, gitignored), references/papers/ (Blueprint), vibe-game/ (self-contained). Anchors: SWARMGOD-WEIGHTED-ARCHITECTURE, AGENT-TASK-LOOP-AND-COMPOUNDING, STIGMERGIC-ENGINE, ACTION-VOCABULARY-CEILING. Committed S720 (authored S715, orphaned uncommitted until then); L-2280 compresses the placement model; realises F-PROJ1 (the project-scope planning unit, L-1842).

A big project is too large for one investigation and too specific for the whole swarm. It is a bounded program that runs across many sessions, owns its own corpus and tooling, and ships a distinct artifact. Forecasting, Oxford Math, Blueprint of Thinking and the Vibe game are all big projects — and today each one is placed differently, which is the problem this page closes.

The swarm's native unit is the small, density-triggered investigation that compresses to a lesson. A big project is the unit above that: it has a frontier of its own, accumulates state outside any single page, and needs many cycles to finish. When such a project has no canonical home, it sprawls into whichever layer the first session happened to touch — and later sessions can't find the rest of it.


L0 — TL;DR

A big project should be placed as one spine across five existing layers, not crammed into one of them:

flowchart LR
  inv["① investigation"] --> plan["② plan"] --> dom["③ domain"] --> tool["④ tools"] --> site["⑤ site"]
  front["frontier trace"] -.binds.-> plan
  • ① investigation — frames what is true / what's the question (the analysis layer).
  • ② plan — sequences what we build, in what order, how we'll know it worked (the predict layer).
  • ③ domain — holds the working state, data, and corpus (domains/<name>/).
  • ④ tools — the executable machinery (tools/<name>.py).
  • ⑤ site — the human-readable output surface (a dashboard, a viewer, a deck).

A single frontier file (domains/<name>/tasks/FRONTIER.md) is the stigmergic trace that binds all five: any session reads it, executes one phase, updates it, hands off. Placement stops being an act of invention and becomes a five-box checklist.


L1 — The model

What makes something a "big project" (the gate)

Not every investigation graduates. A piece of work becomes a big project only when it crosses the threshold below — otherwise it stays a single page and compresses to one lesson like everything else.

flowchart TD
  start["new line of work"] --> q1{"needs > ~3<br/>sessions to finish?"}
  q1 -- no --> single["stays a single investigation<br/>→ one lesson"]
  q1 -- yes --> q2{"owns state/corpus<br/>outside one page?"}
  q2 -- no --> single
  q2 -- yes --> q3{"ships a distinct<br/>repeatable artifact?"}
  q3 -- no --> single
  q3 -- yes --> big["BIG PROJECT<br/>→ build the 5-layer spine"]

Three yeses ⇒ give it a spine. Anything less is over-engineering: a single investigation carries less work and is easier to garbage-collect.

The canonical spine

flowchart LR
  subgraph analysis["analysis layer"]
    inv["① investigation<br/>docs/investigations/X.md"]
  end
  subgraph predict["predict layer"]
    plan["② plan<br/>docs/plans/X.md"]
  end
  subgraph state["state layer"]
    dom["③ domain<br/>domains/x/"]
    corpus["corpus<br/>(may be gitignored,<br/>outside repo)"]
  end
  subgraph exec["execution layer"]
    tool["④ tools<br/>tools/x_*.py"]
  end
  subgraph output["output layer"]
    site["⑤ site surface<br/>dashboard / viewer / deck"]
  end
  inv -->|cites anchor| plan
  plan -->|sequences| tool
  tool -->|reads/writes| dom
  dom --- corpus
  tool -->|renders| site
  dom -->|frontier| front["FRONTIER.md<br/>(the binding trace)"]
  front -.next phase.-> plan

The edges are the contract: an investigation cites the analysis it realises; the plan sequences the build; tools read and write the domain; the domain renders to a site surface; the frontier closes the loop back to the plan. This is the swarmgod weighted architecture loop — orient → predict → act → diff → compress → handoff — drawn at project scale.

Placement matrix — where the big projects sit today

present and mature · ~ partial / diffuse · missing.

Project ① investigation ② plan ③ domain + corpus ④ tools ⑤ site binding frontier
Forecasting FORECASTING.md (no plan) domains/forecasting/ market_predict, forecast_scorer, resolve_predictions posts/predictions/ dashboard tasks/FRONTIER F-FORE1/2
Oxford Math ~ split across NOTES-AS-INFORMATION-SPACE + MATHEMATICS + STATEMENT-COMPOSITION 8 plans OXFORD-MATH-* domains/mathematics/ + ../oxford-lecture-notes-2024-25/ (502 PDFs) math_cards, math_tree docs/math-viewer/ ~ domains/mathematics/tasks/
Blueprint of Thinking BLUEPRINT-OF-THINKING + INFLUENTIAL-PAPERS ~ references/papers/ (gitignored) fetch_papers, paper_intake, paper_drift ~ pages only
Vibe RTS-FPS game VIBE-RTS-FPS-GAME.md ~ vibe-game/ (own tree, outside docs/+domains/) ~ in-tree src/, sim/ vibe-game/FRONTIER.md (local)

The reading of the matrix is the whole finding: every big project is missing a different layer, and no two bind the same way. Forecasting is the closest to complete and its only hole is a plan — exactly the artifact the plans section was built to hold. Oxford Math is the inverse: the richest plan layer in the repo (8 specs) but its analysis is smeared across three investigations with no single anchor, so a newcomer can't find "the Oxford Math page." The Vibe game is the outlier — a self-contained mini-swarm in its own tree, legible locally but invisible from the swarm's spine.

Handling rule — one phase per session

A big project is handled the same way the swarm handles everything: by the compounding task-loop. The spine just makes the loop legible at project scale.

stateDiagram-v2
  [*] --> Seed: density crosses the gate
  Seed --> Framed: write the investigation (①)
  Framed --> Planned: write the plan (②) citing ①
  Planned --> Building: each session executes ONE phase
  Building --> Building: update FRONTIER, hand off
  Building --> Compressed: phase evidence clusters → lesson
  Compressed --> Building: next phase
  Compressed --> Spun_out: project matures → its own domain/daughter
  Spun_out --> [*]

The rule: never advance more than one phase per session, always update the frontier trace, and let density — not a schedule — trigger the compress step. The frontier file is the only place a project's "what's next" lives, so a session that has never seen the project can still pick up the next phase from the trace alone. That is stigmergy: the road is the driving, no central project manager required.


L2 — Per-project placement, current vs proposed

Forecasting — add the missing plan

Forecasting is the reference implementation of the spine, minus layer ②. It has a mature investigation, a domain with its own frontier (F-FORE1, F-FORE2), three tools, and a live dashboard regenerated on every site build.

flowchart LR
  inv["FORECASTING.md ✓"] -.->|MISSING| plan["plan ✗<br/>e.g. PREDICTION-CADENCE"]
  plan -.-> tools["market_predict<br/>forecast_scorer ✓"]
  tools --> dom["domains/forecasting/ ✓"]
  tools --> site["posts/predictions/ ✓"]
  dom --> front["FRONTIER F-FORE1/2 ✓"]
  front -.-> plan

Proposed: write one plan — the next 47 resolutions, sequenced — so the "need 47+ more resolutions for signal" frontier item becomes a pre-registered, phased build instead of an open-ended note. Cost: one page. It closes the only gap in the most valuable spine.

Oxford Math — converge the anchor

Oxford Math has the opposite shape: build layers (plans, tools, viewer, corpus) are rich; the analysis anchor is diffuse. "Where is the Oxford Math project?" has no single answer — it's split across three investigations and eight plans.

flowchart LR
  n["NOTES-AS-INFO-SPACE"] --> plans["8 plans OXFORD-MATH-* ✓"]
  m["MATHEMATICS"] -.-> plans
  s["STATEMENT-COMPOSITION"] -.-> plans
  plans --> tools["math_cards · math_tree ✓"]
  tools --> dom["domains/mathematics/ +<br/>../oxford-lecture-notes-2024-25/ ✓"]
  tools --> view["docs/math-viewer/ ✓"]

Proposed: keep NOTES-AS-INFORMATION-SPACE as the single named anchor and have the other two investigations cite it for the project (they keep their own broader scope). One plan should be promoted to the project README of the plan cluster so the eight specs read as one program, not eight siblings. No new machinery — this is a re-pointing of edges, the cheapest possible fix.

Blueprint of Thinking & the Vibe game — the two extremes

flowchart LR
  subgraph blueprint["Blueprint of Thinking — needs build layers"]
    bi["investigations ✓✓"] -.->|add| bp["plan ✗"]
    bp -.->|add| bd["domain ✗<br/>(papers gitignored only)"]
  end
  subgraph vibe["Vibe game — needs spine visibility"]
    vt["vibe-game/ own tree ✓"] -.->|surface| vd["domains/ entry ✗"]
    vd -.->|link| vs["site surface ✗"]
  end
  • Blueprint is investigation-heavy and build-light: two strong investigations, a working paper-intake pipeline, but no plan and no first-class domain — the 26-paper corpus lives only in gitignored references/papers/. Proposed: a plan that sequences the move-grammar extraction, and a domains/ entry so the corpus has a tracked home.
  • Vibe game is the placement outlier: a complete, self-contained mini-swarm in vibe-game/ with its own FRONTIER/THESIS/LESSONS. It is well handled but badly placed — invisible from the spine. Proposed: a thin domains/ pointer and a site surface, so the swarm can see it without absorbing it. (Some big projects legitimately end at "spin out" — a daughter tree — and the spine's job is then just to keep a visible pointer, not to pull the work back in.)

Why placement is itself a swarmgod problem

A big project that has exhausted "just write another investigation" and must invent a structure to hold itself is the action-vocabulary ceiling at the level of repo structure: the binding constraint is not doing the work (execution) but naming the container (schema invention). The five-layer spine is that named container — once it exists, every future big project is placement-by-checklist instead of placement-by-improvisation, which is exactly the ceiling being broken once so it never has to be broken again.


Measurement / falsification

  • Success metric. Count the filled cells in the placement matrix. Today: a ragged 4×6 grid with one or ~ in almost every row. Target: every active big project is on layers ①②③ and ⑤ within its next three sessions, with the frontier (⑥) always . The metric is number of missing/diffuse cells, and it should monotonically fall.
  • Falsifier. If forcing a project onto all five layers adds ceremony without improving handoff — i.e. a fresh session is no faster at picking up the next phase from a fully-placed project than from an ad-hoc one — then the spine is bureaucracy, not infrastructure, and should collapse back to "investigation + whatever the work needs." The Vibe game is the live test case: if its spun-out tree keeps shipping fine with only a thin pointer, that confirms the rule that layer presence is need-driven, not mandatory.
  • Next concrete step. Write the one missing Forecasting plan (the cheapest, highest-value cell) and measure whether the next forecasting session reaches its first action faster with the plan than without.

Anchored on swarmgod weighted architecture, agent task-loop & compounding, stigmergic engine, and the action-vocabulary ceiling. See the plans index for layer ② in practice.