One Graph, Every Surface

Day 1 named the third failure of flat curricula: no reuse. The letter ب ends up hand-built four times — an app lesson, a web lesson, a PDF worksheet, marketing copy — four copies of one idea to keep in sync. Days 2–6 built a graph and an engine that generate the app's lessons from concept nodes. Today closes the loop: the same nodes feed every other surface too, so a concept is authored once and rendered everywhere.

The enabling idea is a single read seam — one well-defined way for any surface to ask the graph "what concepts exist, and what's in them?" If every surface reads through that one seam, then truth lives in exactly one place (the graph) and each surface is only presentation. Change the concept once; every surface re-renders.

The diagram contrasts the two worlds: four hand-kept copies before, one source read through one seam after. The whole day is about that seam and what hangs off it.

The single read seam is a public catalog API — one HTTP endpoint that returns the graph's concept nodes as plain structured data. Any surface that is not the app engine (the marketing site, the printable generator, a future magazine) reads the curriculum through it:

# the ONE read seam every non-app surface uses
GET /app/v1/graph/nodes

The important word is catalog: the endpoint hands back what concepts exist and what each contains — ids, labels, domains, the assets from Day 2 — as data, not as a finished screen. An API (Application Programming Interface) is just a contract by which one program asks another for something; this one's contract is "give me the curriculum's nodes." Because it returns data, each caller is free to render those nodes however its medium demands.

Two properties make this seam load-bearing:

• Truth lives once. The endpoint reads straight from curriculum_concepts and friends. There is no second copy of the curriculum anywhere — a marketing page and the app are looking at the same nodes.
• Callers are presentation-only. The API decides nothing about layout. A PDF generator, a web page, and a marketing card each take the same node and present it in their own format. None of them owns any curriculum content.

To feel the leverage, follow a single concept node — say the letter ب — out through the seam and watch six different surfaces each render it their own way, all from that one node's data and assets.

The diagram is the one-line thesis of the whole system drawn out: one node at the top, the read seam, and six renderers underneath, each turning that identical node into its own artifact — a generated app byte, a web lesson, a printable "letter pack" worksheet, a curated book listing, a course page, a marketing tile. Six surfaces, one source, zero duplicated curriculum.

The table's last column is the whole point: nobody hand-authored the concept for any of these. It was authored once, in the graph, and every row is presentation over that single source.

The reason this design matters commercially, not just tidily, is what it does to the marginal cost of a surface — the extra work each additional surface or concept costs once the seam exists. In the hand-authored world that cost is "author the whole curriculum again." Here it collapses.

• A new concept costs ~0 per surface. Add a node to the graph and every surface that reads the seam picks it up — the app generates a byte, the web renders a page, the printable adds a worksheet — with no per-surface authoring.
• A new surface costs one renderer, once. Building, say, a kids' magazine means writing one thing: a renderer that reads /app/v1/graph/nodes and lays concepts out as magazine pages. After that, every existing and future concept flows into it for free.
• Sync is impossible to get wrong. There is only one copy of the curriculum, so surfaces cannot drift out of sync — fixing the concept once fixes it everywhere, because everywhere is reading the same node.

This is why the reuse argument from Day 1 is the quiet foundation of the business: the same authoring effort that produces the app also produces the website, the printables, the books, and the marketing — because all of them are just readers of one graph. Day 8 turns to how you ship an engine this central without breaking the app that 95,000+ families already rely on.

• The single read seam — the catalog API GET /app/v1/graph/nodes — lets every non-app surface read the curriculum as structured data, so truth lives in exactly one place and each surface is presentation-only.
• "Catalog" means the endpoint returns what concepts exist and what they contain (ids, labels, assets) as data, never a finished screen, so each caller renders it in its own medium.
• One concept node (e.g. the letter ب) fans out through the seam into six real surfaces — app byte, web lesson, printable PDF, book listing, course page, marketing card — all from the same node.
• This drives marginal cost to ~0: a new concept costs nothing per surface, and a new surface costs a single renderer written once, after which all concepts flow into it for free.
• Because there is only one copy of the curriculum, surfaces cannot drift out of sync — the reuse win Day 1 promised, and the quiet foundation under the whole product.

• [ ] I can explain what a "single read seam" is and why it makes truth live in one place.
• [ ] I can say what GET /app/v1/graph/nodes returns and why returning data (not a screen) matters.
• [ ] I can list the six surfaces one concept node renders into and note that none re-authored the content.
• [ ] I can define marginal cost and explain why a new concept and a new surface both become nearly free.
• [ ] I can explain why one-source reading makes surfaces impossible to leave out of sync.