Big projects — placing & handling multi-session programs¶
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
- 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).
- PreviousArt As Codec
- NextBiology
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 adomains/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 thindomains/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.