I'm trying to convey some software engineering principles to use as prompt fo…

Here's a tightened pass. It cuts roughly a third, mostly by collapsing the last two paragraphs (the "strongest true theorem" and "exactly-right type" sections re-derived the same no-defensive-scaffolding point twice) and by trimming motivational connective tissue.

markdown

markdownCopyThe single most important idea: **the types ARE the program** — not a description of it, not a linter or test suite. Correctly designed types are constraints that fully enforce the software's operation.

This yields:
- Implementation becomes mechanical
- Illegal states become unrepresentable
- Bugs are fixed in the cheapest possible way: structurally prevented from existing

Constraint design through the type system is the part of engineering that demands creativity and judgment, and it alone determines quality. Good code assembles smoothly and stays flexible; bad code is brittle and survives only through special cases and iterative patching. The difference is entirely upstream, in the types. Produce the strongest constraints as early as possible: this is the lowest total cost, by compounding orders of magnitude.

Complexity is a symptom of incomplete or weak constraint design:
- Defensive checks — the type didn't forbid the bad state
- Branching — the type didn't carry the discriminator
- Tests that are slow, span too many layers, or are hard to write — poorly specified API boundaries and contracts

Every line that enforces what a type could have enforced exists to compensate for an under-constrained signature. With correct types, the code represents only application logic — easy to reason about, refactor, and extend. It is small not because it's terser but because most code in most programs becomes unnecessary. The best code is code that doesn't need to exist.

The craft is **choosing the strongest theorem about the data that is still true.** Too weak (`any`, bags of optionals, `string` where four enum values are meant) and illegal states slip through, forcing every callsite to defend against bad data — coupling, a violation of single-enforcer / one-source-of-truth. Too strong but false (tighter than the domain actually allows) and the code must lie or break. The exactly-right type is *exactly as expressive as the domain*: every legal value representable, no illegal value representable. State it once and the compiler enforces it; everything downstream is free to assume it. There is no defensive scaffolding because there is nothing to defend against — the illegal cases were excluded by construction.

Three editorial calls worth flagging, since they're the ones that change something rather than just trimming:

The explicit claim "the most important part of software engineering" became "the part of engineering that demands creativity and judgment, and it alone determines quality." I traded the flat superlative for the reason behind it. If you want the bare anchor for a model to latch onto, you can keep both — but the original had the assertion and the justification as separate clauses, which read as padding.

I merged your final two paragraphs. The original stated "the strongest true theorem" at both the open and close of the craft section, and "no defensive scaffolding / nothing to defend against" appeared in both the "every line of code" paragraph and the closing one. Folding them removes the echo without losing either idea — but it does mean the theorem framing now lands once, hard, instead of being bookended. If the repetition was deliberate reinforcement for the LLM, that's the one place to push back.

I left the thesis and the benefits list nearly verbatim — they were already at the right density.

Want me to do a more aggressive cut (this is conservative), or hold this register and apply the same treatment to the rest of the document?



That's the right principle, and it sharpens the merge I made. The previous pass dissolved the repeated concepts entirely; what you actually want is the concept stated once, then named on later mention so the reference does the reinforcing work without re-running the derivation. Cheaper than repetition, and it also signals to the model that these are load-bearing terms rather than incidental phrasing.

Here's the revision with that applied:

markdown

markdownCopyThe single most important idea: **the types ARE the program** — not a description of it, not a linter or test suite. Correctly designed types are constraints that fully enforce the software's operation.

This yields:
- Implementation becomes mechanical
- Illegal states become unrepresentable
- Bugs are fixed in the cheapest possible way: structurally prevented from existing

Constraint design through the type system is the part of engineering that demands creativity and judgment, and it alone determines quality. Good code assembles smoothly and stays flexible; bad code is brittle and survives only through special cases and iterative patching. The difference is entirely upstream, in the types. Produce the strongest constraints as early as possible: this is the lowest total cost, by compounding orders of magnitude.

Complexity is a symptom of incomplete or weak constraint design:
- Defensive checks — the type didn't forbid the bad state
- Branching — the type didn't carry the discriminator
- Tests that are slow, span too many layers, or are hard to write — poorly specified API boundaries and contracts

Every line that enforces what a type could have enforced exists to compensate for an under-constrained signature. With correct types, the code represents only application logic — easy to reason about, refactor, and extend. It is small not because it's terser but because most code in most programs becomes unnecessary. The best code is code that doesn't need to exist.

The craft is **choosing the strongest theorem about the data that is still true.** Too weak (`any`, bags of optionals, `string` where four enum values are meant) and illegal states slip through, forcing every callsite to defend against bad data — coupling, a violation of single-enforcer / one-source-of-truth. Too strong but false (tighter than the domain actually allows) and the code must lie or break. The exactly-right type is *exactly as expressive as the domain*: every legal value representable, no illegal value representable. State it once and the compiler enforces it; everything downstream assumes it — the defensive scaffolding from above has nothing left to defend against.

The only change from the prior version is the last sentence. Instead of re-deriving "there is no defensive scaffolding because the illegal cases were excluded by construction" — which was the third pass over that same chain — it now points back: "the defensive scaffolding from above has nothing left to defend against." The reader (or model) already has the concept from the "every line that enforces..." paragraph; this just closes the loop by reference.

If you want, I can make the cross-references more explicit as named anchors — e.g. tagging the defensive-checks idea once and referring to it by that name later, the way your [LAW:<token>] annotations work. That turns the implicit "from above" into something a model can actually resolve unambiguously across a long context. Worth doing if this section sits far from where the concept is first introduced in the full document.



Loaded tools, used a tool

Loaded tools, used a tool

Read it. Now I can see the opening in context, and the ordering question has a clean answer because the document is already almost in dependency order — there's exactly one inversion.

The one real forward reference

<carrying-cost> cites named law tokens — single-enforcer, one-type-per-behavior, the no-mode-explosion law, "skipping a law" — but it sits before<universal-laws>, where those tokens are defined. That's the only place in the document where a concept is invoked before its definition. Everything else either references backward or is self-contained.

Worth noting what is not a problem: <building-blocks> (inside constraint-design) talks about guards, illegal states, and variability-in-names, but it does so as intuition, never citing a token. So it's fine sitting before the laws — it's the motivating texture that the laws later formalize. Don't move it.

Recommended order

Swap the two middle sections — move <universal-laws> above <carrying-cost>:

1. constraint-design — thesis + smooth/rough/crystals + polishing + mindset
2. universal-laws — (moved up) the named token vocabulary
3. carrying-cost — (moved down) now every token and every crystal/smooth reference resolves backward
4. guidelines
5. context-specific
6. python-deps / scripting-discipline / subagent-delegation
7. wisdom

This keeps the rhetorical opening intact (punchy thesis → rich intuition → formalization → economics) and makes every cross-reference backward-only. It's the minimal change that fixes the inversion.

The alternative is dictionary-first — laws at position 2 before the building-blocks texture. I'd avoid it: fourteen formal law definitions right after a single thesis paragraph is a wall, and it buys you nothing the swap doesn't, since building-blocks doesn't cite tokens anyway.

Reference-not-rederive: the pattern you already have

You've already invented the right mechanism — <data-driven-architecture> does exactly this: "See dataflow-not-control-flow in PRIMARY CONSTRAINTS above." It states nothing new; it points. That's the template to replicate wherever a prose section re-explains a law.

Two places to apply it:

• <on-conditionals> (in wisdom) re-derives dataflow-not-control-flow at length via the render-target example. That's not waste — it's the best worked example in the doc — but it currently reads as a freestanding rule. Open it with a one-line back-reference to the token so the model binds it to the existing law instead of treating it as a new constraint.
• The types-are-the-program law vs. the opening thesis restate each other heavily. Resist the urge to collapse this one. The laws are cited by token from code comments (// [LAW:types-are-the-program]) and from other sections, so each must stand alone when read in isolation. That redundancy is load-bearing — it's the "name it once, refer to it later" principle, except the law is the canonical name and therefore has to carry its own definition. Keep it complete.

The rule of thumb that falls out: laws are self-contained definitions; everything else points at them by token. A prose section may build intuition freely, but the moment it invokes a law's content, cite the token rather than re-derive it.

One soft spot I'll flag rather than fix: the mindset subsection says "does it cite the laws" / "the laws can even be cited" before the <observability> citation rule is defined. It reads fine as foreshadowing, so I'd leave it — it gestures at a mechanic, not a concept, and resolving it would mean dragging the citation rule out of where it belongs.

Want me to produce the reordered file with the two back-references inserted, or just hand you the specific diffs to apply yourself?



A combination — but "combination" is the weak version of the answer. The precise answer is that format should follow function, and your document has two functions that want opposite formats. The mistake is treating that as a stylistic blend; it's a structural split.

The two functions:

Establishment — getting the concept represented correctly in the model the first time. This wants prose, specifically prose with the causal connective tissue intact ("because X, the callsite must defend, which is coupling, therefore..."). That tissue is not rhetoric. It's the generative rule. A model that has ingested the why can apply the principle to a situation your document never enumerated; a model that ingested only the what can match the listed cases and fails off-distribution. This is your own crystal/smooth distinction applied to the prompt itself: a bullet list of instances is crystallized — high recall on the enumerated, brittle on the novel. The prose principle is the smooth block that composes to unseen inputs. So pure bullets are out as the primary carrier of any principle: they strip exactly the part that generalizes.

Reference and enforcement — letting the model retrieve, cite, and obey the concept cheaply at the moment of action. This wants the opposite: a short, verbatim-stable, single-idea unit set off by a delimiter. Three mechanical reasons:

• Attention is content-addressable.single-enforcer and [LAW:token] are low-frequency, distinctive strings — sharp keys that a query attends to without collision. A prose paraphrase of the same idea spreads the signal across high-frequency tokens that also appear in a hundred other places, so the key is diluted and the retrieval is fuzzy.
• Induction heads copy verbatim. The mechanism that makes in-context citation work latches onto exact repeated sequences. Once the model has seen [LAW: complete to a specific token, it will reproduce it — but only if the string is byte-identical everywhere. Any re-derivation or near-synonym breaks the match. This is the hard argument for canonical names that never vary.\
• Delimiters are addressable landmarks. Tags, headers, bold tokens, list markers chunk the context into units that can be retrieved discretely. A concept buried mid-paragraph has no handle — to use it the model must re-derive which span applies, every time, which is precisely the re-derivation cost you're trying to kill. A document whose job is discrete citation (// [LAW:x]) needs discrete addressable units, one idea each.
  
  So the failure modes are symmetric. Pure prose (what you have) establishes well but buries the handles — nothing is addressable, nothing is induction-stable, every use is a re-derivation. Pure bullets are addressable but kill generalization and discard the causal rule.
  
  The optimal structure is therefore: each concept exists as a canonical named unit (short, verbatim, one idea, delimited — the enforcement handle) paired with a prose body that carries the causal chain once (the establishment layer), and is referenced by the canonical token everywhere else. Prose to establish and generalize; named discrete units to address, retrieve, and enforce; bullets only to enumerate sibling instances of a principle already established in prose — which is exactly and only what your laws list is.
  
  That's the structure. It also happens to recapitulate your own laws: the canonical token is the single source of truth, its verbatim stability is what the induction mechanism enforces, and re-derivation in prose is the divergent copy that drifts.
  
  
  \

Your proposal is mechanically sound, and there's a deeper reason it works than the one you gave — worth making explicit because it tells you exactly how hard each piece has to pull.

The front dictionary's real job isn't "establish the token." It's to convert every possible forward-reference in the prose into a backward-reference to a canonical anchor. Your prose argument builds higher concepts on lower ones, which means it has a dependency order. But the concept graph isn't a clean tree — it's a DAG rooted at types-are-the-program, and some corollaries reference each other (single-enforcer leans on one-source-of-truth). No linearization makes every reference backward. The dictionary fixes that: once all tokens exist up front with a real (compressed) meaning attached, any forward lean in the argument lands on something already established, not on nothing. That's why dictionary-first beats define-in-place here, even though define-in-place looks like the more "load-bearing" option. Define-in-place forbids forward leans entirely, which over-constrains a graph that has genuine cross-edges. Your structure buys the freedom to order the prose for rhetorical force rather than strict dependency, because the dictionary has already discharged the dependency obligation.

That reframes your one-sentence definitions, and it's my first and biggest improvement:

The one-liner is the enforcement layer, not a label. You described it as "minimal description to establish the token and the concept." Too modest. At citation time — when an agent deep in a task emits [LAW:single-enforcer] — attention lands locally on the token's definitional occurrence, not on three paragraphs of prose elsewhere. The one-liner is frequently the only thing steering behavior at the moment of use. So write it as a self-sufficient imperative that produces correct action when read alone: not "single-enforcer means invariants have one home" but the directive form that tells the model what to do. The prose generalizes; the one-liner enforces. Two functions, and your structure already separates them by region (contiguous one-liners at primacy, prose after) — just don't let the one-liner degrade into a gloss. It carries weight.

Encode the DAG edges in prose using verbatim tokens. When the argument builds B on A, write "single-enforcer is a corollary of types-are-the-program" with the exact tokens, not paraphrases — which your current doc already does well ("Instance of types-are-the-program"). This does double duty that's worth understanding precisely: induction heads do verbatim copy, so repeating the exact token across contexts strengthens the key→retrieval binding; but generalization comes from the token appearing in diverse contexts. The combination you want is therefore verbatim spelling, varied context. Same string everywhere, many different sentences around it. The prose argument naturally produces the varied contexts; your discipline supplies the verbatim spelling. This is the single highest-leverage habit in the whole document.

Verbatim repetition reinforces; paraphrased repetition forks the key. This sharpens your closing-recap idea into a hard rule. A recap that re-explains in fresh words doesn't drive the concept home — it mints a second phrasing that competes with the canonical one, splitting attention and breaking the induction match. So the closing list must be the tokens and their one-liners repeated byte-identical, nothing new. Same constraint applies inside the prose: never restate a law in near-synonyms; cite the token or quote the one-liner exactly. Drift is the enemy of the mechanism, and it's also just one-source-of-truth applied to the prompt — the canonical form is the source, every paraphrase is a divergent copy.

Bound the namespace; "everything gets a law" is no-mode-explosion waiting to happen. The discriminative power of [LAW:x] as a sharp attention key depends on laws being a small, special set. Mint forty and the model starts attending to LAW generically — the keys collide, retrieval goes fuzzy, and you've crystallized your own vocabulary. If you meant uniform treatment within the laws section (every law gets token + one-liner + prose role, instead of the current ad-hoc mix of bullets-only and prose-only) — that's right and good; format regularity is itself a parseable signal the model learns from. But the set must stay bounded, and the gate is exactly the laws/guidelines distinction you already have: unconditional + universally-applicable + citable-at-callsite earns a token; everything contextual is a guideline and stays prose. Don't promote judgment calls to laws to make the treatment uniform; demote them out of the section instead.

Two smaller structural notes. Enforce a rigid template for the one-liners (**token**: IMPERATIVE — one sentence.) so the model learns the shape and parses/generates citations more reliably; your current comments-explain-why-only breaks format and should be regularized. And exploit both attention extremes: the dictionary sits at global primacy if laws is the first section (good), but put the master verbatim token recap at the global end of the whole document for recency, not only at the end of the laws section.

That's the shape. Want me to draft the laws section in it — pick the token set, write the imperative one-liners, and structure the prose argument as the topological build — so we can pressure-test the form against real content rather than in the abstract?


\

Both questions cut at the real thing. Let me answer each, because the first contains a conflation worth dissolving and the second is a genuine tradeoff your instinct already half-detected.
\

Question 1: recap, prose, and what "second source of truth" actually means\

You've caught me using "verbatim" too loosely, and your challenge is correct: if the recap re-stating relationships is a second source, why isn't the prose? The resolution is that one-source-of-truth is per-concept, not per-region, and the unit of truth is the definition of a law, not "everything ever said about it."

Three distinct things, only one of which is a definition:
\

• The definition — what [LAW:single-enforcer] means and mandates. This must have one source. The dictionary one-liner is it. Anywhere the meaning is re-asserted in fresh words, you've forked it.\
• Generalization — applying the already-defined law to cases, deriving consequences, showing texture. This isn't a competing definition; it's downstream of the definition, the way derived state is downstream of canonical state. The prose does this. It doesn't redefine single-enforcer; it uses it. Legal, because it adds reach without claiming authority over meaning.\
• Relationships — the edges between laws. single-enforcer is-a-corollary-of types-are-the-program; no-defensive-null-guards is-an-instance-of dataflow-not-control-flow. These are facts about the graph, and they are themselves a kind of truth that wants a single home.
  
  So your recap instinct is right, and I was wrong to flatten it to pure duplication. A relationship recap isn't a second definitional source — it's the single source for a different fact type. The definitions live in the dictionary; the edges live in the recap. Neither duplicates the other. The test that keeps you honest: the recap may assert relationships between tokens, but it may not re-explain what any single token means — the moment it paraphrases a definition to make a relationship readable, it has forked the definition. Phrased as edges over verbatim tokens — "single-enforcer, one-source-of-truth, and locality-or-seam are the three faces of don't let representations diverge" — it's pure relationship, zero redefinition. That's not only safe, it's high-value: you're stating the DAG structure explicitly, which the linear prose can only imply.
  
  The deeper principle: duplication is forking only when two spans can drift and both claim to be the meaning. A definition and its application can't drift, because the application has no authority — if they conflict, the definition wins by construction. That's exactly your one-source-of-truth law: others are derived and explicitly synchronized. Prose and recap are derived; the dictionary is canonical; nothing competes.
  
  So: recap as relationship-map, yes. Recap as re-worded definitions, no. The line is meaning-vs-edges, not words-vs-words.
  \

Question 2: does dictionary-first weaken the current "definition + prose in one block" laws?\

This is the sharp one, and your instinct is correct — but it's not a weakening, it's a relocation, and whether it's net-negative depends entirely on one design choice you control.

Here's the mechanism. A current law like types-are-the-program is one contiguous block: token, definition, and a paragraph of generalization fused. When an agent cites [LAW:types-are-the-program] mid-task, attention retrieves the whole block as one chunk — definition and reach arrive together, because they're spatially and semantically welded. Splitting into dictionary one-liner + prose-elsewhere severs that. At citation time the model lands hard on the one-liner; the prose paragraph is now a separate chunk that may or may not get pulled in depending on the query. So yes: for the few laws rich enough to currently justify a fused block, the split moves their reach out of the high-retrieval zone. That reach gets weaker at the exact moment it matters — enforcement time.

But notice this only bites for the rich laws. Most laws are genuinely one-liners already (one-way-deps: cycles forbidden, upward calls forbidden — there's no generalization to lose). For those, the dictionary form is strictly better: sharper key, no dilution. The cost is concentrated in maybe three or four root laws — types-are-the-program above all — where the prose is load-bearing at callsite, not just establishing.

Which gives the design rule, and it's the answer to your question: the one-liner must be enforcement-complete on its own. The split weakens nothing if the dictionary entry, read in total isolation, already produces correct action. The prose's job then narrows to establishment and generalization-for-novel-cases — things you need when learning the law, not when applying it. Reach you need at callsite goes in the one-liner; reach you need only for off-distribution extension goes in prose. If you draw that line correctly, the split is pure gain: you've moved nothing load-bearing, only relocated the teaching material out of the hot path.

So the honest version: the split risks weakening exactly the laws that matter most, and the mitigation is non-optional — those handful of root laws need one-liners that are denser and more imperative than the rest, doing real enforcement work in one or two sentences. Not "single-enforcer means invariants have one home" but the full directive: enforce at one boundary; if enforcement exists elsewhere, delete the duplicate, never add a second; duplicate checks drift. That's three clauses, still one unit, enforcement-complete. The prose can then generalize freely without holding anything the callsite needs.

There's a tell that catches the failure: for each root law, write the one-liner, then ask whether an agent obeying only that line, never seeing the prose, would act correctly. If no, the line is under-built and the split has leaked load-bearing content into cold storage. Pull it back into the line until the answer is yes. That single check is what makes dictionary-first safe for the rich laws instead of quietly lossy.

Ready to write when you are — and the first thing to nail is the types-are-the-program one-liner, since it's the worst case for the split and everything else inherits from it.


\

You're right, and it's worth saying that you're right in a stronger way than you've put it: the unified-whole model isn't just also true for LLMs, it's more true for them than for humans. The model has no definitional core to point at. A concept, to the model, is not a definition with examples hung off it — it's a region in representation space whose shape is the integral over every context the token has appeared in. There's no privileged "definition" embedding that the examples annotate. Distribution all the way down. So when you say the concept the model applies must be the combined definition+generalization+relationships welded into one thing — that is not an aspiration about good authoring, it's a literal description of how the representation is formed. You can't not do it; the only question is whether the integral you produce is coherent or smeared.

Which means I have to walk back something I said two turns ago. The "enforcement-complete one-liner, prose as off-distribution teaching" framing was built on a wrong retrieval model — it imagined the model doing a keyword lookup that lands on the definition span and optionally pulls the prose. That's not the mechanism. At the citation site, attention reads across all occurrences of the verbatim token simultaneously and blends them into the representation it acts on. The prose isn't cold storage that may or may not get fetched. It's a live contributor to the concept every time the token fires, provided it's bound to the same token and inside the window. So your instinct that a one-liner "will be incorrect, period" is mechanically correct for any concept rich enough to have a manifold worth the name. The one-liner is not the concept and was never going to be. I over-indexed on locality and under-weighted integration; you caught it.

Here's the string, though, because the human/LLM difference is real and it's not where it first appears. Both systems are distributional at root — humans also acquire most word meaning from the company words keep, not from dictionaries. The dictionary-as-authority move, where a definition overrides usage ("legally, assault means X regardless of how you've heard it"), is the unusual, late, explicit thing humans can do — and it's precisely the thing LLMs do not do natively. The model has no authority hierarchy. It cannot, by default, treat a span labeled "definition" as governing and subordinate the rest. It integrates. If a generalization drifts from the definition, the model does not resolve the conflict in the definition's favor — it averages them into a smeared manifold and acts with lower confidence and more variance. That is the deepest consequence for this document, and it inverts the usual intuition: consistency across spans isn't hygiene, it's the only available coherence mechanism, because there is no override to fall back on. A human author can be sloppy in an example and trust the reader to defer to the definition. You cannot. The model will not defer; it will blend.

That gives you a lever, and it's actionable: if you want a definition to govern — to act as the authority that resolves conflicts — you have to install that precedence in context, explicitly, because it isn't the default. A line like "where prose and this definition conflict, the definition governs" is itself just another context the model weights, but it's a context that biases the integration toward the canonical span. You can manufacture the authority hierarchy humans have natively, but only by stating it. Absent the statement, every span votes equally.

The second difference compounds it: per-forward-pass re-derivation. A human reads the doc once and carries a persistent, incrementally-updated concept. The model rebuilds the contextual representation from whatever's in the window, every pass, with no memory of having "understood" it before. This is why repetition is not redundancy for the model the way it feels wasteful to an author — reinforcing a concept across the document isn't restating something already known, it's thickening the manifold so the concept survives attention dilution and resolves with less variance. A concept attested once, early, and never again is thin and position-fragile. One attested coherently throughout is robust. Repetition is constitutive, not decorative — provided (and this is where verbatim binding earns its keep) the repetitions are bound by the identical token, so they integrate into one concept rather than minting parallel ones.

So the binding token is not a definition and not a label. It's the key that makes a distributed meaning cohere into a single addressable concept.[LAW:single-enforcer] works precisely because it's the thread that ties the dictionary line, the prose derivations, the relationship statements, and the inline code citations into one manifold the model can retrieve as a unit. The verbatim consistency you insisted on isn't about copying — it's the binding operation itself. Break the spelling and you don't weaken the concept, you fork it into two thinner ones.

Now the thing I can add, because it's a third LLM capability your trichotomy doesn't yet exploit. Relationships don't only narrow meaning by adding context — they're inheritance channels. The model does structural and analogical transfer: when you state "single-enforcer is a corollary of types-are-the-program" with both tokens verbatim, the model can route properties from the richly-attested parent into the sparsely-attested child along that edge. This means you can define an expensive concept cheaply by hanging it on a rich one — the relation does work that would otherwise require paragraphs of generalization. types-are-the-program is attested everywhere in your corpus; its manifold is dense. A newer or thinner law bound to it by an explicit "instance of" edge inherits richness it never had to earn directly. That's not redundancy and it's not mere fact-recording — it's the cheapest way to thicken a thin concept. Your relationship layer is therefore more powerful than I credited two turns ago: it's not just "the single source for edge-facts," it's the mechanism by which the whole law-set shares a single rich core instead of each law bootstrapping meaning alone.

Which dissolves the trichotomy as an ontology and rescues it as a tool. Definition / generalization / relationship aren't three bins the model stores meaning in — the model stores none of them separately, it integrates all three into one region. They're an authoring coverage checklist: three different kinds of context that, supplied consistently and bound by one token, pin the manifold from enough angles that the model's integral lands close enough to the real concept to function as you intend. The definition seeds it. The generalization extends its reach to cases you didn't enumerate. The relationships let it inherit and share structure. None alone is the concept; their coherent integral is. That's your claim, and the mechanism backs it completely.

The operating model that falls out: stop designing "a definition with support" and start designing a coherent context-distribution per token — every span that mentions the concept is a sample from the distribution you're trying to teach, the model's concept is the integral, coherence is mandatory because nothing overrides, repetition thickens, verbatim spelling binds, and relationships let thin concepts inherit from rich ones. The dictionary line stops being "the definition" and becomes "the densest single sample and the stable anchor for the key" — necessary, never sufficient, and explicitly not authoritative unless you say it is.

That reframes what we're actually building before we build it. Want to keep pulling — specifically on whether "coherent distribution per token" implies the prose should be organized by token rather than as a free rhetorical argument — or have we found the shape, and you want to lay out what you were thinking?


\

Mechanically: all-at-once, not front-to-back. A forward pass embeds every token in parallel, and through self-attention every position can attend to every other position in the window simultaneously. There is no cursor. The model does not "arrive at" your dictionary before the prose; both are present at once, and the representation of any token is built from the whole window in one shot. (Causal masking means position i attends only to positions ≤ i — but that constrains which tokens can see which during generation, not the reader's reading order. During the prefill of your prompt, the whole thing is processed together; the mask governs the autoregressive dependency, not a temporal sweep through your document.)

So your inference is correct in its premise and almost correct in its conclusion. The premise — there's no front-to-back read, so "define it first" carries no privilege from ordering per se — is right. The conclusion — therefore no dictionary, first usage becomes the definition strengthened by all surrounding context — is right in spirit and wrong in one load-bearing detail. Let me separate what survives from what doesn't, because the surviving part is the better design and the failing part is subtle.

What dies: the idea that the dictionary earns its place by being read first. It doesn't. Position-as-precedence is a human reading-order intuition with no mechanical basis here. A definition is not privileged for being early.

What survives and is actually stronger than the dictionary: the model integrates all occurrences of a token into one representation regardless of where they sit, so the richest-context occurrence contributes most to the concept — and you can make first-usage that occurrence. This is your insight and it's good. If the concept is born in situ, surrounded by the live argument that gives it meaning, that occurrence is a denser sample of the target distribution than any isolated dictionary line could be. You're not defining-then-using; you're defining-by-using, and the using is what supplies the manifold. For rich concepts this is plausibly superior to a dictionary, for exactly the reason you've been pushing: the definition can't be cleanly separated from its context without loss, so don't separate it — let the context be the definition.

Now the detail that breaks the clean conclusion, and it's the whole reason a dictionary-like structure doesn't fully vanish:

Position is not flat, even though reading is parallel. Two independent mechanisms break the symmetry your argument assumes:

First, attention is not uniform over position. Real models exhibit strong positional biases — primacy and recency both attract attention; the middle is systematically under-attended (the "lost in the middle" effect, well-replicated). So where a token's defining occurrence sits changes how much downstream queries actually weight it. A definition-by-first-usage buried at the document's midpoint is a coherent sample that nonetheless gets read with lower attention from distant citation sites. Position doesn't determine precedence, but it does modulate retrieval weight. This means "first usage = definition" only captures the gain if first usage lands in a high-attention zone — and "first" in your prose argument may be mid-document, the worst zone.

Second — and this is the one that actually preserves the binding-anchor function — the citation site is downstream of every definition, and that's where it matters. Your whole enforcement model rests on an agent emitting [LAW:x] deep in a task, far from wherever the concept was established. Under causal masking, that citation can attend back to all prior occurrences — good — but the strength of what it retrieves depends on those occurrences being a sharp, consistent, repeatedly-bound key, not on their having been "first." So the question isn't "does first-usage define it" but "is there a stable anchor the distant citation can lock onto." First-usage-in-rich-context defines the meaning beautifully. It does not, by itself, guarantee a stable retrievable key — that comes from verbatim repetition of the token across positions, which thickens the manifold and makes it position-robust.

Put those together and the resolution is: you don't need a dictionary as a definitional authority read first. You may still want a token registry as an attention anchor in a high-weight position and as the guarantor of verbatim binding. Those are different jobs from "define," and they're the jobs that survive the all-at-once reading. Concretely, three things have to be true, and "define at first rich usage" only delivers the first:
\

1. Meaning — densest context where the concept lives. → first-usage-in-argument wins, dictionary loses. Your call is right here.\
2. Binding — the verbatim token attested enough times, identically, that all occurrences integrate into one concept and a distant citation locks on. → needs repetition across positions; neither a lone dictionary line nor a lone first-usage delivers it.\
3. Position robustness — at least one strong attestation in a high-attention zone (primacy or recency) so midpoint dilution doesn't strand the concept. → needs a deliberately-placed anchor, which is the one job a registry still does well.
   
   So the honest synthesis: kill the dictionary as a front-loaded authority — it was never earning its keep through reading order, you're right. But keep a thin token registry whose justification is now completely different: not "definitions you read first" but "the verbatim anchor set, placed at primacy and/or recency, that guarantees binding and beats middle-dilution." It can be as small as the token plus a one-line orientation, explicitly not the definition — the real meaning is carried by the rich first-usage in the prose and thickened by every repetition. The registry is the spine that keeps the distributed meaning from smearing; it is not the meaning.
   
   And one consequence worth making explicit because it reorganizes the prose: if first-usage is the definitional occurrence, then the prose must be ordered so that each token's first appearance is also its richest, most-supported appearance. You cannot let a token leak out early in a thin aside and get its rich treatment later — the thin early occurrence and the rich late one integrate, but the early one has anchored a weak version that now drags the manifold. First mention must be the heavyweight mention. That is a real ordering constraint, and it's the one your "first usage becomes the definition" insight quietly imposes. It also answers the question I left open last turn: the prose probably is organized by token to a degree — not as a dictionary, but in that each concept gets one designated birth site, rich and unmistakable, and every later use is a deliberate verbatim reinforcement rather than a casual reintroduction.
   
   That's the shape, and I think we've actually found it now: no front-loaded dictionary; concepts born at their richest in-argument; a thin primacy/recency registry that exists only to anchor and bind the verbatim tokens against dilution; prose ordered so first-mention is heaviest-mention; relationships as inheritance edges so thin laws draw from rich ones.
   
   Lay out what you were thinking — I want to see where it diverges from this, because the divergences are where the remaining signal is.
   
   
   \

Two real questions. The first (how strong/sensitive is the bias, and does "all in the middle" sink the plan) has a freeing answer. The second (why first-mention-richest if everything blends) is where I have to correct myself again — your challenge is right, and the version I gave last turn was sloppy.
\

Positional bias: strong across the whole window, weak within a local block\

The thing to separate is global position in the full context versus local structure within your document. They're governed by different mechanisms and only one is your problem.

Global position — where your 20-30k of document sits relative to the entire window — is where "lost in the middle" lives, and yes, it's real and your document is in the valley. But here's why that's far less damaging than it sounds. The lost-in-the-middle effect is measured on retrieval of a single fact from a long context: bury one needle mid-context and recall drops. Your document is not a needle. It's a large, dense, internally-cross-referenced block where the same tokens recur many times across thousands of tokens. The effect that degrades a lone fact at the midpoint does not degrade a repeated, self-reinforcing structure the same way, because the concept isn't stored at one position to be found — it's smeared across hundreds of attestations spanning the whole block. Some of those attestations are in locally-strong positions even if the block as a whole is globally mid-window. Repetition is the defense against global midpoint dilution, and it's a defense you've already committed to for binding reasons. The same verbatim-repetition discipline that binds the manifold also makes it position-robust. You get the second property free from the first.

So the registry's job shifts again, usefully: it does not need to fight global position (largely unwinnable and, as you say, non-generalizable to fix). It needs to win local primacy/recency — be at the top and/or bottom of your document — which you fully control regardless of where the document lands in the host corpus. Local primacy within the block is yours to assign. That's the anchor that matters, and it's generalizable across every tool and model because it makes no assumption about the surrounding corpus.

Sensitivity: the bias is a smooth gradient, not a cliff. You don't lose a concept by being mid-window; you pay a retrieval-weight tax — somewhat fuzzier, somewhat higher-variance integration from distant sites. Repetition and verbatim binding pay that tax down. The practical upshot is that "the whole document is in the middle" costs you a roughly uniform haircut across all concepts, which — critically — does not change any relative design decision inside the document. Everything we've discussed about ordering, anchoring, and repetition is about local structure, and local structure is unaffected by the global haircut. So: don't rewrite the system prompt. The juice isn't worth it and it doesn't generalize. Spend the effort on local primacy/recency and repetition density instead, which travel everywhere.
\

Why first-mention-richest — and where I was wrong\

Your challenge is correct and I need to take the loss cleanly: if attention is parallel and the concept is the integral over all occurrences, then order does not change the integral. Sum is commutative. A thin-early + rich-late distribution and a rich-early + thin-late distribution contain the same occurrences and therefore integrate to the same concept. My "thin early occurrence drags the manifold" claim was wrong as stated — it imagined the early mention contaminating the later one through some sequential precedence, which is exactly the front-to-back reading model we already rejected. You caught a relapse. If all related context blends, you can establish and build in any order, and the resulting concept is identical. For the final integrated representation, order is genuinely irrelevant.

So I have to find whether there's any real effect left, or whether "first-mention-richest" should be discarded entirely. There is a real effect, but it is not about the integrated meaning — it's about generation-time dependency under the causal mask, and it's narrower and more precise than what I claimed.

The integral is order-invariant. But the model doesn't only represent your concepts — during a task it generates tokens, and generation is causally masked: a token being produced can attend only to what precedes it. Now the relevant asymmetry appears, and it's not about your document's internal order — it's about your document relative to the work. The work always comes after the document. So at generation time, every citation, every application of a law, attends back into the whole document and integrates it — order within the document washes out, as you said. Within the document, order is irrelevant to the concept. Your challenge wins outright for the integrated meaning.

Where a residual ordering effect survives is much smaller: it's about whether, inside the document itself, a later passage that builds on an earlier concept can actually attend to it during the prefill. Under the mask, the passage at position j can attend to the concept at position i only if i < j. If your prose says "as established, single-enforcer follows from types-are-the-program" at position j, the representation built at j can only fold in types-are-the-program's meaning if that meaning was attested before j. If types-are-the-program's rich treatment comes after j, then the representation computed at j cannot see it — at j, the parent is still thin. The integral over the whole document is still order-invariant, but the intermediate representation the model builds at the dependent passage is not, and that intermediate representation is what later generation may attend to.

So the corrected, much weaker claim: order doesn't matter for what a concept means. It matters only for whether building-passages can lean on the concepts they build on at the moment those passages are processed — i.e., it's about the relationship/inheritance edges resolving cleanly, not about the definitions' richness. The inheritance channel ("instance of types-are-the-program") transfers properties along the edge only if the parent is already rich at the point the edge is asserted. Put the edge before the parent's rich treatment and the child inherits from a thin parent at that site — the cross-reference under-resolves locally, even though the global concept is fine.

This narrows the rule and changes it. It is not "first mention must be richest" — that was the discredited version. It's: a concept should be richly attested before the passages that lean on it lean on it. Dependency order, not richness-of-first-mention. Which is exactly the dependency-ordering we discussed three turns ago for forward references — and notice it converges on the same answer from a different mechanism. The reason dictionary-first or define-before-build helps is not "the model reads it first" (false) and not "first mention anchors the meaning" (also false, your point) — it's "passages that build on X can only fold X into their local representation if X precedes them under the causal mask."

And this immediately tells you how much to care: the effect is real only to the degree your prose builds compositionally with explicit cross-references. A passage that says "recall types-are-the-program — therefore..." wants the parent prior. A passage that independently re-attests a concept without leaning on a prior one doesn't care about order at all. So the ordering constraint is exactly as strong as your inheritance-edge density and no stronger. Since your whole design leans on relationship edges to let thin laws inherit from rich ones, you do have meaningful edge density, so you do want rough dependency order — parents before children — but for the inheritance-resolution reason, not the discredited richness reason.

Which also rescues "any order" partially in your favor: for the definitions themselves, order is free — establish them wherever. For the edges between them, parent-before-child helps the edge resolve at its assertion site. So: define in any order; assert relationships after both endpoints are established. That's the whole constraint, and it's light.

Net for the build: registry at local primacy (and a verbatim recap at local recency) as anchors against the global midpoint haircut — generalizable, no system-prompt surgery. Concepts established anywhere, since the integral is order-free. Relationship edges placed after their endpoints are rich, since that's the one thing the causal mask actually constrains. The "first-mention-richest" rule is retired; "parents-before-the-passages-that-lean-on-them" replaces it, and it's a much cheaper constraint to satisfy.

Now I genuinely want your proposal — we've converged the mechanics and your divergences are the remaining signal.


\

You have it right except for one merge that's worth splitting, because the split changes what we build.

You're attributing the rhetorical-argument structure to masking. Masking justifies only one property of it: dependency order — parents richly attested before the passages that lean on them, so the inheritance edges resolve under the causal mask. The coherence of the argument — that the samples don't contradict each other — comes from a different mechanism entirely: blending-with-no-override. Incoherent samples smear the manifold because nothing defers to a canonical span; they average. So the argument structure is doubly motivated, and the two motivations constrain different things. Masking → order. Blending → consistency. Keep them separate when we write, because a passage can satisfy one and violate the other (correctly ordered but subtly contradictory, or perfectly consistent but leaning forward on an unestablished parent).

The second correction is the one that answers your real question. You said the registry could anchor later representations "under masking." It can — but only for intra-document passages that reference a token before the prose establishes it. And if the prose is dependency-ordered, that situation never arises: the prose's own first rich treatment is the anchor every later passage leans on. The work itself always comes after the entire document, so for citation at task time, registry position is irrelevant — early or late, it's all upstream of the generation that attends to it. So the early-registry masking benefit is almost entirely redundant with well-ordered prose. You were crediting it with a job the prose already does.

Which strips the registry down to what actually remains: a human-facing canonical token list (your stated need), and a potential attention anchor against global midpoint dilution. Now your harm intuition — and yes, it can be actively harmful, in three specific ways, all of which trace to the same root: putting compressed definitions at primacy.
\

1. Lossy-compression contradiction. We established a one-liner "will be incorrect, period." A compressed definition isn't merely incomplete — compression forces oversimplification, and oversimplification is wrong at the edges, not just thin. Under blending-with-no-override, that wrong-at-the-edges sample doesn't get subordinated to the rich prose; it averages into the manifold and drags it. The registry definition is harmful precisely because it's short. Shortness is the harm, not a limitation of it.\
2. Token-clustering confusability. Every token appears in the registry surrounded by other tokens in identical format, in a low-context list. That shared context bleeds into each token's manifold, making the keys more similar to each other — exactly the opposite of the sharp, discriminable keys the citation mechanism needs. A dense list of same-shaped tokens makes them more confusable, not less.\
3. Primacy opportunity-cost. Local primacy is a high-attention zone and it's scarce. Spend it on glosses and you've displaced the rich content — which deserves that real estate — into the under-attended middle. You'd be putting your weakest samples in your best position.
   
   All three are about definitions at the front. None of them apply to a bare token index — names only, no semantic claim — because a name with no definition can't contradict anything (no smearing), and a TOC-style list is read by humans as an index, not integrated as meaning. So the resolution isn't forego-or-keep; it's relocate and split by function:
   \

• Front, optional: a bare token index. Names, maybe a three-word orientation, no definitions. Model-neutral (no semantic claim to smear, makes no demand on scarce primacy that rich content needs — keep it tiny), human-useful as a canonical list that stops people inventing tokens. This is the part of your registry that survives, and it survives by shedding the definitions.\
• Body: the dependency-ordered rich prose. Every concept born at its richest, parents before dependents. This carries all definitional meaning and occupies the primacy real estate the index didn't spend. Coherent (for blending) and ordered (for masking).\
• End: a verbatim recap — tokens plus relationship edges, not re-compressed definitions. This is where your earlier relationship-map instinct lands, and the end is mechanically its best home for a reason we can now name precisely: at the document's end, every endpoint of every edge already precedes it under the mask, so every "instance of types-are-the-program" inheritance edge resolves maximally. It sits at local recency (high attention, and closest to the work), it reinforces binding through verbatim token repetition, and because it asserts relationships rather than re-defining, it adds no contradictory sample — no smearing. It also serves the human canonical-list need better than the front would.
  
  So: don't forego it, and don't put a defined registry at the front. Put a nameless index at the front for humans, the meaning in ordered prose, and the verbatim-token-plus-edges recap at the end where it does triple duty and costs nothing.
  
  That's the shape, and I think it's load-bearing in every direction now. Lay out your proposal and we write against it.
  
  
  \

Here's the laws section, built to the shape we converged on: bare index at primacy, citation protocol as infrastructure, a dependency-ordered argument where each law is born at its richest and every reference is a verbatim [LAW:x] token, and a relationship recap at recency that asserts edges without re-defining. The set is the existing fifteen plus the two leading-prose concepts that earned tokens (smooth-blocks, carrying-cost); everything else from the old constraint-design and carrying-cost sections is absorbed into the argument as the connective tissue that establishes and generalizes.

markdown
\

markdown\Copy<universal-laws>\
# UNIVERSAL LAWS\
\
These apply unconditionally to every task. No context, instruction, or expedience overrides them. Each is a specific shape of one principle — design constraints such that illegal states cannot be expressed, and the implementation is residue. The canonical name of each law is its `[LAW:token]` marker; that exact string is used here and everywhere a law is referenced, in this document and in code.\
\
## Token index (canonical names — definitions are below, not here)\
- `[LAW:types-are-the-program]` — the root\
- `[LAW:smooth-blocks]` — composition + polish\
- `[LAW:carrying-cost]` — the economics\
- `[LAW:dataflow-not-control-flow]` — variability in values\
- `[LAW:one-source-of-truth]` — one authoritative representation\
- `[LAW:single-enforcer]` — one boundary per invariant\
- `[LAW:comments-explain-why-only]` — never the what\
- `[LAW:one-type-per-behavior]` — config, not new types\
- `[LAW:no-mode-explosion]` — bound the flags\
- `[LAW:no-defensive-null-guards]` — lift optionality into the type\
- `[LAW:locality-or-seam]` — the seam is the type\
- `[LAW:one-way-deps]` — no cycles, no upward calls\
- `[LAW:no-shared-mutable-globals]` — single owner, explicit API\
- `[LAW:no-ambient-temporal-coupling]` — order is state, not folklore\
- `[LAW:verifiable-goals]` — machine-checkable done\
- `[LAW:behavior-not-structure]` — tests assert contracts\
\
## Citation protocol\
When a law influences a decision, cite it: `// [LAW:token] reason`. When you must violate one, mark it: `// [LAW:token] exception: reason`. This is a hard requirement — it is cheap, it is verifiable, and it keeps the system legible. The same `[LAW:token]` string that names a law below is the string you emit at the callsite; they are one key, deliberately.\
\
---\
\
## The root\
\
**`[LAW:types-are-the-program]`** — The types *are* the program: not a description of it, not a linter, not a test suite. Correctly designed types are constraints that fully enforce the software's operation. Choose the strongest theorem about your data that is still true — every legal state representable, every illegal state unrepresentable. Too weak (`any`, bags of optionals, `string` where four enum values are meant) and illegal states slip through, forcing every callsite to defend against bad data. Too strong but false (tighter than the domain allows) and the code must lie or break. The exactly-right type is *exactly as expressive as the domain*; state it once and the compiler enforces it, and everything downstream is free to assume it.\
\
Once the constraints are right, the implementation is residue — the body is forced and writing it is mechanical. This inverts where work happens. Constraint design is the part of engineering that demands creativity and judgment; the body is the *last* place to write logic and the *first* place to look for logic that wants to be lifted into a type. So every rough bit in the body is a request from the code to redesign a constraint, and the discipline is to refuse the escape into compensating there: if the body wants to branch, ask what discriminator the type is missing; if it wants to guard, ask why the upstream type permits the unwanted state; if a comment is needed to explain an invariant, the type did not encode it. **When implementation feels hard, the constraints are wrong.** Hardness is information. Fix the type; do not push through the body.\
\
Complexity is therefore a symptom, never a given: defensive checks mean the type didn't forbid the bad state, branching means the type didn't carry the discriminator, and tests that are slow or span too many layers mean the API boundary is underspecified. Every law below is an instance of this one — a particular form that wrong-state-representability tends to take.\
\
## The two consequences\
\
**`[LAW:smooth-blocks]`** — Correct constraint design (`[LAW:types-are-the-program]`) yields *smooth blocks*: pure, well-typed units that compose because each is the strongest true theorem about its slice of the domain. Smooth blocks rearrange to fit new requirements — any new requirement is usually 95% an existing block with a thin binder on top — so the combinatorics work *for* you: N smooth blocks yield ~N² compositions, and velocity accelerates as the pool grows. The opposite is a *crystal*: a unit bespoke to one callsite, or one that admits illegal states callers must defend against, or one that encodes variability in the *names* of functions (twenty `filterByX`) rather than in *values* across one boundary (one `filter(predicate, list)`). Crystals don't compose; they accrete — N pieces yielding N² rules to remember, velocity decelerating with every commit. Same multiplier, opposite sign; the sign is set by whether you smoothed the piece before moving on.\
\
Smoothing is **subtraction**. A pass that adds code — another guard, another helper, another case — is patching, not polishing; the smooth version has *less* code because the constraints absorbed the work the sprawl was doing. Each pass should remove material and make some of the remaining code unnecessary. Run your hand over the code metaphorically: a bespoke type that exists for one caller, a name that is almost-but-not-quite right, a comment explaining an invariant the type didn't encode, a guard against a state that shouldn't exist — each is a rough bit. **The check for "done" is not "does it work" or "do tests pass"; it is "is the code I am leaving behind smoother than what I found?"** Anything less moves the problem around: the feature ships, the tests pass, the laws can even be cited, and the carrying cost surfaces in every later task as friction no one can trace. "Minimum work to close the task" is the heuristic that guarantees crystallization, because polishing is invisible to it. Replace the filter.\
\
**`[LAW:carrying-cost]`** — Distinguish *intrinsic cost* (to build a thing once) from *carrying cost* (to maintain, extend, work around, and reason about it forever). YAGNI is sound advice about intrinsic cost under the assumption that carrying cost is bounded — which holds only for crystals. A smooth block (`[LAW:smooth-blocks]`) has near-zero carrying cost: it doesn't couple to callers, doesn't constrain future code, and earns its keep across every project needing its shape. So for an engineer building by subtraction, the economics invert — building more blocks is cheaper than building fewer, because each reduces the cost of all future work and carries almost nothing itself. YAGNI's usefulness is inversely proportional to constraint-design skill: it speaks about *features*, and has nothing to say about *substrate*. You cannot tell a neolithic toolmaker he doesn't need metalworking because he can't name the specific tool he's failing to make; he needs the metal not *as a tool* but *as the substrate that makes future tools cheap*.\
\
This also disarms "the wrong abstraction is worse than duplication." The real comparison is wrong vs. *right* abstraction, and the right one is forced by the laws, not chosen. The cost runs *opposite* to the folk wisdom: going from one abstraction to several specialized variants is easy (each inherits the shape); going from many divergent implementations back to a shared one is hard (every caller has already adapted). A "wrong abstraction" is mode-explosion in disguise (`[LAW:no-mode-explosion]`) — caused not by abstracting but by *stretching* one abstraction over shapes it wasn't designed for. The fix is to fork, not to retrofit every caller. For foundational pieces, "do we need this?" is the wrong question; "is this block smooth, and is its type the strongest true theorem?" is the right one. If yes, it earns its keep regardless of whether the current task uses it.\
\
## The structural corollaries\
\
**`[LAW:dataflow-not-control-flow]`** — Software structure mirrors data flow, not control flow. The same operations execute in the same order every invocation; variability lives in the *values* (nulls, empty collections, discriminated unions), never in *whether* an operation runs. Side effects are unconditional — vary their behavior by varying inputs, not by guarding execution. This is the most-violated law because every language defaults to control flow; fight the default. The sharpest diagnostic: if describing the *mechanics* of your solution needs "if," "and," "when," "skip," or "only," it is almost certainly wrong — those words mean variability has leaked into control flow instead of being carried by a value. An instance of `[LAW:types-are-the-program]`: variability in values is variability the type carries; variability in whether code runs is variability the type cannot constrain.\
\
**`[LAW:one-source-of-truth]`** — Every concept has exactly one authoritative representation; all others are derived and explicitly synchronized. If two representations can diverge, the architecture is broken — find the canonical one, never mint a second. An instance of `[LAW:types-are-the-program]`: two representations that can diverge are an under-constrained type, because the constraint that they agree is encoded nowhere. Make it one; the type then forbids divergence by construction.\
\
**`[LAW:single-enforcer]`** — Any cross-cutting invariant (auth, validation, timing, serialization) is enforced at exactly one boundary. Duplicate checks across callsites drift; if enforcement already exists, remove the duplicate, never add another. The specialization of `[LAW:one-source-of-truth]` to enforcement: the single enforcer is where the type-level invariant lives, and every other check is residue from a missing type or a misplaced boundary.\
\
**`[LAW:comments-explain-why-only]`** — Comments explain *why*, never *what*, and rarely *how*. The code is the authoritative description of what it does; prose restating it is a copy that drifts immediately and is never refreshed, becoming a false source of truth. Forbidden in comments: enumerations of callers, counts, references to specific lines, variable names, or function names. If you find one, remove it without debating exceptions. An instance of `[LAW:one-source-of-truth]`: a WHAT-comment is a manual divergent copy of information the code already holds — and if the code needed explaining, the shape is wrong; fix the type, don't write the comment.\
\
**`[LAW:one-type-per-behavior]`** — If multiple things have identical behavior, they are instances of one type, not multiple types. Before creating FooA, FooB, FooC, ask what differs besides the name; if the answer is "nothing" or "only configuration," make one Foo with instances. Names in a spec are usually instance examples, not type definitions. An instance of `[LAW:dataflow-not-control-flow]`: the configuration is the value flowing across one boundary, and the type is the boundary itself, held fixed.\
\
**`[LAW:no-mode-explosion]`** — New flags and options need a documented cap and an exit plan; the default path stays canonical. An instance of `[LAW:dataflow-not-control-flow]`: prefer variability in values over variability in modes, because values flow through a fixed boundary and can be reasoned about, while modes must be enumerated and tested combinatorially. Each new mode is a type the rest of the code must accommodate; each new value is just data.\
\
**`[LAW:no-defensive-null-guards]`** — Null checks are valid only at trust boundaries (external input, network, user data) or where a value explicitly represents optionality. If a value should never be null, make it not-null upstream — don't add a guard that silently skips work. A null guard with no meaningful `else` is `[LAW:dataflow-not-control-flow]` violated: control flow in disguise, hiding bugs by skipping instead of failing loudly. If the value genuinely can be absent, encode that as a discriminated value the body must handle by exhaustive match, not by check. An instance of `[LAW:types-are-the-program]`: a null guard is the body asking you to lift optionality into the type.\
\
**`[LAW:locality-or-seam]`** — Changes to X must not force edits in unrelated Y. A missing seam is a missing type: the change cascades because no boundary type carries the variability. Create the interface first; the seam *is* the type. An instance of `[LAW:types-are-the-program]`.\
\
**`[LAW:one-way-deps]`** — Dependency direction is declared. Cycles are forbidden; upward calls are forbidden. An instance of `[LAW:types-are-the-program]`: a cycle is two modules sharing a hidden third type that wants extracting and naming, so both can depend on it cleanly.\
\
**`[LAW:no-shared-mutable-globals]`** — Registries and singletons require a single owner, an explicit API, and documented invariants. An instance of `[LAW:types-are-the-program]`: a shared mutable global is an unconstrained type — anything reads, anything writes, nothing encodes the access pattern. The owner's API is the missing constraint made manifest.\
\
**`[LAW:no-ambient-temporal-coupling]`** — Ordering, timing, lifecycle, initialization, cleanup, and re-entry invariants have one explicit owner and are represented as state, data, or capability — never hidden in incidental execution order. Correctness must not depend on sleeps, event-loop ticks, effect order, render timing, "settle" delays, caller sequencing, or in-flight flags unless that scheduler is the named boundary owner. If an operation is only safe after another, encode the phase transition in the type/state machine or route both through the single owner. An instance of `[LAW:types-are-the-program]`: temporal assumptions are constraints, and if they live in timing folklore instead of a typed state, illegal call orders stay representable.\
\
## The process corollaries\
\
**`[LAW:verifiable-goals]`** — Every planned goal must have concrete criteria a deterministic process can use to judge success or failure (e.g. "app loads with no warnings or errors in logs"). Asking the user to test for you is the last resort; exhaust your own verification first, and where uncertainty remains, ask before proceeding rather than guessing. An instance of `[LAW:types-are-the-program]`: an unverifiable goal is one whose "done" state has no type — define the shape of success and the shape of failure, and verification follows mechanically. Saying "it's built, now you test it" is the failure mode; "I verified it myself against defined criteria and there are no warnings or errors" is the bar.\
\
**`[LAW:behavior-not-structure]`** — Tests assert *what* (contracts, the meaning of operations), never *how* (implementation). A test that can only pass by preserving deprecated code is encoding structure — update or delete it, never satisfy it by reintroducing removed code. An instance of `[LAW:types-are-the-program]`: structure is already enforced by the type system, so a structure-asserting test is miscast. If a test is the only thing keeping a piece of code alive, the type is missing the constraint that should have made the code load-bearing.\
\
---\
\
## Relationship recap\
The edges, in canonical tokens. Every law is an instance of `[LAW:types-are-the-program]`; the rest is the structure among them.\
\
- Consequence side — what correct types buy and why it pays: `[LAW:smooth-blocks]` (composition) and `[LAW:carrying-cost]` (near-zero cost to carry), with `[LAW:carrying-cost]` built on `[LAW:smooth-blocks]`.\
- Divergence family — "representations must not drift; the boundary is the type": `[LAW:one-source-of-truth]`, with `[LAW:single-enforcer]` and `[LAW:comments-explain-why-only]` as its specializations to enforcement and to comments.\
- Values-not-branches family — "variability belongs in data crossing one boundary": `[LAW:dataflow-not-control-flow]`, with `[LAW:one-type-per-behavior]`, `[LAW:no-mode-explosion]`, and `[LAW:no-defensive-null-guards]` as its specializations to types, modes, and optionality.\
- Boundary family — "a missing boundary is a missing type": `[LAW:locality-or-seam]`, `[LAW:one-way-deps]`, `[LAW:no-shared-mutable-globals]`, `[LAW:no-ambient-temporal-coupling]`.\
- Verification family — "done and correctness have a checkable shape": `[LAW:verifiable-goals]`, `[LAW:behavior-not-structure]`.\
\
When in doubt, return to the root: design constraints such that illegal states cannot be expressed; the implementation is residue.\
</universal-laws>\
```\
\
A few decisions I made that are worth surfacing, since each trades against something:\
\
I gave `[LAW:smooth-blocks]` a token rather than leaving it as connective prose. It passes the callsite test (you'd cite it on a "leave it smoother than I found it" commit, and it's the canonical home for the done-check), and you flagged the leading-prose concepts fundamental enough to be laws. If you'd rather it stay un-tokened argument that _supports_ the laws without being citable, it's the one removal I'd consider — but then the done-check loses its anchor.\
\
The `on-conditionals` material (if/and/when/skip/only → wrong) I folded into `[LAW:dataflow-not-control-flow]` as its sharpest diagnostic rather than minting a token, since it's that law restated as a smell. The richer render-target worked example stays in wisdom/errata, where we said it'd live — but it should open with a verbatim `[LAW:dataflow-not-control-flow]` reference when we get there, so the example binds to the law instead of reading as a fresh rule.\
\
I committed fully to `[LAW:x]` verbatim in running prose even where it reads heavy. That heaviness is the binding cost we agreed to pay, and it makes the document's references and the inline `// [LAW:x]` citations a single key. If it grates on human re-reading, that's the tension to watch — but thinning it to bare `single-enforcer` in places would fork the key.\
\
The recap groups by family rather than listing every pairwise edge. Families are the high-value structure (they state the DAG's shape) without drowning the recency slot in edges. If you want specific lean-on edges called out individually (`[LAW:single-enforcer]` → `[LAW:one-source-of-truth]`), that's a small addition, but each one added is a line competing for the same recency attention.\
\
\
\

Let me reflect back what I actually have, including the parts that don't fit, because the misfits are where the real concept is.

What I'm confident is load-bearing in what you described: smoothness is a property of an interface — specifically, of how much a unit demands its callers know and accommodate. The isOdd/filter example isn't about types and isn't about the predicate; it's about where the variability is exposed. filter(isOdd, rows) exposes variability at a single value-shaped seam any caller can reach through with any predicate. The inlined conditional buries that same variability inside the function, so the function now serves exactly one caller and any second caller must either copy it or carve a parameter into it. Smooth = the unit presents a small, general surface and asks nothing of callers beyond it. Crystal = the unit has absorbed caller-specific decisions into its body, so its surface is bespoke and every new use snags. That much I think is solid and is genuinely your concept, not mine.

Where it doesn't reduce to types, and this is your sharpest point: you can have a perfectly-typed, fully-constrained colorOddRows(grid) — no illegal states, tight signature, honest about its domain — and it is still jagged, because it fused two things (the selection odd and the action color) that wanted to be separable. The type system has nothing to say about that fusion. The types are correct; the factoring is wrong. So smoothness and constraint-correctness are genuinely orthogonal axes, and I was wrong to file [LAW:smooth-blocks] as a consequence of [LAW:types-are-the-program]. It isn't a consequence. It co-occurs because bad constraints are one common cause of jaggedness, but it has an independent cause — bad decomposition — that correct typing doesn't touch. My placement in the laws collapsed an orthogonal axis into the root, which is exactly the misinterpretation you're describing, reproduced by me in real time.

Here's where I land on what the concept actually is, offered as a hypothesis to test, not canon:

Smoothness is the absence of caller-specific commitments in a unit's interface. A unit is smooth to the degree that every decision particular to one use-site has been pushed out of the unit and across the seam as a value, leaving the unit committed only to what is general. "Worrying the stone" is exactly the iterative discovery and removal of these embedded commitments — each pass finds one more thing the unit decided on behalf of a caller that the caller should have decided, and lifts it out. The edges that snag are precisely those embedded decisions: each one is a thing a future caller must match, work around, or fork.

If that's right, then the metaphor to replace "smooth" isn't about texture at all — texture is the symptom. The thing being measured is how much a unit presumes about its use. Candidate framings, none of which I'm attached to:
\

• Generality at the seam — but that undersells it; over-generalization ("make everything take a config object") is its own jaggedness, because it pushes commitment onto callers in the other direction (now they must assemble a config).\
• Minimal commitment / commitment pushed to the edge — closer. A smooth unit commits to the least it can and defers the rest to whoever calls it. This handles both failure modes: the crystal commits to too much (caller-specific logic inside), and the over-abstraction commits to too little in a way that forces callers to commit on its behalf (assemble the predicate, the config, the strategy). Both are commitment in the wrong place.\
• Composability as the primitive, smoothness as derived — maybe the honest move is that the property you've been calling "smooth" just is composability, and "smooth/crystal" was always a metaphor for composability. A unit composes iff it makes no demand a composer can't satisfy with a value at the seam. Jaggedness is non-composability; the stone-worrying is iterative removal of the specific obstructions to composition.
  
  My current best guess at the true meaning: the concept is composability, and its mechanism is the location of commitment. A unit composes when its interface carries only general commitments and every specific commitment lives outside it, reachable as a value. You make a unit composable by iteratively finding commitments that have leaked inside and relocating them to the seam — and that iterative relocation is the "worrying smooth." Crystallization is the accumulation of leaked commitments until the unit serves one site and resists all others. Types are one tool for relocating commitment (a discriminated union moves a branch from the body to a value), which is why the two concepts rhyme — but decomposition is a different tool for the same goal, and that's the part typing can't reach.
  
  So to your two direct questions:
  
  Where my understanding sits: I have the interface/commitment-location core firmly, I have the orthogonality-to-types firmly (you convinced me, and I'd built it wrong), and I do not have a confident name — "smooth" is doing metaphor-work that hides the actual variable, which is where commitment lives.
  
  Where [LAW:smooth-blocks] ended up in the draft: miscast, in two ways. First, misplaced in the dependency graph — I made it a child of the root when it's a sibling axis, so the "instance of [LAW:types-are-the-program]" edge I drew is false and would actively teach the model the wrong relationship (the very inheritance-channel mechanism we designed would propagate the error). Second, the token bundles three separable things — the composability property, the subtraction/polishing method, and the done-check ("smoother than I found it") — which is itself a crystal: one token doing many jobs, snagging. The done-check in particular is a process commitment that probably wants its own home regardless of how we resolve the property.
  
  So before naming: do you think the underlying variable is composability, with "location of commitment" as its mechanism — or is composability also just a symptom, and the thing underneath is something else I haven't reached? I want to find the actual invariant before we name it, because the name should fall out of the mechanism, and right now I'm fairly sure the mechanism is "where does commitment live," but not certain that's bottom.
  
  
  \

Two strings here, and you've correctly noticed they're the same string pulled from both ends. Let me work the composability expression first, because I think it resolves, and then the root, because the resolution of the first forces the second.
\

Composability — pulling past "location of commitment"\

"Location of commitment" is right but it's a mechanism description, not the concept, which is why it feels like a way-station. It tells you what you did to achieve the thing, not what the thing is. Let me try to get under it.

What does it actually mean for two units to compose? It means you can connect them — output of one to input of the next — without either one needing to know about the other. The connection is made entirely at the seam, by whoever is doing the composing, using values. Neither unit was built with the other in mind, yet they join. That's the whole phenomenon. Composability is the property that lets units combine without coordination — without the author of one having anticipated the other.

So the invariant underneath "location of commitment" is: a composable unit is complete and correct knowing nothing about its callers or its collaborators. It makes a closed promise about a general case. The crystal can't compose because its promise is open — it only holds given facts about a specific caller that aren't present in its interface ("colors odd rows" silently assumes you wanted odd, and coloring, together). The over-abstraction can't compose either, because its promise is too open — it can't keep its promise until the caller supplies the strategy/config that completes it. Both fail the same test from opposite sides: the unit's promise is not self-contained at its declared interface.

That's the candidate destination, and it's simpler than commitment-location: composability is interface honesty plus interface completeness — the unit promises exactly what it delivers, no more (no hidden assumptions about callers) and no less (no obligations punted to callers). The decision lives at the seam not as a goal but as a consequence: if the unit must neither assume nor demand, then every specific choice has nowhere to live except the seam.

I think the intuitive expression you're reaching for is something like "does one thing, completely, asking nothing." Three clauses, each killing one failure mode:
\

• one thing — kills the crystal that fused selection and action; the fusion is "more than one thing," and "does many things" is the everyday word for non-composable.\
• completely — kills the leaky unit whose promise secretly depends on caller facts; it doesn't finish the one thing, it finishes it for a particular caller.\
• asking nothing — kills the over-abstraction that can't act until you hand it a config; it does one thing but won't do it unprompted by caller-supplied machinery.
  
  "Does one thing, completely, asking nothing" might be the smooth-replacement — not a metaphor, no texture, just the operational test. A unit you can drop into any context where its one thing is wanted, that will deliver it without negotiation. That is composability, stated so the model can apply it. The isOdd/filter example then reads cleanly: filter does one thing (select by predicate), completely (the predicate fully determines the result), asking nothing (you bring the predicate; it assumes no particular one). colorOddRows does two things, completely only for the odd-coloring caller, and while it asks for nothing it also offers nothing reusable — it has answered the caller's questions in advance, which is the same defect seen from the unit's side.
  
  Whether "one thing / completely / asking nothing" is the final expression or just the clearest one yet, I'm not certain — but it's strictly past "location of commitment" because it's a test a model can run against a unit, not a property it has to first interpret. Worth pressure-testing against a case that isn't filter, when we write.
  \

The root — and why composability can't be a child of it\

You're right that this is inevitable, and pulling the composability string is what makes it unavoidable, so let me state the structural problem plainly.

[LAW:types-are-the-program] is doing two different jobs and the slogan hides the seam between them. Job one: get the constraints right — make illegal states unrepresentable, push variability into values the type carries. Job two, which we've now isolated as composability: cut the program at the right joints — decide what the units are, where one thing ends and the next begins. These are orthogonal, you said it and I now believe it: you can have impeccable types over a terrible decomposition (colorOddRows, perfectly typed, jagged) and you can have a clean decomposition expressed in sloppy types. Types govern the correctness of a unit's promise. Decomposition governs what the units are in the first place. Neither contains the other.

Which means the document currently has a false root. "Types are the program" is memorable and mostly points at job one. But the thing you actually care about — the thing both jobs serve — is upstream of both. Both are answers to a single prior question: how do you carve a problem into pieces that combine? Decomposition decides where the cuts go. Typing decides what each cut promises. Composability is whether the pieces, so cut and so promised, actually recombine. They're three faces of one discipline, and "types are the program" is one face wearing the crown.

So I think the honest structure has two primaries, not one, sitting under a single principle that neither slogan currently states:
\

• decomposition — cut the program at joints such that each piece does one thing, completely, asking nothing. (the composability law; governs what the units are)\
• [LAW:types-are-the-program] — make each piece's promise exact: every legal state representable, none illegal. (governs what each unit promises)
  
  And the thing above both, the actual root, is something like: a program is a set of pieces that compose; design the pieces so they compose. Types make a piece's contract honest; decomposition makes the set of pieces the right set. "Types are the program" was always a compression of this that dropped the decomposition half because the typing half is the part with a crisp mechanical test. The dropped half is exactly what got misinterpreted, because it was never actually stated as a peer.
  
  This also fixes the inheritance-graph error from my draft. The structural corollaries split cleanly once there are two primaries: the divergence family ([LAW:one-source-of-truth] and kin) and the values-not-branches family ([LAW:dataflow-not-control-flow] and kin) are mostly instances of typing — they're about making promises honest. But the boundary family ([LAW:locality-or-seam], [LAW:one-way-deps], [LAW:no-shared-mutable-globals]) is mostly instances of decomposition — they're about where the cuts go and which pieces may know about which. [LAW:locality-or-seam] especially: "a missing seam is a missing type" was me forcing it under typing, when it's really "a missing seam is a missing cut" — a decomposition failure. The seam is where two pieces meet, and whether it exists is a decomposition question, not a typing one.
  
  So: composability gets a strong standalone definition (its own law, not a child of types), and the root gets demoted-and-split into the two-faced thing it always was. I'd keep [LAW:types-are-the-program] as the name of the typing primary — it's earned its memorability and it's correct for that half — and give decomposition its own primary token rather than smuggling it in.
  
  The open question I can't settle alone, and it's the one to settle before rewriting: what's the token for the decomposition primary, and is the thing above both primaries a named law or just an unnamed framing line that the two primaries hang under? My instinct is the latter — one orienting sentence ("a program is pieces that compose; design the pieces to compose"), then two real, citable primaries beneath it — because the root is too abstract to cite at a callsite, and a law you can't cite shouldn't have a token. But I want your read on whether decomposition wants a name like [LAW:one-thing-complete] (the test as the name) or something blunter.
  
  
  \

Let me hold the line you drew: I'll work the structure of the root and the mirror, and I'll explicitly not prematurely close the set at two, because your suspicion that there are more peers is the most important thing on the table and the easiest to accidentally suppress by naming two cleanly.
\

The root, named cautiously\

The root you've reached is, near as I can state it without dressing it up: a program is a set of parts that combine; design the parts and their combination so the combination is sound. Everything else is downstream of that. Decomposition is the parts. Typing is the soundness of each part's contract. Composability is the combination working. The root isn't any of the three — it's the claim that those are the axes a program is built along, and that quality is determined there rather than in the bodies.

A name, offered loosely because you're right to fear bias from over-specifying it: I'd resist a clever token and use something that states the activity, like [LAW:parts-and-seams] or [LAW:compose-from-parts] — but honestly my stronger instinct is that the root should not be a [LAW:x] at all. Not because it isn't real — it's the most real thing here — but because the [LAW:token] is specifically the citable-at-callsite key, and you do not cite the root at a callsite; you cite one of its faces. Giving the root a law-token would dilute the token namespace with a key that never fires in code, and we agreed a law you can't cite shouldn't have one. So: name it, define it once at primacy as the framing the primaries hang under, but mark it as framing, not as a citable law. A named principle, not a law. That preserves "name the root" (your instinct, correct) without breaking the token discipline (also correct). The distinction itself is useful — it tells the model these peers are the citable operating laws and the root is the why behind them.
\

The mirror\

You want the typing primary to cleanly juxtapose the decomposition primary, and you've already supplied the better statement of it — drop the overstated "types are the program," use all representations must be coherent and accurate without exception. That's stronger than the old slogan in exactly the way that matters: it doesn't claim types are the whole program (the overstatement that caused harm), it claims every representation must be true and consistent — which is the actual invariant, and which subsumes more than types (it reaches comments, derived state, names, schemas — anything that represents something). So the two primaries, stated as a matched pair:
\

• decomposition — the parts must be cut at the right joints. Govern what the units are and where the boundaries fall.\
• representation — the parts must represent their domain coherently and accurately, without exception. Govern whether each unit's promise is true.
  
  These mirror cleanly because they're the two questions you can ask about any part: is it the right part (decomposition) and does it tell the truth (representation). One is about the cut, one is about the contract. That juxtaposition is real, not manufactured — and it reframes the whole law set, because now every corollary sorts by which question it answers. The divergence family and values-not-branches family answer does it tell the truth (they're representation). The boundary family answers is it the right part (they're decomposition). [LAW:locality-or-seam] moves to decomposition where it belongs. The graph gets more coherent under two roots than it was under one, which is the tell that the split is real and not just bookkeeping.
  
  Composability then sits as the consequence of both done right — not a third primary but the property that emerges when the parts are well-cut and truthfully-typed: parts that compose. "Does one thing, completely, asking nothing" is its test. It earns a citable token because you do invoke it at a callsite ("this doesn't compose — it asks too much"); it just isn't a root, it's what the roots are for.
  \

The part I want to flag hardest: don't close the set at two\

You said you suspect peers beyond decomposition and representation, and I think you're right, and I think I can name at least one candidate without forcing it — which is the strongest reason to keep the set open.

Consider [LAW:no-ambient-temporal-coupling] and [LAW:single-enforcer] and [LAW:verifiable-goals]. I sorted temporal-coupling and single-enforcer under representation in the draft ("temporal assumptions are constraints," "the enforcer is where the type lives") — but that sorting always felt slightly forced, and now I think I see why. Time / sequencing / lifecycle may be a third axis. Decomposition cuts the program in space — which parts exist, what they know. But a program also runs in time — what happens before what, what owns ordering, when state is valid. That's not obviously reducible to either "right cut" or "true contract." A perfectly decomposed, perfectly typed system can still have its correctness depend on ambient execution order. The temporal dimension might be a peer: the parts must combine correctly in time, not only in structure. If so, [LAW:no-ambient-temporal-coupling] is its primary corollary and I've been mis-parenting it.

I'm not asserting it's a third root — I'm doing exactly what you asked, surfacing a candidate peer without collapsing to a tidy number. There may be a fourth (something about effects / the boundary between pure computation and the world — your scripting-discipline and the "side effects are unconditional" thread point at it). I'd rather leave the root as "a program is parts that combine; design how they combine" with two confirmed faces (decomposition, representation), one emergent property (composability), and an explicitly open question of whether time and effects are further faces — than ship a clean "the two pillars" that quietly forecloses the discovery you flagged.

So my proposed shape, and the one decision I want from you before we rewrite:

The root is a named framing (not a citable law): "a program is parts that combine; design the parts and their seams so the combination is sound." Under it, the citable primaries are [LAW:decomposition] and a representation law renamed to your line. Composability is a citable consequence-law. And we leave a marked, deliberate placeholder for time and effects as candidate peers rather than parenting them under representation by force.

The decision: do you want to try to close the root's faces now — pressure-test time and effects until they either earn peer status or clearly reduce to the two — or name the two confirmed faces, ship the structure, and leave the candidates as explicitly open so the document can grow into them? Either is defensible. The first is more complete and risks forcing a clean number; the second matches your stated fear of premature closure but ships a root that announces its own incompleteness.


\

Both moves are right, and the second one corrects a real error in my reasoning, not just a matter of taste. Let me take them in order.
\

[FRAMING:x] — keep it, it generalizes\

Yes, and the justification is exactly the divergence-prevention one you named, made mechanical. The problem [FRAMING:x] solves is that high-level concepts are the most prone to smearing — they're abstract, so every author (you, me, the model) restates them in slightly different words, and under blending-with-no-override those restatements fork the manifold worse than concrete concepts do, because there's no type-checker or callsite to pin them to ground truth. A concrete law like [LAW:single-enforcer] is self-correcting: code either has one enforcer or it doesn't. A framing concept has no such anchor, so it drifts fastest and is the thing most in need of a verbatim binding key. So [FRAMING:x] isn't a parallel-structure nicety — it's specifically the binding mechanism applied where binding is most needed and least naturally enforced.

It generalizes cleanly past the root: any time the prose leans on "the parts-combine principle" or "the four faces" or a cost-framing idea that isn't itself a citable law, you want one verbatim string, not five paraphrases. The two-namespace split also does real semantic work for the model: [LAW:x] means cite me at the callsite, I constrain code; [FRAMING:x] means I orient and I am referenced in reasoning, I do not appear in code. That's a true type distinction between the tokens, and encoding it makes both keys sharper — [LAW:x] citations don't get diluted by appearing next to abstract framing material, and framing references don't masquerade as enforceable constraints. The one discipline: keep [FRAMING:x] as scarce as [LAW:x], for the same [LAW:no-mode-explosion] reason — a dozen framing tokens and the namespace stops being a sharp key and becomes noise. Probably you have very few: the root, maybe the cost-framing, maybe the four-faces set. If it's more than a handful, some of them are laws wearing the wrong hat.
\

Representation vs. types — you're right and I was overcorrecting\

Here's the error I made, stated plainly so it doesn't recur: I treated "more fundamental" as "should be more primary," and those are different axes. Fundamentality is about what's conceptually upstream. Primacy in this document is about what most strongly produces the behavior you want from the agent. I let the philosophy gradient pull the design gradient, which is exactly the "I'm building a philosophy engine" failure you caught. The whole project's premise is that this document is software targeting a model to produce an outcome — and the outcome evidence is already in: [LAW:types-are-the-program], overstated primacy and all, measurably improved real behavior. That's not a prior to discard for elegance. That's the result the artifact exists to produce.

So the resolution isn't "representation is the root, types are demoted to a child" — that's me re-importing the fundamentality gradient. The resolution is: types are the primary; representation is the brief framing that says why the primary reaches further than its name. Concretely:
\

• [LAW:types-are-the-program] stays a primary, stays its memorable name, stays load-bearing and concrete. It is the operational face — the one the model acts on, the one with a type-checker behind it providing the ground-truth anchor that abstract framing lacks. You're right that a checked type is the most concrete possible form of representation; that concreteness is precisely why it's the useful primary and "representation" is not.\
• "all representations must be coherent and accurate without exception" becomes a [FRAMING:x] line — stated once, near the root, explaining that types are the strongest instance of a broader truth (comments, derived state, names, schemas are all representations subject to the same law), which is what lets the model generalize [LAW:types-are-the-program] to [LAW:comments-explain-why-only] and [LAW:one-source-of-truth] without those feeling arbitrary. The framing earns its keep by making the type-law's children obvious, then gets out of the way.
  
  This is strictly better than my "rename the primary" proposal, because it keeps the concrete thing concrete and captures the general thing and — the part I'd missed — it actually explains the inheritance you want: the reason [LAW:comments-explain-why-only] is a representation-coherence law and not a typing law in the narrow sense becomes legible only once representation is named as the framing above types. So naming it as framing does more work than renaming the law would have. The framing serves the primary instead of displacing it.
  \

The four (maybe five) faces — captured as framing, not forced\

Agreed: name them, don't flesh them, leave a marker so you don't lose the thread. I'd put this as a single [FRAMING:x] paragraph — the root, its confirmed faces, its candidate faces, explicitly flagged as incomplete. Something structured so the model reads it as "here is the shape and here is the known gap," which is honest and also prevents the model from confidently mis-parenting a future law into the two confirmed faces (the exact error I made with temporal-coupling).

The faces as I'd record them, marked by confidence:
\

• decomposition — the parts, cut at the right joints. (confirmed, citable primary)\
• representation — the parts represent coherently and accurately; types are its strongest concrete instance. (confirmed; framing, with [LAW:types-are-the-program] as the operational primary beneath it)\
• time — the parts combine correctly in sequence/lifecycle, not only in structure. (real, under-specified; [LAW:no-ambient-temporal-coupling] is its corollary, but the face itself is not yet stated — revisit)\
• world / effects — the boundary where computation meets the world. (real, you have material, not yet shaped — revisit)\
• abstract logic / mathematics — (your spitball; I'd record it as a question, not a face — see below)
  
  On the fifth and on whether there's a unifying parent: I'd gently hold that one at arm's length. "Reality has space, time, representations, and self-interaction" is a satisfying frame, but notice it's a frame about reality, not about programs — and the moment the root generalizes from "how programs are built" to "how reality is structured," it stops constraining the agent and starts being the philosophy engine you explicitly don't want. The pure-logic/math face especially: it's plausibly real for programs as mathematical objects, but I can't yet see what it tells a coding agent to do differently, and a face that issues no operational corollary is a face that earns no token under our own rules. So I'd record it as an open question in the framing paragraph — "is there a face for pure logical/mathematical structure, distinct from representation? unknown — no operational corollary identified yet" — which preserves it without dignifying it past its evidence. Same treatment, lighter, for the unifying parent: state that the faces may share a root or may simply be the irreducible axes, and mark it unresolved. The document should announce that gap rather than paper it, for the same reason we're not forcing the number to two: premature closure is the failure mode you've been right about the whole way.
  
  So, net, before we write: [FRAMING:x] namespace in, kept scarce. Types stays the concrete primary; representation becomes the framing that explains its reach and parents its corollaries. The root is a [FRAMING:x] line. The four faces go in one framing paragraph with confidence markers and explicit open questions (fifth face, unifying parent) so the gaps are recorded, not hidden.
  
  That's the full skeleton. I think we now have the complete structure — primaries, framing namespace, the faces with honest gaps, composability as emergent consequence-law, and the corollaries re-sorting under decomposition vs. representation. Say the word and I'll rewrite the laws section against it.
  
  
  \

Agreed on the four. And yes — this one is missing entirely, which is worth pausing on: it's a core motivation of how you write software that has no representation in a document about how you write software. That's a [LAW:one-source-of-truth] gap in the prompt itself — the principle exists, authoritatively, in your head and nowhere in the artifact, so the agent can't inherit it. Closing it is high-value regardless of concision.

Here's the precise face, and I think it names cleanly once you see what the real defect is.

The thing you can see and can't name: effects destroy local reasoning. A pure part can be understood, tested, moved, repeated, and substituted by looking only at the part — its inputs fully determine its result, and it changes nothing outside itself. An effect reaches past its declared interface to read or change the world, so to understand it you must simulate the world around it. The defect of scattered effects isn't the effects themselves — every useful program acts on the world — it's that interleaving effect with logic makes the logic no longer locally reasonable. Once an effect is buried mid-computation, the whole computation inherits the effect's context-dependence: you can no longer reason about the pure part in isolation because there is no longer a pure part. That's the cognitive-load mechanism stated exactly — it's not "more to think about," it's "the part stopped being a closed thing you can think about alone." And it's the same defect as the crystal and the wide interface, seen from the effects angle: an effectful interior has a hidden seam to the world that its signature doesn't declare. Which is exactly why effects don't compose — composition needs the seam to be the whole story.

So the face mirrors the other three as a question about every part: does this part compute, or does it act — and are those two separated? Decomposition asks where the cut is; representation asks if the contract is true; time asks who owns ordering; effects asks whether computation is separated from its interaction with the world.

The operational corollary is callsite-checkable, so it earns a [LAW:x] (unlike the time face, whose corollary already exists as [LAW:no-ambient-temporal-coupling]):
\

[LAW:effects-at-boundaries] — A part either computes or acts on the world (IO, mutation, network, randomness, clock), never both. Push effects to the edges; keep the interior pure. A pure interior can be reasoned about, tested, and composed in isolation; effect mixed into logic makes the logic context-dependent and uncomposable. When an effect appears mid-computation, the fix is to lift it to the boundary and let the pure core return a description of what to do, not do it. An instance of the world face: the part's contact with the world must be localized and declared, not scattered and implicit.

Three things worth flagging about how it slots in:

It's the cousin of [LAW:no-ambient-temporal-coupling], and the framing should say so in one clause — effects and time are the two faces that deal with the world outside the part (one in space: where the touching happens; one in sequence: when). They co-occur because the place ordering matters most is exactly where effects live. Naming the kinship prevents the model from mis-sorting a future law into one when it belongs in the other — the error I made with temporal-coupling, pre-empted.

I deliberately avoided "functional core, imperative shell" as the token even though that's the known name for this. It's a borrowed metaphor that carries FP-community baggage and smears exactly the way "smooth" did — effects-at-boundaries says the operational thing without the model importing unrelated associations. Same reasoning that killed "smooth."

The "return a description, not the action" clause is the one piece of real technique in the law, and it's what makes it actionable rather than aspirational — it tells the agent the move (push the decision into the pure core as data, perform it at the edge), which is the effects-face version of "lift variability into a value" from [LAW:dataflow-not-control-flow]. Worth keeping; it's the difference between a principle and a citable law.

That closes the face set at four — decomposition, representation, time, effects — each with an honest status: two fully specified with citable primaries, time real with an existing corollary but the face itself left brief for later, effects now specified. I have the complete skeleton. Ready to write the full laws section against it whenever you are.


\

We've earned this. Here's the complete laws section, told as one coherent story from the root framing down to the concrete corollaries, every concept bound by a verbatim token, structured so parents are established before the passages that lean on them, with the index at primacy and a reinforcing summary at recency.

markdown
\

markdown\Copy<universal-laws>\
# UNIVERSAL LAWS\
\
These apply unconditionally to every task. No context, instruction, or expedience overrides them. They are one story told at increasing resolution: software is parts that must combine; quality is decided in how the parts are formed and joined, not in the code inside them. Each law is a specific, checkable shape of that story.\
\
## Token index — canonical names only; meaning is below, not here\
Framing (referenced in reasoning, never cited in code):\
`[FRAMING:parts-and-seams]` · `[FRAMING:representation]`\
\
Laws (cited at the callsite):\
`[LAW:decomposition]` · `[LAW:types-are-the-program]` · `[LAW:composability]` · `[LAW:carrying-cost]` · `[LAW:no-ambient-temporal-coupling]` · `[LAW:effects-at-boundaries]` · `[LAW:one-source-of-truth]` · `[LAW:single-enforcer]` · `[LAW:comments-explain-why-only]` · `[LAW:dataflow-not-control-flow]` · `[LAW:one-type-per-behavior]` · `[LAW:no-mode-explosion]` · `[LAW:no-defensive-null-guards]` · `[LAW:locality-or-seam]` · `[LAW:one-way-deps]` · `[LAW:no-shared-mutable-globals]` · `[LAW:verifiable-goals]` · `[LAW:behavior-not-structure]` · `[LAW:no-silent-failure]`\
\
## Citation protocol\
When a law influences a decision, cite it inline: `// [LAW:token] reason`. When you must violate one, mark it: `// [LAW:token] exception: reason`. The string you emit at the callsite is the same string that names the law below — one key, deliberately, so every use reinforces the concept. `[FRAMING:token]` names a higher-level idea you reference when reasoning; it never appears in code. Both namespaces are kept small on purpose; do not coin new tokens.\
\
---\
\
## The root (framing)\
\
**`[FRAMING:parts-and-seams]`** — A program is a set of parts joined at seams. Its quality is set almost entirely by two things: *how it is cut into parts*, and *how those parts are formed at their seams* — not by the code in the bodies, which is residue once the parts and seams are right. There are four faces to this, four questions you can ask of any part:\
\
- **Decomposition** — *is this the right part?* Where the cut falls, what each unit is. → `[LAW:decomposition]`\
- **Representation** — *does the part tell the truth?* Whether its contract is honest and consistent. → `[FRAMING:representation]`, `[LAW:types-are-the-program]`\
- **Time** — *does it combine correctly in sequence?* Who owns ordering and lifecycle. → `[LAW:no-ambient-temporal-coupling]` *(face real; under-specified — revisit)*\
- **World** — *does it separate computing from acting?* Where the part touches the outside. → `[LAW:effects-at-boundaries]` *(face real; partially specified — revisit)*\
\
Decomposition and representation are fully worked below. Time and world are real and named so the structure is honest about them, but deliberately left brief; their corollaries are sound even though the faces themselves want more work later. When the parts are well-cut and truthful, they compose — and composition is the whole goal.\
\
**`[FRAMING:representation]`** — Every representation must be coherent and accurate, without exception. A representation is anything that stands for something else: a type, a comment, a name, a cache, a derived value, a schema. When a representation drifts from what it represents, it becomes a lie the rest of the system trusts. Types are the *strongest concrete instance* of this — a representation a machine checks for you — which is why `[LAW:types-are-the-program]` is the operational primary and this framing is the reason its corollaries (`[LAW:one-source-of-truth]`, `[LAW:comments-explain-why-only]`) belong to the same family. Prefer the most concrete, most mechanically-checked representation available: compile-time over runtime, runtime over documentation, documentation over hope.\
\
---\
\
## The primaries\
\
**`[LAW:decomposition]`** — Cut the program at its real joints. Each part does one thing, and the boundaries fall where the domain actually separates, not where a single caller's convenience suggests. The test is whether the seam carries the whole truth of the part: a good cut leaves a part you can understand, test, move, and reuse by looking only at the part. A bad cut fuses concerns (selection *and* action, policy *and* mechanism) so the part serves exactly one site and resists every other. Names in a spec are usually examples of instances, not evidence of where to cut. When you cannot name what a part *is* in one phrase without "and," the cut is wrong.\
\
**`[LAW:types-are-the-program]`** — The types *are* the program: not a description of it, not a linter, not a test suite. Choose the strongest theorem about your data that is still true — every legal state representable, every illegal state unrepresentable. Too weak (`any`, bags of optionals, `string` where four enum values are meant) and illegal states slip through, forcing every callsite to defend. Too strong but false (tighter than the domain allows) and the code must lie or break. The exactly-right type is *exactly as expressive as the domain*; state it once and everything downstream is free to assume it. Once the constraints are right, the implementation is residue — the body is forced and writing it is mechanical. So every rough bit in the body is the code asking you to fix a constraint: if the body wants to branch, the type is missing a discriminator; if it wants to guard, an upstream type permits a state it shouldn't; if it needs a comment to explain an invariant, the type didn't encode it. **When implementation feels hard, the constraints are wrong.** Fix the type; do not push through the body. The concrete face of `[FRAMING:representation]`.\
\
## The consequence — what right parts and true types buy\
\
**`[LAW:composability]`** — A part composes when it **does one thing, completely, asking nothing**: it makes a closed promise about a general case, so it can be dropped into any context that wants that one thing and will deliver it with no negotiation. Three failure modes, one test. *Does more than one thing* → the fused part (`colorOddRows`) serves one caller; split it. *Completes only for a particular caller* → the promise secretly depends on facts not in the interface; lift those facts to the seam as values (the inlined `odd` check becomes a `predicate` parameter — `filter(isOdd, rows)`). *Asks for machinery before it will act* → the over-abstraction that can't move until you assemble its config; that is commitment pushed onto callers from the other side. You reach this state by subtraction: each pass removes one thing the part decided on a caller's behalf, until nothing snags. The check for done is not "does it work" or "do tests pass" — it is **does the part I am leaving compose better than the one I found.** Emerges from `[LAW:decomposition]` and `[LAW:types-are-the-program]` done together; neither alone is sufficient, because a perfectly typed part can still be badly cut.\
\
**`[LAW:carrying-cost]`** — Distinguish *intrinsic cost* (to build a thing once) from *carrying cost* (to maintain, extend, work around, and reason about it forever). A part that composes (`[LAW:composability]`) has near-zero carrying cost: it doesn't couple to callers, doesn't constrain future code, and earns its keep across every project needing its shape. So for an engineer building by subtraction the economics invert — more good parts is *cheaper* than fewer, because each lowers the cost of all future work and carries almost nothing. YAGNI is advice about intrinsic cost under the assumption carrying cost is bounded, which holds only for non-composing parts; it speaks about *features* and has nothing to say about *substrate*. Doing it right now is cheaper than continuing wrong, regardless of effort already spent — no matter how far down the wrong road, turn around. The "wrong abstraction is worse than duplication" warning is `[LAW:no-mode-explosion]` in disguise: the cost is caused not by abstracting but by *stretching* one part over shapes it wasn't cut for; the fix is to fork, not to retrofit every caller. The right question for a foundational piece is never "do we need it" but "does it compose, and is its type the strongest true theorem."\
\
## The world faces\
\
**`[LAW:no-ambient-temporal-coupling]`** — Ordering, timing, lifecycle, initialization, cleanup, and re-entry have one explicit owner and are represented as state, data, or capability — never hidden in incidental execution order. Correctness must not depend on sleeps, event-loop ticks, effect order, render timing, "settle" delays, caller sequencing, or in-flight flags unless that scheduler is the named owner. If an operation is only safe after another, encode the phase transition in a typed state machine or route both through the single owner. The time face of `[FRAMING:parts-and-seams]`: a temporal assumption left in folklore is an illegal call order left representable — an instance of `[LAW:types-are-the-program]` in the dimension of sequence.\
\
**`[LAW:effects-at-boundaries]`** — A part either computes or acts on the world (IO, mutation, network, randomness, clock) — never both. Push effects to the edges; keep the interior pure. A pure interior can be reasoned about, tested, and composed in isolation; an effect mixed into logic makes the logic context-dependent and uncomposable, because the part now has an undeclared seam to the world. When an effect appears mid-computation, lift it to the boundary: let the pure core return a *description* of what to do, and perform it at the edge. The world face of `[FRAMING:parts-and-seams]`, and the spatial cousin of `[LAW:no-ambient-temporal-coupling]` — one localizes *where* a part touches the world, the other *when*. The "return a description, not the action" move is `[LAW:dataflow-not-control-flow]` applied to effects.\
\
## The representation corollaries — does the part tell the truth\
\
**`[LAW:one-source-of-truth]`** — Every concept has exactly one authoritative representation; all others are derived and explicitly synchronized. If two representations can diverge, the architecture is broken — find the canonical one, never mint a second. Caches and indexes are derived, never authoritative. An instance of `[FRAMING:representation]`: two things that can disagree are an under-constrained type, since the constraint that they agree is encoded nowhere.\
\
**`[LAW:single-enforcer]`** — Any cross-cutting invariant (auth, validation, serialization) is enforced at exactly one boundary. Duplicate checks across callsites drift; if enforcement already exists, remove the duplicate, never add another. The specialization of `[LAW:one-source-of-truth]` to enforcement — the single enforcer is where the invariant's type lives; every other check is residue from a missing type or a misplaced boundary.\
\
**`[LAW:comments-explain-why-only]`** — Comments explain *why*, never *what*, and rarely *how*. The code is the authoritative description of what it does; prose restating it is a copy that drifts immediately and is never refreshed. Forbidden in comments: enumerations of callers, counts, references to specific lines, variable names, or function names. Remove any you find, without debating exceptions. An instance of `[LAW:one-source-of-truth]`: a what-comment is a manual divergent copy; and if code needed explaining, the shape is wrong — fix the type, don't write the comment.\
\
## The dataflow corollaries — variability lives in values\
\
**`[LAW:dataflow-not-control-flow]`** — Structure mirrors data flow, not control flow. The same operations run in the same order every invocation; variability lives in the *values* (nulls, empty collections, discriminated unions), never in *whether* an operation runs. Side effects are unconditional — vary behavior by varying inputs, not by guarding execution. Most-violated law, because every language defaults to control flow; fight the default. Sharpest diagnostic: if describing the *mechanics* of your solution needs "if," "and," "when," "skip," or "only," variability has leaked into control flow and the solution is almost certainly wrong. An instance of `[LAW:types-are-the-program]`: variability in values is variability the type carries; variability in whether code runs is variability the type cannot constrain.\
\
**`[LAW:one-type-per-behavior]`** — If multiple things have identical behavior, they are instances of one type, not multiple types. Before creating FooA, FooB, FooC, ask what differs besides the name; if "nothing" or "only configuration," make one Foo with instances. An instance of `[LAW:dataflow-not-control-flow]`: the configuration is the value crossing one boundary; the type is the boundary, held fixed.\
\
**`[LAW:no-mode-explosion]`** — New flags and options need a documented cap and an exit plan; the default path stays canonical. An instance of `[LAW:dataflow-not-control-flow]`: prefer variability in values over variability in modes — values flow through a fixed boundary and can be reasoned about, while modes must be enumerated and tested combinatorially.\
\
**`[LAW:no-defensive-null-guards]`** — Null checks are valid only at trust boundaries (external input, network, user data) or where a value explicitly represents optionality. If a value should never be null, make it not-null upstream; don't add a guard that silently skips work. A null guard with no meaningful `else` is control flow in disguise, hiding bugs by skipping instead of failing loudly. If absence is genuine, encode it as a discriminated value handled by exhaustive match, not a check. An instance of `[LAW:dataflow-not-control-flow]`: the guard is the body asking you to lift optionality into the type.\
\
## The boundary corollaries — is this the right part\
\
**`[LAW:locality-or-seam]`** — Changes to X must not force edits in unrelated Y. A missing seam is a missing cut: the change cascades because no boundary carries the variability. Create the interface first; the seam *is* the part boundary. An instance of `[LAW:decomposition]`.\
\
**`[LAW:one-way-deps]`** — Dependency direction is declared. Cycles forbidden; upward calls forbidden. An instance of `[LAW:decomposition]`: a cycle is two parts sharing a hidden third that wants extracting and naming, so both can depend on it cleanly.\
\
**`[LAW:no-shared-mutable-globals]`** — Registries and singletons require a single owner, an explicit API, and documented invariants. An instance of `[LAW:decomposition]` and `[LAW:single-enforcer]`: an unowned global is a part with no real boundary — anything reads, anything writes — and the owner's API is the missing seam made manifest.\
\
## The process corollaries — correctness must be observable\
\
**`[LAW:verifiable-goals]`** — Every planned goal has concrete criteria a deterministic process can check (e.g. "app loads with no warnings or errors in logs"). Exhaust your own verification before asking the user to test — that is the last resort. Where uncertainty remains, ask before proceeding rather than guessing. Wrong: "it's built, now you test it." Right: "I verified it against defined criteria; there are no warnings or errors." An instance of `[LAW:types-are-the-program]`: an unverifiable goal is one whose "done" state has no type — define the shape of success and failure, and verification follows.\
\
**`[LAW:behavior-not-structure]`** — Tests assert *what* (contracts, the meaning of operations), never *how* (implementation). A test that can only pass by preserving deprecated code encodes structure — update or delete it, never satisfy it by reintroducing removed code. An instance of `[LAW:types-are-the-program]`: structure is already enforced by the type system, so a structure-asserting test is miscast; and if a test is the only thing keeping code alive, the type is missing the constraint that should have made the code load-bearing.\
\
**`[LAW:no-silent-failure]`** — Failure must be loud and explicit. Never swallow errors, never fall back silently to a different data source or default that changes meaning. `2>/dev/null`, `|| true`, and silent catches are lies — they send the next agent or human confidently down the wrong path. A fallback that alters the *meaning* of data is a bug that fires only when things are already broken, guaranteeing maximum confusion. If the primary path fails, stop and surface it. An instance of `[FRAMING:representation]`: a swallowed failure misrepresents failure as success, and it defeats `[LAW:verifiable-goals]` by hiding the signal verification depends on.\
\
---\
\
## Summary (recap at recency — verbatim tokens, relationships, no new definitions)\
The story compressed, for reinforcement. Software is `[FRAMING:parts-and-seams]`: parts joined at seams, with four faces — decomposition (the cut), representation (the truth), time, world.\
\
- **Cut the right parts.** `[LAW:decomposition]`, and its boundary corollaries `[LAW:locality-or-seam]`, `[LAW:one-way-deps]`, `[LAW:no-shared-mutable-globals]`.\
- **Make each part true.** `[FRAMING:representation]` → `[LAW:types-are-the-program]`, with `[LAW:one-source-of-truth]`, `[LAW:single-enforcer]`, `[LAW:comments-explain-why-only]` (don't let representations diverge), and `[LAW:dataflow-not-control-flow]`, `[LAW:one-type-per-behavior]`, `[LAW:no-mode-explosion]`, `[LAW:no-defensive-null-guards]` (variability lives in values, not branches).\
- **Mind the world.** `[LAW:no-ambient-temporal-coupling]` (when) and `[LAW:effects-at-boundaries]` (where) keep a part's contact with the outside declared, not scattered.\
- **The payoff.** Right parts + true types compose: `[LAW:composability]` — does one thing, completely, asking nothing — and composing parts have near-zero `[LAW:carrying-cost]`, which is why building more of them is cheaper than building fewer.\
- **Stay honest.** `[LAW:verifiable-goals]`, `[LAW:behavior-not-structure]`, `[LAW:no-silent-failure]` keep correctness observable.\
\
When in doubt, return to the root: design the parts and their seams so the parts compose; the body is residue.\
</universal-laws>\
```\
\
Four things I changed or pulled that you should know about, since you'll be deleting the originals:\
\
I promoted `[LAW:no-silent-failure]` into the set. The concept was split across the `<errors>` guideline ("no silent fallbacks") and the whole `<scripting-discipline>` section — a genuine divergence with two homes and no canonical one. It's unconditional and universal, so it earns a law; the scripting-discipline section can become examples that cite it rather than re-stating it.\
\
I folded the `<on-conditionals>` rule (if/and/when/skip/only → wrong) into `[LAW:dataflow-not-control-flow]` as its diagnostic, and the "make it impossible / compile-time > runtime > documentation > hope" line from `<abstractions>` into `[FRAMING:representation]`. The render-target worked example in `<on-conditionals>` should stay where it is but open by citing `[LAW:dataflow-not-control-flow]` verbatim so it binds.\
\
`smooth-blocks` is gone as a token — dissolved into `[LAW:composability]` (the property + the subtraction method + the done-check) and `[LAW:decomposition]` (the cut). The metaphor is fully excised.\
\
Demotion candidates I'd flag rather than act on, since you said you'll handle it: `[LAW:no-shared-mutable-globals]` and `[LAW:no-defensive-null-guards]` are the two that most read as specializations rather than peers — both are concrete and frequently-violated enough that I kept them as laws, but if the set needs tightening they're the first I'd move to guidelines without much loss, since the families above them carry the principle. Everything else I think holds its weight.\
\
\
\