Where integrate sits
By the time integrate runs, the hard part is over. Pippa has looked at the plate and answered in one JSON object, and the engine has validated that object against the rubric's Pydantic models. The worker records reading.recorded with the whole body, then hands the same parsed PlateReading to integrate (backend/reading.py, lines 383-389). A reply that fails validation never reaches this function, so the tree does not move.
That order is the first thing worth copying. Pippa's words are stored as a reading before any of them become structure. If integrate ever did something odd, the reading it worked from would still be there to inspect.
The model proposes, plain code decides
The tree is never handed to the model to edit. Pippa gets Dad's tree as data in her input (dads_tree, a compact catalog of principle and dish ids and names), and the rubric asks her to reuse those ids when something truly matches. She returns names, ids and descriptions. Everything that touches the record after that is ordinary deterministic Python. No model call happens inside integrate.
For each dish the reading names, the function does four things in a fixed order:
- Resolve the principles. At most two per dish (
dish.principles[:2]), which matches the rubric's "one root principle per dish, two at most". Each is looked up first by therefid Pippa gave, accepted only if that id really is a principle, then by name. A known principle is reused. An unknown one is proposed as a new class. A principle with neither a usable id nor a name is skipped. One whoserefresolves needs no name, because the id is accepted before the name is ever checked. - Resolve the dish. By
dish_ref(a dish or variant id), then by original name or Korean gloss. If nothing matches, a new dish is proposed with the resolved principles as its parents. - Parent it.
ensure_parentwrites aclass.parentedevent for each principle edge that does not exist yet, so a known dish can gain a parent it did not have. - Link the plate. One
class.linkedevent ties the encounter to the dish, stamped withsource: "reading", the reading's id and Pippa's confidence for that dish.
Then come the siblings, which get the next lesson to themselves.
Every write is an event
Notice what integrate never does: it never writes SQL. propose_class, ensure_parent and the link all go through sizzle.record, which appends an event to the journal and then applies it to the SQLite mirror. Track 5 is about that spine. For this track the consequence is enough. The tree is built from the class events in order: class.proposed, class.parented and class.linked from this function, class.revised when a proposal's words are refreshed or Dad edits a field, and class.adopted and class.renamed from Dad. Those alone are not enough, though. Which links count, and what evidence a class shows, depend on the plates and their readings: the current-links view keeps a reading's link only while that reading is the plate's current one, and evidence reads each plate's kind. So it is the whole journal, replayed in order, that rebuilds the tree exactly.
propose_class also refuses to invent structure. It drops any parent id the mirror does not know, trims every text field, and writes only the fields that carry a value. Every class integrate creates starts as status: "proposed", with an origin saying who started it: reading for a principle or dish named on the plate, sibling for an inferred sibling. The third origin, dad, never comes through here. A variant Dad derives is recorded by derive_variant with origin dad and status: "adopted" from its first event, because it is his from the start.
What one plate of gambas grows
Take the design's own generic example. A tapas-bar plate of gambas al ajillo arrives while the tree is still empty. The reading names one dish and one principle, roughly "move aroma into fat first, then cook in that fat". After integrate the journal holds:
| Event | What it adds |
|---|---|
class.proposed (principle) | The abstract class, with its summary, why, roles and method skeleton |
class.proposed (dish) | Gambas al ajillo with its Korean gloss, cuisine and role bindings, already parented to the principle |
class.linked | This plate tied to the dish, as the reading's claim |
class.proposed, once per sibling | Aglio e olio, scallion-oil fried rice and the rest, all inferred |
A second plate of the same dish adds one more class.linked. If the dish is still a proposal and Pippa described it differently this time, it also adds a class.revised. No second gambas class appears. Lesson 3 shows why.
A dish whose reading names no principle at all is still proposed, with no parents. The Tree page lists it under "Not yet under a principle" until a later reading gives it one.
The only way in is through a plate
Sizzle ships with no taxonomy. Invariant 6 of its architecture says the tree grows and is never imported. Every principle in the record exists because some plate made Pippa name it, and every one of them stays a proposal until Dad adopts it, renames it or ties a plate to it.
The oo-quest's Track 1 (The Straw) argues that understanding is inheritance: you grab something you already know and climb from there. integrate behaves the same way with each plate. It reaches for the classes already in the tree before it proposes a new one, and a new class arrives already hanging from whatever it could reuse.