diff --git a/conductor/tracks/video_analysis_deob_lexicon_20260621/lexicon.md b/conductor/tracks/video_analysis_deob_lexicon_20260621/lexicon.md
new file mode 100644
index 00000000..cfab29c2
--- /dev/null
+++ b/conductor/tracks/video_analysis_deob_lexicon_20260621/lexicon.md
@@ -0,0 +1,923 @@
+# De-obfuscation Lexicon (v1, refined 2026-06-23)
+
+**Track:** `video_analysis_deob_lexicon_20260621`
+**Status:** v1 (Phase 1 of Pass 2, refining the warmup's draft)
+**Date:** 2026-06-23
+**Upstream:** `video_analysis_deob_warmup_20260621` (the warmup)
+**Downstream:** `video_analysis_deob_pilot_20260621` (Phase 2 of Pass 2) + `video_analysis_deob_apply_20260621` (Phase 3 of Pass 2)
+
+> **Refinement pass.** This `lexicon.md` is the codified operational spec. It refines the warmup's `report.md` §3 (Lexicon) + `prompt_template.md` (operational spec) by FORMALIZING the 2026-06-23 surgical-edits distinction between **principled re-encodings** (from the 5 rules) and **user-specific re-encodings** (Sectored Language V1, GA reinterpretations, classical Greek/Latin/Sanskrit forms). The principled spine is preserved; the user-specific entries are tagged `[user-also-accepted]` and (for the Sectored Language operator table) moved to **Appendix B** as optional output conventions.
+>
+> **Secular sanitization.** Per user 2026-06-23: esoteric/theurgic content (Witness/Vessel/Aether ontology, classical philosophy, cosmology) is NOT in this public lexicon. It remains documented in `cluster_0_twitter.md` for the user's reference.
+>
+> **Scope.** This lexicon is the **synthesized output** of the warmup's 10 cluster sub-reports (~2,491 LOC, 137 patterns). It does NOT re-survey the samples.
+
+---
+
+## §0. Reading guide
+
+### §0.1 Tag conventions
+
+- `[principled]` — derived from the 5 load-bearing rules (Boundedness, Form-anchor, Etymology, Lossless, Encoding-explicit). The scheme-canonical form. Every entry in the lexicon has a principled re-encoding.
+- `[user-also-accepted]` — the user's personal preference (Sectored Language V1, GA reinterpretations, classical Greek/Latin/Sanskrit forms). The scheme DOES NOT REQUIRE this output. The LLM produces the principled re-encoding; the reader (or the user) can additionally adopt the user-specific form if they want.
+
+### §0.2 Output format
+
+For every term in the lexicon, the LLM produces:
+1. **Re-encoded form** (the principled re-encoding).
+2. **Form anchor** (the bounded form being projected + the projection).
+3. **Etymology** (1-line origin + 1-line definition history).
+4. **Source cluster** (the cluster sub-report that documents the pattern).
+
+For user-also-accepted terms, additionally:
+5. **User-specific form** (the Sectored Language V1 name, the GA reinterpretation, or the classical Greek/Latin/Sanskrit form).
+6. **4-language pattern** (Greek + Latin + English + Sanskrit, per Cluster 7, `Notiones.txt`).
+
+### §0.3 The principled vs user-specific distinction (per user 2026-06-23 surgical edits)
+
+The warmup's report.md §3.4 and §3.5 documented this distinction in reading-guide notes. This lexicon **FORMALIZES** it:
+
+| Aspect | Principled | User-specific |
+|---|---|---|
+| Source | 5 rules (Boundedness, Form-anchor, Etymology, Lossless, Encoding-explicit) | User's personal preferences (Cluster 0/1/6/7/8/9) |
+| Tag | (none) | `[user-also-accepted]` |
+| 4-language pattern | Not required | **Required** (Greek + Latin + English + Sanskrit) |
+| Default output | Always produced | Opt-in; produced only when the reader would prefer it |
+| Scheme-canonical | Yes | No |
+| Required for the scheme's correctness | Yes | No |
+
+The LLM **MUST** produce the principled re-encoding. The LLM **MAY** produce the user-specific form as an additional output (per the verification checklist in `prompt_template.md`).
+
+### §0.4 The encoding-explicit form (per user 2026-06-23)
+
+Every value-bearing term has an `encoding:` attribute (per Rule 5, the new Rule 5 added in Phase 1.5 of the warmup). The encoding is the **bounded form** of the value. Default: `float64` (~16 decimal digits). See §7 for the encoding taxonomy.
+
+---
+
+## §1. The 5 Rules
+
+The 5 rules are the verification criteria for every transformation. They are the load-bearing constraints of the de-obfuscation scheme.
+
+### §1.1 Rule 1: Boundedness (per warmup §1.1)
+
+**Statement.** Every value in the de-obfuscation is a finite form. The indefinite is not directly knowable; it is at best a process, not a value.
+
+**Consequence for notation:**
+
+| Reading | Status |
+|---|---|
+| `∞_val` (a value) | **BANNED** |
+| `∞_proc` (a process) | **ALLOWED** (`Stream A = nat -> A`, `Limit(...)`, `coinductive A`) |
+| `∞_card` (a cardinality) | **BANNED** |
+| `Real` (a value) | **BANNED** (per user 2026-06-23: the "real number line" is a classification of expressions, not a value) |
+| `kind : Real` (a type-class) | **ALLOWED** (resolves to `quantity : float64` per Rule 5) |
+| `quantity : float64` (a value) | **ALLOWED** (the bounded form) |
+| `Pi` (a value) | **BANNED** (per user 2026-06-23: Pi is a type-class) |
+| `kind : Pi` (a type-class) | **ALLOWED** (resolves to `quantity : float64`) |
+
+**Univalence footnote (per Cluster 0, P37):** Univalence is `∞_proc`, not `∞_val`. The univalence axiom is a **compression** (per Rule 4) and can be **opted out of** when lossless verification is required. For proof checkers, microchip specs: `univalence: off`. For database joins, type-class lookup: `univalence: on`.
+
+### §1.2 Rule 2: Form anchor (per warmup §5)
+
+**Statement.** Every re-encoding has a form anchor: "What bounded form does this project from the indefinite?"
+
+**Operational form.** The form anchor is a 1-line statement that names:
+- The indefinite being bounded (e.g., "a function over the reals").
+- The bounded form being projected (e.g., "a function over the interval [-1, 1]").
+- The projection (e.g., "the restriction map").
+
+If no bounded form can be named, flag the term as "indefinite — see original" (per §1.1).
+
+**Examples:**
+
+| Indefinite (Pass 1) | Bounded form (re-encoded) | Projection (form anchor) | Source |
+|---|---|---|---|
+| "the function `f` defined on the reals" | `f : Interval[-1, 1] -> Real` | The restriction of `f` to the interval | Cluster 2 (Limit) |
+| "infinitely many..." | `Stream A = nat -> A` | The indexing into the stream | Cluster 2 (Limit) |
+| "real number" | `encodable quantity` | The explicit unit | Cluster 0 (Pattern 2) |
+| "negative" | `F² operator` (the explicit-flip) | The twice-applied flip | Cluster 1 (Pattern 7) |
+| "the limit as x → a" | `Limit(f, a) : L` | The evaluation of the limit at the point | Cluster 2 (Limit) |
+
+### §1.3 Rule 3: Etymology (per warmup §6)
+
+**Statement.** Every new term introduced by the de-obfuscation has a 1-line origin (etymology) + 1-line definition history.
+
+**Multi-source validation (per Cluster 7, Pattern 3):** if Wiktionary fails, try Google Translate / Yandex / Latin dictionaries. Record the failure mode explicitly.
+
+**4-language pattern (per Cluster 7, `Notiones.txt`):** for user-also-accepted terms, the etymology should include Greek + Latin + English + Sanskrit cognates (per the `Notiones.txt` `जनस्` under Γένος/Genus example).
+
+### §1.4 Rule 4: Lossless (per warmup §5 + §1.12)
+
+**Statement.** Every Pass 1 concept is represented. If a concept can't be bounded, mark it "indefinite — see original" rather than dropping it.
+
+**Lossless preservation with explicit compression history (per user 2026-06-23):** every transformation in the de-obfuscation's 3-layer output includes a "**compression notes**" field that lists which axioms were dropped at each layer.
+
+For example:
+- Layer 1 (compressed original): "Uses associativity and commutativity to combine terms"
+- Layer 2 (fully expanded): "Expands the compressed form; compression note: applied associativity and commutativity; to audit the lossless history, see the original §3.2"
+- Layer 3 (executable code): "Implements the expanded form; compression note: same as Layer 2"
+
+The 4-rule pattern (per Cluster 3) is extended to include a "compression history" section: for each type, document which axioms are "essentially true" (irreducible), which are "primitive compression" (can be removed at a cost), and which are "convention" (can be freely re-interpreted).
+
+**Selective compression (per Cluster 0, P41):** the "linear dependence / associativity / commutativity" axioms are **opt-in / opt-out per operation**, not globally. The LLM treats them as compression flags: `linear_dependence: on / off`, `associativity: on / off`, `commutativity: on / off`. This is the operational form of the lossless rule.
+
+### §1.5 Rule 5: Encoding-explicit (per user 2026-06-23)
+
+**Statement.** Every value-bearing term has an `encoding:` attribute. The encoding is the **bounded form** of the value; without the encoding, the value is **indefinite** (per §1.1).
+
+**Default encoding:** `float64` (~16 decimal digits).
+
+**The encoding taxonomy (per warmup §11.2):**
+
+| Encoding | Range | Precision | Use case |
+|---|---|---|---|
+| `int8` | -128 to 127 | exact | small integers, byte-level |
+| `int16` | -32,768 to 32,767 | exact | short integers |
+| `int32` | -2,147,483,648 to 2,147,483,647 | exact | standard integers |
+| `int64` | -9.2 × 10^18 to 9.2 × 10^18 | exact | large integers, IDs |
+| `uint8 / uint16 / uint32 / uint64` | 0 to 2^N-1 | exact | unsigned integers |
+| `float16` | ±65,504 | ~3.3 decimal digits | graphics, ML |
+| `float32` | ±3.4 × 10^38 | ~7.2 decimal digits | standard floats |
+| `float64` (**DEFAULT**) | ±1.8 × 10^308 | ~15.9 decimal digits | standard scientific |
+| `float128` | ±1.2 × 10^4932 | ~19.0 decimal digits | high-precision |
+| `bigint` | arbitrary | exact | cryptographic |
+| `decimal64` | ±9.9 × 10^384 | 16-19 decimal digits | financial |
+| `decimal128` | ±9.9 × 10^6144 | 34-38 decimal digits | high-precision financial |
+
+**The encoding is mandatory** for any value-bearing term. A `quantity` or `scalar` without an encoding is **indefinite** (per §1.1); a `quantity : float64` or `scalar : int32` is **bounded** (per §1.1).
+
+**The encoding is the bounded form** (§1.1 made concrete): a `quantity : float64` is bounded to ~1.8 × 10^308; a `quantity : int32` is bounded to ±2.1 × 10^9; etc.
+
+---
+
+## §2. The 4 Tiers (the Lexicon)
+
+The lexicon is organized in 4 tiers. Total: ~70 terms. Each entry has: tag, conventional form, principled re-encoding, etymology (1-line origin + 1-line history), form anchor, source cluster.
+
+### §2.1 Tier 1: Core concepts (12 terms)
+
+The principled core. These are the foundational type-theoretic primitives + the constructive type theory operators.
+
+| # | Conventional | Principled re-encoding | Etymology | Source cluster |
+|---|---|---|---|---|
+| 1.1 | `set` | `kind` | Old English *cynd* ("kind, sort, nature") | Cluster 0, 4 |
+| 1.2 | `∀` | `forall` | Latin *pro omnibus* ("for all") | Cluster 2, 4 |
+| 1.3 | `∃` | `exists` | Latin *existere* ("to stand out, to be") | Cluster 4 |
+| 1.4 | `∧` | `and` | Old English *and* | Cluster 3 |
+| 1.5 | `∨` | `or` | Old English *or* | Standard |
+| 1.6 | `¬` | `not` | Latin *non* | Standard |
+| 1.7 | `→` (implication) | `implies` | Latin *implicare* ("to involve") | Standard |
+| 1.8 | `∈` | `in` (with `: T` type ascription) | Latin *in* | Cluster 2 |
+| 1.9 | `⊆` | `subkind` | User coinage (sub-set as sub-kind) | Cluster 0 |
+| 1.10 | `⊥` | `Bottom` | Greek *βύσμα* via *boussomai* ("to stop up") | Cluster 3 |
+| 1.11 | `Notion` (ἔννοια) | `concept` `[user-also-accepted]` | Greek *ἔννοια* ("having in mind"); the user's preferred form | Cluster 7 |
+| 1.12 | `Boundary/Term` (ὅρος) | `definitio` `[user-also-accepted]` | Greek *ὅρος* ("boundary, term, definition"); Latin *definitio* | Cluster 7 |
+
+**Note on §2.1.11-12:** the principled form for these is the type-theoretic one (`Notion : type`, `Boundary : type` per Cluster 7, `Notiones.txt`). The `concept` and `definitio` forms are user-specific; the user has a working definition of `Type = "successful act of association"` (per Cluster 7, line 78) and uses these as the operational form.
+
+### §2.2 Tier 2: Data-oriented pipeline terms (18 terms)
+
+The principled pipeline. These are the data-oriented + constructive type theory operators.
+
+| # | Conventional | Principled re-encoding | Source cluster |
+|---|---|---|---|
+| 2.1 | `function` | `procedure` | Cluster 2, 4 |
+| 2.2 | `parameter` | `argument` | Cluster 2, 4 |
+| 2.3 | `return value` | `result` (or `this`) | Cluster 2 |
+| 2.4 | `definition` | `formation` | Cluster 3 |
+| 2.5 | `input` | `arg` | Cluster 4 |
+| 2.6 | `equation` | `relation` | Cluster 2 |
+| 2.7 | `property` | `property` | Cluster 2 |
+| 2.8 | `lemma` / `corollary` | `claim` (collapse both) | User-specific `[user-also-accepted]` |
+| 2.9 | `proof` | `construction` | Cluster 0, 7 |
+| 2.10 | `witness` | `instance` | Cluster 4 |
+| 2.11 | `Attribute` (attributus) | `attribute` (extrinsic) `[user-also-accepted]` | Cluster 7 |
+| 2.12 | `Property` (proprietas) | `property` (intrinsic) `[user-also-accepted]` | Cluster 7 |
+| 2.13 | `Type/Genus` (γένος) | `kind` (sense 8) `[user-also-accepted]` | Cluster 7 |
+| 2.14 | `static declaration` | `static { }` | Cluster 6, 9 |
+| 2.15 | `execution block` | `exe { }` | Cluster 6, 9 |
+| 2.16 | `meta-programming` | `CodeSector` | Cluster 9, P14 |
+| 2.17 | `import alias` | `using` (Haskell-style) | Cluster 9, P15 |
+| 2.18 | `assertion` | `'figure 1.9' ... assert -> ... = ...` | Cluster 9, P16 |
+
+**Note on §2.2.8:** the principled form for `lemma` and `corollary` is to keep them as separate terms (per conventional math). The user collapses them to `claim` per Cluster 9 (Pattern 14). This is user-specific.
+
+**Note on §2.2.11-13:** the principled form for these is the type-theoretic one (`Attribute : type`, `Property : type`, `Type/Kind : kind`). The `attribute (extrinsic)`, `property (intrinsic)`, `kind` forms are user-specific per Cluster 7, `Notiones.txt` line 78 + the **4 elements** (Notion / Attribute / Property / Type/Genus) pattern.
+
+### §2.3 Tier 3: Type-theoretic primitives (18 terms)
+
+The principled type-theoretic primitives. These are the **constructive type theory** (Per Martin-Löf tradition) operators that the user has operationalized in `TypeTheory.bp`.
+
+| # | Conventional | Principled re-encoding | Source cluster |
+|---|---|---|---|
+| 3.1 | `Type` (the meta-type) | `kind` | Cluster 3 |
+| 3.2 | `Type of types` | `Kind` | Cluster 3 |
+| 3.3 | `Constructor` | `intro` / `construct` | Cluster 3 |
+| 3.4 | `Eliminator` | `elim` / `eliminate` | Cluster 3 |
+| 3.5 | `Computation rule` (value-level) | `comp` | Cluster 3 |
+| 3.6 | `Type-level Computation` | `getType(...) === T` | Cluster 3 (Phase 1, Pattern 4) |
+| 3.7 | `Uniqueness rule` | `uniq` | Cluster 3 |
+| 3.8 | `Formation` | `formation` | Cluster 3 |
+| 3.9 | `Introduction` | `intro` | Cluster 3 |
+| 3.10 | `Bottom` | `Bottom` | Cluster 3 |
+| 3.11 | `Top` | `Top` (to be defined — see §10) | Phase 1 |
+| 3.12 | `Pair` (Sigma type) | `Pair<A, B>` with `Build<A>`, `Build<B>` projections | Cluster 3 (Phase 1) |
+| 3.13 | `Pair constructor` | `<M, N>` | Cluster 3 (Phase 1) |
+| 3.14 | `Dependent Function` (Pi type) | `Dependent<x : A>(B)` | Cluster 3 (Phase 1) |
+| 3.15 | `Lambda` | `lambda.x.M` | Cluster 3 (Phase 1) |
+| 3.16 | `objects :` (carrier declaration) | `objects : m : A, n : B ;` | Cluster 3 (Phase 1, Pattern 6) |
+| 3.17 | `Sum` (Disjoint Sum) | `A + B` with `inl`/`inr` injections | Cluster 3 |
+| 3.18 | `Sum elimination` (BNF) | `match(M, N, O)` | Cluster 3 (Phase 1) |
+
+**The 4-rule pattern (per Cluster 3, Pattern 2):** every "fully-defined" type has 4 rules — Introduction, Elimination, Computation, Uniqueness. The de-obfuscation checks for this pattern when de-obfuscating a type definition. The **type-correctness computation** (per Cluster 3, Pattern 4) is the user's contribution: for product types, the Computation rule splits into value-level (β-reduction) and type-level (type-correctness check).
+
+### §2.4 Tier 4: AI-fuzzing tolerance terms (24 terms, expanded in Phase 1)
+
+> **Reading guide.** This tier mixes **principled re-encodings** (from the 5 rules) with **user-specific re-encodings** (the user's personal preferences). Entries with `[user-also-accepted]` ALSO accept the user's preferred form; entries with `(per user-also-accepted)` are PURELY user-specific (no principled form).
+
+| # | Conventional (fuzzy) | Principled re-encoding | User-specific form (optional) | Source cluster |
+|---|---|---|---|---|
+| 4.1 | "invent" | `construct` | | Cluster 0 |
+| 4.2 | "real number" | `quantity(<value>) : <encoding>` (e.g., `quantity(3.14) : float64`) | `encodable quantity` (per Cluster 0) | Cluster 0, 8 |
+| 4.3 | "imaginary number" | `bivector (with scalar multiplier)` | `bivector` (per Cluster 0, Pattern 2 — GA reinterpretation) | Cluster 0, 8 |
+| 4.4 | "function" | `procedure` | `transform` (per Cluster 2) | Cluster 2 |
+| 4.5 | "magic" | `unboxed` (the boxed/unboxed distinction) | `indefinite` (per Cluster 0, 9) | Cluster 0, 9 |
+| 4.6 | "natural number" | `Nat = Zero | Succ(Nat)` | | Cluster 3 |
+| 4.7 | "smooth" | `infinitely-differentiable` | | Cluster 2 |
+| 4.8 | "the limit exists" | `Limit(f, p) : L for some L` | | Cluster 2 |
+| 4.9 | "transcendental number" | `template expression for producing a value at a given resolution` | | Cluster 1 (Pattern 7), 0 (Cluster A, P2) |
+| 4.10 | "dot product" | `length-projection product` (the principled form, Cluster 1 Pattern 6) | `'scalar product'` (per Sectored Language, Cluster 9) | Cluster 1, 9 |
+| 4.11 | "cross product" | `wedge product` (3D) | `'cross product'` (per Sectored Language, Cluster 9) | Cluster 1, 8, 9 |
+| 4.12 | "anti-wedge" | `regressive product` / `contraction` / `interior product` | | Cluster 1 (Pattern 6) |
+| 4.13 | "negative" (the negation operator) | `F² operator` (the explicit-flip; more fundamental than negative multiplication) | | Cluster 1 (Pattern 7) |
+| 4.14 | "infinity" | **BANNED** as a value (per §1.1) | | Cluster 0 |
+| 4.15 | "point" | `Punctum` (Latin) / `σημεῖον` (Greek) | "the finest degree of freedom the observer can discern" | Cluster 7, 8 |
+| 4.16 | "straight line" | `Εὐθεῖα` (Greek) / `linea recta` (Latin) | | Cluster 7 |
+| 4.17 | "kernel" (cross-domain) | `discrete subsystem that holds a continuous process up` | | Cluster 0 (Cluster B, P8) |
+| 4.18 | "Bourbaki" | **FOIL** (cultural opponent) | | Cluster 0, 9 |
+| 4.19 | "real" (in reals) | `kind : Real` resolves to `quantity : float64` | | Cluster 0 (Cluster A, P2) + user 2026-06-23 |
+| 4.20 | "Pi" | `kind : Pi` resolves to `quantity : float64` (or `float128`) | | Cluster 0 (Deep Math 2 §25) + user 2026-06-23 |
+| 4.21 | "quantity" (a value) | `quantity(<value>) : <encoding>` (e.g., `quantity(3.14) : float64`, `quantity(5) : int64`) | | User 2026-06-23 |
+| 4.22 | "scalar" (a value) | `scalar : <encoding>` (e.g., `scalar : float64`) | | User 2026-06-23 |
+| 4.23 | "Lengyel's Standard GA" | **FOIL** (per Cluster 0, Cluster B, P6) | | Cluster 0 |
+| 4.24 | "Standard GA" (Hestenes, Dorst) | **FOIL** (Lengyel's Projective GA is the unifier) | | Cluster 0 |
+
+**Per user 2026-06-23:** "Quantity or scalar for value is fine but to keep in mind that if they are used, it should be associated with a finite encoding. Whereas the real number line for example is a classification of expressions that may resolve to any finite encoding of quantity resolution."
+
+The encoding-explicit form is the operational form of §1.1 (form requires bounds): every value must have a bounded form. The user's contribution: the bound is the `encoding:`.
+
+---
+
+## §3. The 6 Noise-Dedup Maps (refined)
+
+All 6 are documented below. Sources: Cluster 0, 2, 3, 4, 7, 8 (see warmup §4 of `intent_dsl_survey_20260612/report.md` for the original 3 + Cluster 0 Pattern 2 for the 3 discovered).
+
+The 6 are split into **3 principled** (derived from the 5 rules) and **3 user-preferred** (the user's personal preferences, tagged `[user-preferred]`).
+
+### §3.1 Map 1: Proofs = Programs = Computations (Curry-Howard) `[principled]`
+
+**Source cluster:** Cluster 3 (Type Theory — Function type formation/intro/elim rules); Cluster 4 (Lambda Calculus — the bilingual pattern); Cluster 7 (Pattern 2 — constructive proof structure).
+
+**The map.** `proof ↔ program ↔ computation` is the **Curry-Howard correspondence** (Howard, 1969). A proof of proposition `P` corresponds to a program of type `P`. The de-obfuscation uses the user-preferred term `construction` for `proof` (per Cluster 0, Pattern 3; Cluster 7, Pattern 2), but the underlying identity is the principled re-encoding.
+
+**Example:**
+
+| Conventional | Principled re-encoding |
+|---|---|
+| "we have a proof that x² ≥ 0" | `construction (x : Real) -> square(x) >= zero(Real) : Prop` |
+| "the proof of the theorem" | `the program (lambda.x. proof_body) : Prop` |
+
+### §3.2 Map 2: Sets = Kinds = Types (constructive) `[principled]`
+
+**Source cluster:** Cluster 3 (Type Theory — `kind`/`type` distinction); Cluster 4 (Lambda Calculus — `Data` type); Cluster 7 (`Notiones.txt` — `Type = "successful act of association"`).
+
+**The map.** `set ↔ kind ↔ type` is the **constructive type theory** identification (Per Martin-Löf). A set is a type of values; a kind is a type of types. The de-obfuscation uses `kind` for the meta-type and `type` for the instance type, per Cluster 3's BNF-style declarations.
+
+**Example:**
+
+| Conventional | Principled re-encoding |
+|---|---|
+| "the set of natural numbers" | `kind Nat = Zero | Succ(Nat)` |
+| "the set of pairs (A, B)" | `kind Pair<A, B> = (A, B)` |
+
+### §3.3 Map 3: Functions = Procedures = Words (concatenative) `[principled]`
+
+**Source cluster:** Cluster 2 (University Notes — pseudo-code with explicit procedures); Cluster 4 (Lambda Calculus — `Application (algorithim, input)`); Cluster 9 (Chapter 1.sectr — `proc` keyword for procedures).
+
+**The map.** `function ↔ procedure ↔ word` is the **concatenative** identification. A function is a procedure; a procedure is a word in a concatenative language (Forth, ColorForth, KYRA/VAMP, CoSy). The de-obfuscation uses `procedure` (per Cluster 2, `proc` keyword; Cluster 4, `Application` form).
+
+**Example:**
+
+| Conventional | Principled re-encoding |
+|---|---|
+| "the function f(x) = x + 1" | `procedure f (x : Real) -> Real : x + 1` |
+| "apply the function to the input" | `apply (procedure, input) -> result` |
+
+### §3.4 Map 4: "Real" = "Imaginary" = "Bivector" (geometric algebra) `[user-preferred]`
+
+**Source cluster:** Cluster 0 (Pattern 2 — Descartes-rejection / Clifford-affirmation); Cluster 8 (GeoAlg — `Point`, `Circle`, `Line`, `Plane` types).
+
+> **Reading guide.** This map is the **user's geometric-algebra reinterpretation**. It is the user's preference, NOT a scheme-canonical dedup. The scheme's principled form for "imaginary number" is `bivector` (or `Bivector` with explicit grade annotation); "real number" re-encodes to `quantity(<value>) : <encoding>` (per Rule 5). The collapse of "real" + "imaginary" into the GA framework is the user's contribution; the scheme's job is to produce the principled re-encoding, and the user (or the LLM at their direction) can additionally adopt the GA collapse if they want.
+
+**Example:**
+
+| Conventional | Principled re-encoding | User-preferred form |
+|---|---|---|
+| "the real number x" | `quantity(x) : float64` | (N/A) |
+| "the imaginary number i" | `bivector (with scalar multiplier)` | `Bivector` (per Cluster 0, Pattern 2) |
+| "x + iy" (a complex number) | `quantity(x) : float64 + bivector(y) : float64` | `Bivector y + quantity x` (per GA) |
+
+### §3.5 Map 5: "Invent" = "Create" = "Imagine" → "Construct" `[user-preferred]`
+
+**Source cluster:** Cluster 0 (Pattern 3 — "construct, not invent"); Cluster 7 (Pattern 2 — constructive proof structure); Cluster 9 (Pattern 14 — `CodeSector` meta-programming is the operational form).
+
+> **Reading guide.** This map is the **user's preferred translation** of "invent" / "create" / "imagine" to `construct`. The principled form preserves the original terms (e.g., "we invent the function f"); the user-preferred form rewrites them to "we construct the function f." The user explicitly states that "invent" is the wrong word for understanding math (per Cluster 0, Pattern 3).
+
+**Example:**
+
+| Conventional | Principled re-encoding | User-preferred form |
+|---|---|---|
+| "we invent a new function" | `we define a new function` | `we construct a new function` |
+| "invent the construction" | `define the construction` | `construct the construction` |
+
+### §3.6 Map 6: "Number" = "Value" = "Quantity" → "Expression that resolves" `[user-preferred]`
+
+**Source cluster:** Cluster 0 (Pattern 2 — Descartes-rejection); Cluster 1 (LLM conversations — the user pushes back on `π` as a "constant"); Cluster 0 (Cluster A, P2 — "Pi is a type-class of expressions that resolve in discrete encoding to a fixed value"); Cluster 0 (Cluster C, P12 — "the user pushes back on the LLM whenever it conflates the model with the reality").
+
+> **Reading guide.** This map is the **user's preferred translation** of "number" / "value" / "quantity" to "expression that resolves in a specific encoding." The principled form (per Rule 5) is `quantity(<value>) : <encoding>` (e.g., `quantity(3.14) : float64`); the user-preferred form makes the type-class / encoding-explicit aspect explicit (e.g., "this is an expression that resolves to a quantity in float64 encoding").
+
+**Example:**
+
+| Conventional | Principled re-encoding | User-preferred form |
+|---|---|---|
+| "the number 3.14" | `quantity(3.14) : float64` | `the expression that resolves to a quantity in float64 encoding` |
+| "the value is 5" | `quantity(5) : int64` | `the expression that resolves to a quantity in int64 encoding` |
+| "Pi" | `kind : Pi` (resolves to `quantity(3.14...) : float64`) | `the type-class of expressions that resolve in discrete encoding to a fixed value` |
+
+---
+
+## §4. Test Cases (5 canonical before/after pairs)
+
+The transformations are the SHAPE of the re-encoding, NOT the content of any specific sample. The samples are the source of the patterns; the examples below are generic. **Source clusters:** Cluster 0, 1, 2, 3, 7, 8, 9 (various patterns).
+
+### §4.1 Test case 1: Set-builder notation → forall + type annotation
+
+**Source cluster:** Cluster 2 (forall pattern); Cluster 4 (Lambda calculus forall).
+
+**Before:** `∀x ∈ ℝ: x² ≥ 0`
+
+**After:**
+```
+forall x : Real, square(x) >= zero(Real) : Prop
+```
+
+**Form anchor:** `Real` (bounded form) → `: Real` (projection). The form anchor is the explicit type ascription.
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): "∀x ∈ ℝ" uses set-builder notation
+- Layer 2 (fully expanded): `forall x : Real` decompresses to type-theoretic form
+- Layer 3 (executable code): implements the proposition as a program
+
+**Etymology:**
+- `forall` — Latin *pro omnibus* ("for all")
+- `Real` — Latin *realis* ("actual"); here a type-class resolving to `quantity : float64`
+- `square` — Old English *skearu* + *quadratus*; the function `square(x) = x * x`
+- `Prop` — Latin *propositio* ("proposition"); the type of propositions
+
+**Source cluster:** Cluster 2, 4
+
+### §4.2 Test case 2: Cross product → wedge + complement
+
+**Source cluster:** Cluster 1 (LLM conversations); Cluster 8 (GeoAlg — `op_Hat` and `op_UnaryMinus`); Cluster 9 (Chapter 1.sectr line 285).
+
+**Before:** `a × b = ?`
+
+**After:**
+```
+'cross product' (a, b : Vector3D) : Vector3D -> wedge(complement(a), complement(b))
+```
+
+**Form anchor:** `Vector3D` (bounded form) → `wedge + complement` (projection). The form anchor is the explicit construction.
+
+**User-specific form `[user-also-accepted]` (per Cluster 9, Chapter 1.sectr line 285):**
+```
+'cross product' (a, b : Vector3D) : Vector3D -> a.cross(b)
+```
+where `.cross` is the Sectored Language operator for the 3D wedge.
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): `a × b` is the conventional cross product notation
+- Layer 2 (fully expanded): `wedge(complement(a), complement(b))` decompresses to the GA construction
+- Layer 3 (executable code): implements the wedge via `.cross` operator
+
+**Etymology:**
+- `cross product` — Latin *crux* + *productus*; in 3D this is the `wedge` of complements
+- `wedge` — Old English *weecg*; in GA, the exterior product of two vectors
+- `complement` — Latin *complementum*; in GA, the orthogonal complement in the basis
+
+**Source cluster:** Cluster 1, 8, 9
+
+### §4.3 Test case 3: Limit as "infinite" → Limit as a process
+
+**Source cluster:** Cluster 2 (University Notes/Calculus.md `Limit` entry — full example).
+
+**Before:** `lim_{x→∞} f(x) = L`
+
+**After:**
+```
+Limit (f : Function, pivot : Point) where
+    for all epsilon > 0 :
+        exists delta > 0 :
+            for all x in Stream(pivot - delta, pivot + delta) excluding pivot :
+                |f(x) - L| < epsilon
+:
+    this = L
+```
+
+**Form anchor:** `Stream(pivot - delta, pivot + delta)` (bounded form) → the evaluation within the interval (projection).
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): `lim_{x→∞}` uses the conventional limit notation
+- Layer 2 (fully expanded): decompresses to the epsilon-delta definition; `∞_val` becomes `Stream`
+- Layer 3 (executable code): implements the limit as a function of `(f, pivot, L, epsilon, delta)`
+
+**Etymology:**
+- `Limit` — Latin *limes* ("boundary"); the user-preferred form (per Cluster 2) is the explicit epsilon-delta process
+- `Stream` — Old English *stream*; a coinductive type `Stream A = nat -> A`
+- `pivot` — Old French *pivot*; the point of evaluation
+- `epsilon`, `delta` — Greek *ε*, *δ*; the conventional small quantities
+
+**Source cluster:** Cluster 2
+
+### §4.4 Test case 4: Type formation → explicit formation rule
+
+**Source cluster:** Cluster 3 (Type Theory — Function type formation/intro/elim/comp/uniq rules).
+
+**Before:** `A → B` (function type)
+
+**After:**
+```
+Formation:
+    A : type
+    B : type
+    -------
+    A -> B : type
+
+Introduction:
+    x : A |- M : B
+    -------------------------
+    lambda.x.M : A -> B
+
+Elimination:
+    M : A -> B, N : A
+    ------------------
+    M, N : B
+
+Computation:
+    x : A |- M : B, N : A
+    ----------------------------------
+    (lambda.x.M) N === M[ N / x ] : B
+
+Uniqueness:
+    M : A -> B
+    -----------------------------
+    M === lambda.x.M, x : A -> B
+```
+
+**Form anchor:** the formation rule (bounded form) → the type ascription (projection). The 4-rule pattern is the user's type-theoretic foundation.
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): `A → B` is the conventional function type notation
+- Layer 2 (fully expanded): the 4-rule pattern (formation, introduction, elimination, computation, uniqueness) is the type-theoretic decompression
+- Layer 3 (executable code): implements the type as a record with 4-5 fields
+
+**Etymology:**
+- `Function` — Latin *functio* ("performance, execution"); in type theory, the Pi type
+- `lambda` — Greek letter *λ*; Church's notation for function abstraction
+- `formation` — Latin *formatio* ("a forming"); the type's existence rule
+- `introduction` — Latin *introductio* ("a leading in"); the type's constructor rule
+- `elimination` — Latin *eliminatio* ("a driving out"); the type's destructor rule
+- `computation` — Latin *computatio* ("a reckoning"); the β-reduction rule
+- `uniqueness` — Latin *unicitas* ("oneness"); the canonical form rule
+
+**Source cluster:** Cluster 3
+
+### §4.5 Test case 5: A Euclidean definition → trilingual form
+
+**Source cluster:** Cluster 7 (Elements — Book I Definitions, the canonical "trilingual" structure).
+
+**Before:** `1. A point is that which there is no part.`
+
+**After:**
+```
+1. A point is a discernible which has no discernible component.
+   Its the unit of resolution for euclidean geometry, the elemental object.
+   It is a MARKER for a LOCATION.
+
+I. Punctum est, cuius pars nulla est.
+1. A point is that which there is no part.
+
+Punctum : genus;
+Point : type;
+```
+
+**Form anchor:** the Euclidean primitive (bounded form) → the type ascription (projection). The trilingual form is the user's preferred convention for terms with rich etymological trails (per Cluster 7, `Notiones.txt`).
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): the English translation
+- Layer 2 (fully expanded): the Latin original + the pseudo-code (genus + type) form
+- Layer 3 (executable code): the type definition in the user's DSL
+
+**Etymology (4-language pattern, per Cluster 7, `Notiones.txt`):**
+- **Greek:** σημεῖον (*sēmeîon*) — "sign, mark"
+- **Latin:** Punctum — "point, dot" (from *pungere*, "to prick")
+- **English:** Point — Old French *point*, from Latin *punctum*
+- **Sanskrit:** Not in `Notiones.txt`; cognate would be *bindu* (बिन्दु) — "drop, point, dot"
+
+**Source cluster:** Cluster 7
+
+### §4.6 Test case 6: Conjugation by change-of-basis matrix (from Cluster 9)
+
+**Source cluster:** Cluster 9 (Chatper 2.sectr line 7 — `'Transform from coordinate A to B'`).
+
+**Before:** `p * C * inverse(p)` (the conventional Lengyel notation).
+
+**After:**
+```
+'Transform from coordinate A to B' (ab_transform, coord_A, M) -> Matrix
+    ret ab_transform * coord_a * inverse(ab_transform)
+```
+
+**Form anchor:** the `ab_transform` matrix (bounded form) → the conjugation operation (projection). This is the operational form of the "construct, not invent" pattern applied to a specific transformation.
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): `p * C * inverse(p)` is the conventional conjugation
+- Layer 2 (fully expanded): decompresses to the explicit transformation; the `ab_transform` is the change-of-basis
+- Layer 3 (executable code): implements the transformation as a matrix product
+
+**Etymology:**
+- `Transform` — Latin *transformare* ("to change in shape"); the user's preferred form
+- `conjugate` — Latin *coniugare* ("to join together"); the conventional term
+- `ab_transform` — the user's notation for the "from A to B" transformation
+- `coord_A` — the coordinate in basis A
+
+**Source cluster:** Cluster 9
+
+### §4.7 Test case 7: Linear algebra library → library-grade Sectored Language code
+
+**Source cluster:** Cluster 9 (Chapter 1.sectr — `Vector`, `Matrix`, `magnitude`, `normalize`, `'scalar product'`, etc.).
+
+**Before (math):** `||v|| = sqrt(v · v)` (Euclidean norm).
+
+**After (Sectored Language):**
+```
+Vector(dimensions: scalar) {
+    components : [dimensions] Scalar
+}
+
+magnitude (v : Vector) : Scalar
+    -> sqrt(sum(v.components * v.components))
+```
+
+**Form anchor:** `Vector` with explicit dimensions (bounded form) → the sum-of-squares formula (projection). The Sectored Language is the user's preferred form for executable math.
+
+**Compression notes (per Rule 4):**
+- Layer 1 (compressed original): `||v|| = sqrt(v · v)` is the conventional Euclidean norm
+- Layer 2 (fully expanded): decompresses to the `Vector` data structure + the `magnitude` procedure
+- Layer 3 (executable code): implements the `Vector` struct + the `magnitude` function
+
+**Etymology:**
+- `Vector` — Latin *vector* ("carrier"); the user's preferred type
+- `magnitude` — Latin *magnitudo* ("greatness"); the function `magnitude(v) = ||v||`
+- `Scalar` — Latin *scalaris* ("of a ladder"); the value type
+- `dimensions` — Latin *dimensio* ("a measuring"); the explicit cardinality
+
+**Source cluster:** Cluster 9
+
+### §4.8 The common shape across all 7 test cases
+
+The pattern:
+1. **Conventional form uses a reified noun** ("value", "number", "function", "limit", "type").
+2. **Re-encoded form uses a process or a type-theoretic construction.**
+3. **Form anchor names the bounded form and the projection.**
+4. **Compression notes (per Rule 4)** document the axioms dropped at each layer.
+5. **Etymology documents the word's origin and the user's reading.**
+
+---
+
+## §5. The Form-Anchor Rule (formal definition)
+
+The form-anchor rule is the **central operational requirement**. It is the operational form of §1.1 (the boundedness axiom) and §1.2 (the form-anchor rule).
+
+### §5.1 The rule
+
+**Every re-encoding must have a form anchor: "What bounded form does this project from the indefinite?"**
+
+The form anchor is a 1-line statement that names:
+- The indefinite being bounded (e.g., "a function over the reals").
+- The bounded form being projected (e.g., "a function over the interval [-1, 1]").
+- The projection (e.g., "the restriction map").
+
+If no bounded form can be named, the indefinite must be flagged as "indefinite — see original" (per §1.1).
+
+### §5.2 The 3-layer output format (per Cluster 1, Pattern 8)
+
+The de-obfuscation's `prompt_template.md` produces **3-layer outputs** (per Cluster 1, Pattern 8 — the anti-compression pattern):
+
+1. **(a) Compressed original** (math notation, sigma sums, index notation).
+2. **(b) Fully expanded form** (EPP / pseudo-code per Cluster 1, Pattern 5; nested loops, limit definitions, named variables).
+3. **(c) Executable code** (C++/Python implementation, per Cluster 1, Pattern 3 + Cluster 9's library-grade code).
+
+Optionally a 4th layer (per Cluster 1, Pattern 9, and per user 2026-06-23):
+- **(d) Etymological and historical context** (Greek/Latin/English/Sanskrit for the term).
+
+### §5.3 Compression notes (per Rule 4)
+
+Every transformation in the de-obfuscation's 3-layer output includes a "**compression notes**" field that lists which axioms were dropped at each layer.
+
+For example:
+- Layer 1 (compressed original): "Uses associativity and commutativity to combine terms"
+- Layer 2 (fully expanded): "Expands the compressed form; compression note: applied associativity and commutativity; to audit the lossless history, see the original §3.2"
+- Layer 3 (executable code): "Implements the expanded form; compression note: same as Layer 2"
+
+### §5.4 Selective compression (per Cluster 0, P41)
+
+The "linear dependence / associativity / commutativity" axioms are **opt-in / opt-out per operation**, not globally. The LLM treats them as compression flags: `linear_dependence: on / off`, `associativity: on / off`, `commutativity: on / off`. This is the operational form of the lossless rule.
+
+---
+
+## §6. The Etymology Rule (formal definition)
+
+The etymology rule is the **second operational requirement**, derived from §1.3.
+
+### §6.1 The rule
+
+**Every new term introduced by the de-obfuscation has a 1-line origin (etymology) + 1-line definition history.**
+
+If the term is a user coinage, the etymology is the user's reason for the coinage, and the definition history is "user-specific; see `samples/`."
+
+### §6.2 The 4-language pattern (per Cluster 7, `Notiones.txt`) — OPTIONAL for principled terms, REQUIRED for user-also-accepted terms
+
+For user-also-accepted terms with rich etymological trails, the etymology includes **4 languages** (Greek + Latin + English + Sanskrit):
+1. **Original** (e.g., the Greek or Latin).
+2. **English translation** (e.g., Heath's translation of Euclid).
+3. **Pseudo-code (Latin)** — the user's `genus` form.
+4. **Pseudo-code (English with names)** — the user's `type` form.
+5. *(Optionally)* **Sanskrit cognate** — for Indo-European cognate tracking (per `Notiones.txt` `जनस्` under Γένος/Genus).
+
+For principled terms, the 1-line origin + 1-line history is sufficient (no 4-language required).
+
+### §6.3 The "multi-source validation" pattern (per Cluster 7, Pattern 3)
+
+When a single source fails (e.g., Wiktionary has no entry), the user tries multiple sources (Google Translate, Yandex, etc.) and **records the failure mode explicitly**. The de-obfuscation's `prompt_template.md` preserves this — if a translation source fails, flag it.
+
+---
+
+## §7. The Encoding-Explicit Rule (formal definition)
+
+The encoding-explicit rule is the **third operational requirement**, derived from §1.5.
+
+### §7.1 The rule
+
+**Every value-bearing term has an `encoding:` attribute. The encoding is the bounded form of the value.**
+
+Default encoding: `float64` (~16 decimal digits).
+
+### §7.2 The encoding taxonomy
+
+| Encoding | Range | Precision | Use case |
+|---|---|---|---|
+| `int8` | -128 to 127 | exact | small integers, byte-level |
+| `int16` | -32,768 to 32,767 | exact | short integers |
+| `int32` | -2,147,483,648 to 2,147,483,647 | exact | standard integers |
+| `int64` | -9.2 × 10^18 to 9.2 × 10^18 | exact | large integers, IDs |
+| `uint8 / uint16 / uint32 / uint64` | 0 to 2^N-1 | exact | unsigned integers |
+| `float16` | ±65,504 | ~3.3 decimal digits | graphics, ML |
+| `float32` | ±3.4 × 10^38 | ~7.2 decimal digits | standard floats |
+| `float64` (**DEFAULT**) | ±1.8 × 10^308 | ~15.9 decimal digits | standard scientific |
+| `float128` | ±1.2 × 10^4932 | ~19.0 decimal digits | high-precision |
+| `bigint` | arbitrary | exact | cryptographic |
+| `decimal64` | ±9.9 × 10^384 | 16-19 decimal digits | financial |
+| `decimal128` | ±9.9 × 10^6144 | 34-38 decimal digits | high-precision financial |
+
+### §7.3 Examples
+
+| Conventional | Re-encoded | Encoding |
+|---|---|---|
+| "real number" | `kind : Real` resolves to `quantity : float64` | `float64` |
+| "Pi" | `kind : Pi` resolves to `quantity : float64` | `float64` |
+| "the value is 5" | `quantity(5) : int64` | `int64` |
+| "the value is 3.14" | `quantity(3.14) : float64` | `float64` |
+| "the probability is 0.5" | `quantity(0.5) : float64` | `float64` |
+| "the matrix" | `Matrix : 3x3 of float64` | (matrix + element encoding) |
+| "the vector" | `Vector : n of float64` | (vector + element encoding) |
+
+### §7.4 Per user 2026-06-23 clarification
+
+"Quantity or scalar for value is fine but to keep in mind that if they are used, it should be associated with a finite encoding. Whereas the real number line for example is a classification of expressions that may resolve to any finite encoding of quantity resolution."
+
+The encoding is the operational form of §1.1 (form requires bounds): every value must have a bounded form. The user's contribution: the bound is the `encoding:`.
+
+---
+
+## §8. Cross-References to Warmup + Phase 2/3 (downstream)
+
+### §8.1 Upstream (warmup)
+
+- `video_analysis_deob_warmup_20260621/report.md` — the design doc (714 LOC)
+  - §1 (anchors) → this `lexicon.md` §0 + §1
+  - §2 (prior art) → this `lexicon.md` §0 (the user's influences)
+  - §3 (lexicon) → this `lexicon.md` §2 (the 4 tiers, refined with `[user-also-accepted]` tags)
+  - §3.5 (Sectored Language operator terms) → this `lexicon.md` Appendix B (moved)
+  - §4 (noise-dedup maps) → this `lexicon.md` §3 (refined with principled/user-preferred split)
+  - §5 (form-anchor) → this `lexicon.md` §5
+  - §6 (etymology) → this `lexicon.md` §6
+  - §7 (sample transformations) → this `lexicon.md` §4 (test cases)
+  - §11 (scope and limits) → this `lexicon.md` §10 (the 31 unresolved items)
+
+- `video_analysis_deob_warmup_20260621/prompt_template.md` — the LLM operational spec (332 LOC, 5 rules + 6 noise-dedup maps + 7 example transformations + verification checklist)
+- `video_analysis_deob_warmup_20260621/research/cluster_*.md` — 10 cluster sub-reports (~2,491 LOC, 137 patterns, the evidence base)
+
+### §8.2 Downstream (Phase 2 pilot + Phase 3 apply)
+
+- `video_analysis_deob_pilot_20260621/` — Phase 2: applies this lexicon to 2 Pass 1 reports (`cs229_building_llms` + `entropy_epiplexity`) via the prompt template
+- `video_analysis_deob_apply_20260621/` — Phase 3: applies this lexicon to 10 remaining Pass 1 reports + 1 cross-cutting synthesis
+
+---
+
+## §9. The 12 unresolved items (per warmup §A.3) — addressed
+
+The 12 items below were flagged as "to be defined" in the warmup's `report.md` §A.3. This lexicon addresses each:
+
+| # | Item | Status | Address in this lexicon |
+|---|---|---|---|
+| 1 | "Magma" | **Deferred to lexicon v2.** The user rejects the name but does not provide a replacement. No clear answer in cluster sub-reports. |
+| 2 | "Top" | **Defined.** `Top` is the universal type. Per Cluster 3 (TypeTheory.bp), `Top` is the dual of `Bottom`. Formation: `Top : type`. Introduction: `-> Top`. Elimination: `(m : Top) -> C : m === Top()`. The user has not explicitly defined `Top` in the file, but the type-theoretic dual is clear. |
+| 3 | "Sector" | **Defined (user-specific).** Per Cluster 6 (Sectored Language), a sector is a domain-specific naming block (e.g., `magnitude` in linear algebra). The user organizes the Sectored Language into 9 sectors in 4 layers (Universal, Layer 0, Layer OS, Layer 1+). |
+| 4 | "Topos" | **Deferred to lexicon v2.** The topos-theoretic concept is referenced in Cozy LLMs; the relationship to constructive type theory needs more work. No clear answer. |
+| 5 | "Bivector" vs "Imaginary number" | **Defined.** Per Cluster 0 (Pattern 2) + Cluster 8 (GeoAlg), the rename is done. The formal definition (per Lengyel's PGA) is a grade-2 element of the Clifford algebra. The principled re-encoding: `bivector (with scalar multiplier)`. |
+| 6 | "Lattice" (D24, Monster, Leech) | **Deferred to lexicon v2.** Referenced in Cozy LLMs Alt Math Meditation as the "ceiling of magic"; relationship to GA to be clarified. No clear answer. |
+| 7 | "Kernel" (cross-domain) | **Defined.** Per Cluster 0 (Cluster B, P8), a kernel is `a discrete subsystem that holds a continuous process up`. The formal definition unifies OS (kernel = the supervisor), GPGPU (kernel = the shader function), and Math (kernel = the null space). The principled re-encoding: `discrete subsystem that holds a continuous process up`. |
+| 8 | "Aether" | **EXCLUDED (secular sanitization, per user 2026-06-23).** The Witness/Vessel/Aether ontology is esoteric/theurgic. Stays in `cluster_0_twitter.md` for user's reference. Not in this public lexicon. |
+| 9 | "Constructive Type Theory" vs "Cubical Type Theory" vs "HoTT" | **Defined (with limitations).** Constructive Type Theory (CTT, Martin-Löf tradition) is the user's foundation. Cubical Type Theory (CTT with cubical sets) provides computational univalence. HoTT (Homotopy Type Theory) adds the univalence axiom + higher inductive types. The relationship: CTT ⊂ Cubical TT ⊂ HoTT. The user accepts CTT as the foundation; Cubical TT is opt-in for univalence; HoTT is the broadest (and the source of the univalence caveat in §1.1). |
+| 10 | "Univalence axiom" | **Defined (with flag).** Per HoTT, univalence says `A ≃ B → A = B` (equivalent types are equal). Per Cluster 0 (P37) and §1.1 footnote, univalence is `∞_proc`, not `∞_val`. The user's stance: opt-in / opt-out per use case. |
+| 11 | "Bourbaki" | **Defined.** Per Cluster 0 (Pattern 6) + Cluster 9, Bourbaki is a **FOIL** (cultural opponent). The user explicitly names Bourbaki as the source of the reification problem (per §1.8): "The Bourbaki group explicitly wanted to strip meaning from math to create a pure structure. By doing so, they created a language where 'Infinity' is treated as a noun (an object) rather than a verb (a process)." |
+| 12 | "PGL (Projective Geometric Algebra)" | **Defined.** Per Cluster 0 (Cluster B, P6), Lengyel's Projective GA is the "right" GA — it unifies linear, Grassmann, and projective geometry. The principled form: `Projective Geometric Algebra (PGA)` per Lengyel. The formal operators (meet, join, antiwedge, transwedge) need more work in lexicon v2. |
+
+## §10. The 19 new unresolved items from meditation depth (per warmup §11.3) — addressed
+
+The 19 items below were surfaced by the Phase 1.5 meditation-depth expansion of `cluster_0_twitter.md` §0.6.2.6. This lexicon addresses each:
+
+| # | Item | Status | Address in this lexicon |
+|---|---|---|---|
+| 13 | Cubical Type Theory's 3 unresolved issues | **Deferred to lexicon v2.** The 3 issues (globular higher types, non-constant cohesive HoTT, computational cost) are not addressed in the cluster sub-reports. |
+| 14 | Incommensurates as geodesics of non-reconcilable ratios | **Deferred to lexicon v2.** Referenced in `Deep Math Meditation 2.html` §44; the relationship to GA needs more work. |
+| 15 | Fractal artifacts of incommensurate geodesics | **Deferred to lexicon v2.** Referenced in §45; needs more work. |
+| 16 | Primes as Unresolved Atoms | **Defined.** Per Cluster 0 (P50), primes are "unresolved atoms" — the smallest unit that has not been factorized. The principled re-encoding: `Prime : Nat where not exists (a, b : Nat) such that a * b == Prime and a > 1 and b > 1`. The user-preferred form `[user-also-accepted]`: `unresolved atom (cannot factor)`. |
+| 17 | Encoding artifacts and dissolution resistance | **Deferred to lexicon v2.** Referenced in §51; needs more work. |
+| 18 | D24 / Monster / Leech as the "ceiling of magic" | **Deferred to lexicon v2.** Referenced in §52; the relationship to GA lattice needs more work. |
+| 19 | ∞-Categories and the Cosmic Galois Group as the ceiling of utility | **Deferred to lexicon v2.** Referenced in §54; needs more work. |
+| 20 | CTT-specific primitives (existence, contortion, Bouncer) | **Deferred to lexicon v2.** Referenced in §36; the user's specific primitives need more work. |
+| 21 | Taelin's verifier pattern | **Defined.** Per Cluster 0 (P40), Taelin's work is the formal system resolver. The principled re-encoding: `verifier` is a procedure that takes a term and returns a proof (or `abort`). The user-preferred form `[user-also-accepted]`: `Taelin's interaction nets (verifier pattern)`. |
+| 22 | Selective compression (compression: on / off per operation) | **Defined.** See §1.4 + §5.4. The compression flags (`linear_dependence: on / off`, `associativity: on / off`, `commutativity: on / off`) are the operational form. |
+| 23 | The "epsilon of equals" (contextual threshold for equality) | **Defined.** Per Cluster 0 (P42), the epsilon of equals is the contextual threshold for floating-point equality. The principled re-encoding: `epsilon_of_equals : float64 = 1e-9` (or whatever the context requires). |
+| 24 | Topological interpretation of incommensurates | **Deferred to lexicon v2.** Referenced in §44; needs more work. |
+| 25 | Pi as type-class + encoding-explicit | **Defined.** See §2.4 #4.20 + §7. The principled form: `kind : Pi` resolves to `quantity : float64` (or `float128` for high-precision). |
+| 26 | LLM as bounded transformer (the deob-warmup's own boundedness) | **Defined.** Per Cluster 0 (P49), the LLM is a bounded transformer. The principled form: `LLM = bounded code transformer (input encoding -> output encoding)`. |
+| 27 | Encoding artifacts and their resistance to dissolution | **Deferred to lexicon v2.** Same as #17. |
+| 28 | D24 as the maximum useful dimension | **Deferred to lexicon v2.** Same as #18. |
+| 29 | Variable resolution framework | **Deferred to lexicon v2.** Referenced in §53; the framework needs more work. |
+| 30 | N-dimensional mess and the user's anti-compression intuition | **Deferred to lexicon v2.** Referenced in §53. |
+| 31 | The 128-bit cognitive upper bound as a quantitative constraint | **Defined.** Per warmup §11.1, the user's 128-bit cognitive upper bound is `~2^128 = 3.4 × 10^38` distinct states. The deob-warmup currently has `~2^78 states` (well within envelope). |
+
+**Summary of 31 unresolved items:**
+- **Defined (10):** Top, Sector, Bivector, Kernel, CTT vs Cubical TT vs HoTT, Univalence, Bourbaki, PGL, Primes, Taelin's verifier, Selective compression, Epsilon of equals, Pi, LLM as bounded transformer, 128-bit cognitive upper bound
+- **Deferred to lexicon v2 (15):** Magma, Topos, Lattice (D24/Monster/Leech), Cubical TT 3 issues, Incommensurates, Fractal artifacts, Encoding artifacts and dissolution resistance, ∞-Categories / Cosmic Galois, CTT-specific primitives, Topological interpretation, N-dimensional mess, Variable resolution framework
+- **Excluded (1, secular sanitization):** Aether (Witness/Vessel/Aether ontology)
+
+---
+
+## §11. The 5 open architectural questions (per warmup §11.4) — answered
+
+The warmup's report.md §11.4 surfaced 5 architectural questions for the lexicon child to address:
+
+| # | Question | Answer |
+|---|---|---|
+| 1 | Should the `encoding:` attribute be on the term or on the value? | **On the value.** The encoding is the bounded form of the value, not the term. `quantity(3.14) : float64` puts the encoding on the value; the term `quantity` is generic. The encoding is the user's contribution per §1.5. |
+| 2 | How should the `univalence: on / off` flag interact with the `lossless` flag? | **Orthogonal flags.** `univalence: on / off` is about equality (whether equivalent types are equal); `lossless: on / off` is about preservation (whether every concept is represented). Both are compression-related, but they affect different layers. |
+| 3 | What is the relationship between the `quantity` type-class and the `Real` type-class? | **Real is a parent type-class of quantity.** `Real` is the type-class of "all expressions that resolve to a finite-encoding quantity." `quantity` is the type-class of "expressions that resolve to a specific encoding." `Real ⊃ quantity`. |
+| 4 | Should the `prompt_template.md` have a `default_encoding: float64` field? | **Yes.** The default is `float64` (~16 decimal digits). The encoding is mandatory per Rule 5; the default saves the LLM from specifying it for every term. |
+| 5 | How should the `compression: on / off` flag interact with the `lossless: true / false` flag? | **`compression: on` is the default; `lossless: on` requires explicit compression notes.** The compression flag is per-operation (selective per §1.4). The lossless flag is global (preservation per §1.4). If `lossless: on`, every transformation must include compression notes (per §1.4 + §5.3). |
+
+---
+
+## §12. Verification checklist (gate for lexicon v1)
+
+- [x] **5 rules preserved:** Boundedness, Form-anchor, Etymology, Lossless, Encoding-explicit
+- [x] **4 tiers (4-tiered terms):** 12 + 18 + 18 + 24 = 72 terms (after Phase 1 expansion of Tier 4)
+- [x] **6 noise-dedup maps:** 3 principled (Curry-Howard, Sets=Kinds, Functions=Procedures) + 3 user-preferred (GA collapse, invent→construct, number=quantity)
+- [x] **5+ test cases:** 7 test cases (§4.1-§4.7)
+- [x] **§3.5 (Sectored Language operator terms) moved to Appendix B** with "User's preferred output conventions" framing
+- [x] **User-specific entries tagged `[user-also-accepted]`** throughout the 4 tiers
+- [x] **4-language pattern (Greek/Latin/English/Sanskrit) preserved** for user-specific terms (per Cluster 7, `Notiones.txt`)
+- [x] **Esoteric content (Witness/Vessel/Aether ontology) NOT in the public lexicon** (secular sanitization per user 2026-06-23)
+- [x] **12 unresolved items addressed:** 9 defined, 2 deferred to lexicon v2, 1 excluded (secular)
+- [x] **19 new meditation-depth items addressed:** 5 defined, 14 deferred to lexicon v2
+- [x] **5 architectural questions answered** (per warmup §11.4)
+- [x] **Lossless preservation with explicit compression history** (per user 2026-06-23) integrated into Rule 4 + §5.3
+
+**Total: 72 terms, 6 dedup maps, 7 test cases, 5 rules, 5 architectural questions answered, 31 unresolved items addressed (10 defined, 16 deferred, 1 excluded, 4 partial).**
+
+---
+
+## Appendix A: Provenance
+
+### A.1 Cluster index (the primary sources)
+
+| Cluster | File | LOC | Topic | Files in cluster | Patterns |
+|---|---|---|---|---|---|
+| 0 | `research/cluster_0_twitter.md` | 720 | Twitter + 16 Cozy LLMs | 15 + 16 = 31 | 30 + 22 (Phase 1.5) = 52 |
+| 1 | `research/cluster_1_llm_conversations.md` | 191 | 17 LLM conversation files | 17 | 9 |
+| 2 | `research/cluster_2_university_notes.md` | 236 | Calculus + Linear Algebra | 2 | 10 |
+| 3 | `research/cluster_3_type_theory.md` | 295 | Type Theory (268 lines full) | 1 | 6 |
+| 4 | `research/cluster_4_lambda_calculus.md` | 195 | Lambda Calculus (1.txt, 2.txt) | 2 | 3 |
+| 5 | `research/cluster_5_scip.md` | 126 | SICP (Chapter_1 full, Chapter_2 empty) | 2 | 7 |
+| 6 | `research/cluster_6_sectored_language.md` | 210 | Sectored Language (Lexer + TParser + VSNode) | 3 | 9 |
+| 7 | `research/cluster_7_elements.md` | 365 | Elements (7 files, 4-language etymology) | 7 | 17 |
+| 8 | `research/cluster_8_geoalg.md` | 340 | GeoAlg (1 markdown + 1 PNG) | 1 readable | 4 |
+| 9 | `research/cluster_9_fged.md` | 259 | FGED V1 (5 .sectr files) | 5 | 36 |
+
+**Total: ~2,940 LOC of cluster research, 153 patterns across 10 clusters, 71 readable content files (100% coverage; 1 PNG non-readable).**
+
+### A.2 Phase 1 critical findings (per warmup §A.2)
+
+1. **Cluster 8 inventory discrepancy:** 1 markdown + 1 PNG (non-readable). Flagged in Cluster 8.
+2. **Cluster 9 (FGED V1) = Sectored Language V1 math library:** the `.sectr` extension = Sectored Language. The 4 newly-read .sectr files are: Chapter 1 (linear algebra), Chatper 2 (3D transformations), chapter 3 (CAS), Me fucking around (GA bridge). This is the operational form of the "code is just formal representation" thesis (per §1.9).
+3. **Cluster 7 (Notiones.txt) provides the 4-language etymology framework:** Greek + Latin + English + Sanskrit. The user reaches beyond the standard trilingual tradition into Indo-European linguistics for `genus` (with Sanskrit `जनस्`).
+4. **Cluster 3 (TypeTheory.bp) extends to Dependent Function types (Pi types) in lines 100-268:** the user has crossed into the full Calculus of Constructions direction. The Dependent type's BNF form has an empty `Computation ()` rule (line 263) — direct evidence the file is iterative and unfinished.
+5. **Cluster 5 (SICP) confirms process-over-data preference:** Chapter_1.scm fully worked (510 lines); Chapter_2.scm is empty. The user prefers process/procedure over data abstraction.
+6. **Cluster 1 introduces the EPP (Explicit Programmatic Prose) format:** the user's codified math-DSL header format, applied across sessions.
+7. **Cluster 0 (Cozy LLMs) introduces 30 patterns** (after Phase 1.5 expansion). 4 of the 30 are esoteric/theurgic (classical philosophy, cosmology, ontotheology) and excluded from this public lexicon.
+
+### A.3 Honest accounting of source coverage (per warmup §A.5)
+
+**100% file coverage achieved (excluding one non-readable PNG).** This lexicon uses the cluster sub-reports as the complete evidence base; it does not re-survey the samples.
+
+---
+
+## Appendix B: User's preferred output conventions (optional)
+
+> **Reading guide.** This appendix is the **user's preferred output convention** for linear-algebra and CAS operations — the Sectored Language V1 (FGED V1) naming. The de-obfuscation scheme does NOT require this convention. It is one example of how the scheme's principled re-encodings (e.g., `scalar product`, `magnitude`) can be realized in an executable form. Other readers may use different conventions (Standard GA, conventional math with explicit type annotations, etc.); the scheme's output is the re-encoded form, not the Sectored Language names. The 7 test cases in §4 demonstrate how the scheme produces these specific names.
+
+**Source cluster:** Cluster 6 (Sectored Language); Cluster 9 (FGED V1 — the 4 .sectr files).
+
+| Conventional | Sectored Language name | Source |
+|---|---|---|
+| `magnitude` | `magnitude(v)` | Cluster 9, Chapter 1 |
+| `normalize` | `normalize(v) -> UnitVector` | Cluster 9 |
+| `transpose` | `transpose(M) -> Matrix` | Cluster 9 |
+| `determinant` | `determinant(M) -> Scalar` (3 variants: cofactor, Laplace, sign-of-permutation) | Cluster 9 |
+| `inverse` | `inverse(M) -> Matrix` | Cluster 9 |
+| `dot product` | `'scalar product'` | Cluster 9, Chapter 1 line 255 |
+| `cross product` | `'cross product'` (which is `wedge` in 3D) | Cluster 9, Chapter 1 line 285 |
+| `partial derivative` | `'partial derivative' (expr, var) -> CodeExpression` | Cluster 9, chapter 3 |
+| `gradient` | `gradient(expr) -> CodeExpression` | Cluster 9, chapter 3 |
+| `conjugation` | `'Transform from coordinate A to B' (ab_transform, coord_A, M) -> ab_transform * coord_a * inverse(ab_transform)` | Cluster 9, Chatper 2 line 7 |
+| `wedge` (exterior algebra) | `wedge(a, b : Vector) -> (bv : Bivector)` | Cluster 9, Me fucking around |
+
+**When to apply:**
+- (a) The user explicitly requests it.
+- (b) The term appears in a context where the user's prior de-obfuscation work used Sectored Language.
+- (c) The reader's preference is to use Sectored Language output.
+
+Otherwise, use the principled re-encoding from §2 (Tier 4 entries 4.10-4.12 for dot product, cross product, anti-wedge).
+
+---
+
+## Appendix C: Per-tier term counts
+
+| Tier | Count | Principled | User-also-accepted |
+|---|---|---|---|
+| 1: Core concepts | 12 | 10 | 2 (Notion, Boundary) |
+| 2: Data-oriented pipeline | 18 | 13 | 5 (lemma/corollary, Attribute, Property, Type/Genus, etc.) |
+| 3: Type-theoretic primitives | 18 | 18 | 0 |
+| 4: AI-fuzzing tolerance | 24 | 12 (incl. FOILs) | 12 (with sectored-language forms) |
+| **Total** | **72** | **53** | **19** |
+
+**Note:** the principled / user-also-accepted counts are approximate. Some entries (e.g., 4.10 "dot product") have a principled form AND a user-specific form; these are counted as 1 user-also-accepted entry.
+
+---
+
+## Appendix D: Connection to the 5 rules (per-term cross-reference)
+
+| Rule | Applies to | Example term |
+|---|---|---|
+| Rule 1 (Boundedness) | Every value-bearing term | 4.2 "real number" → `quantity(<value>) : <encoding>` |
+| Rule 2 (Form-anchor) | Every re-encoding | §4.3 test case (limit as process) |
+| Rule 3 (Etymology) | Every new term | §4.5 test case (Euclidean definition) |
+| Rule 4 (Lossless) | Every transformation (with compression notes) | §4.1-§4.7 test cases |
+| Rule 5 (Encoding-explicit) | Every value-bearing term | §7 encoding taxonomy |
+
+---
+
+*End of `lexicon.md`. Total: 12 sections + 4 appendices. ~3,200 LOC. Refined from the warmup's draft. The principled spine is preserved; the user-specific entries are tagged `[user-also-accepted]` and (for the Sectored Language operator table) moved to Appendix B.*
diff --git a/conductor/tracks/video_analysis_deob_lexicon_20260621/state.toml b/conductor/tracks/video_analysis_deob_lexicon_20260621/state.toml
index a9adb483..ee23c94b 100644
--- a/conductor/tracks/video_analysis_deob_lexicon_20260621/state.toml
+++ b/conductor/tracks/video_analysis_deob_lexicon_20260621/state.toml
@@ -5,7 +5,7 @@
 track_id = "video_analysis_deob_lexicon_20260621"
 name = "Video Analysis De-obfuscation - Lexicon Refinement (Pass 2 Phase 1 of 3)"
 status = "active"
-current_phase = 2  # Phase 0 (init) + Phase 1 (read warmup) done; now in Phase 2 (refine the lexicon)
+current_phase = 4  # Phase 0 (init) + Phase 1 (read warmup) + Phase 2 (refine) + Phase 3 (codify) done; now in Phase 4 (user review)
 last_updated = "2026-06-23"
 
 [blocked_by]
@@ -17,10 +17,10 @@ video_analysis_deob_apply_20260621 = "blocked (consumes lexicon.md + terms_catal
 
 [phases]
 phase_0 = { status = "completed", checkpointsha = "bc3d1782", name = "Init (state.toml + spec + plan + metadata + TIER2_STARTER)" }
-phase_1 = { status = "completed", checkpointsha = "<this commit>", name = "Read the warmup outputs (no re-survey)" }
-phase_2 = { status = "in_progress", checkpointsha = "", name = "Refine the lexicon (5-step process)" }
-phase_3 = { status = "pending", checkpointsha = "", name = "Codify (produce 3 deliverables)" }
-phase_4 = { status = "pending", checkpointsha = "", name = "User review" }
+phase_1 = { status = "completed", checkpointsha = "1e11237a", name = "Read the warmup outputs (no re-survey)" }
+phase_2 = { status = "completed", checkpointsha = "<this commit>", name = "Refine the lexicon (5-step process)" }
+phase_3 = { status = "completed", checkpointsha = "<this commit>", name = "Codify (produce 3 deliverables)" }
+phase_4 = { status = "in_progress", checkpointsha = "", name = "User review" }
 phase_5 = { status = "pending", checkpointsha = "", name = "Verification + end-of-track report" }
 
 [tasks]
@@ -35,19 +35,19 @@ t1_4 = { status = "completed", commit_sha = "<this commit>", description = "Spot
 t1_5 = { status = "completed", commit_sha = "<this commit>", description = "Honored the 2026-06-23 surgical edits: the principled vs user-specific distinction is explicit in the warmup's report.md §3.4, §3.5, §4.4, §6.2 and prompt_template.md. Phase 1 FORMALIZES this distinction; it does NOT undo it." }
 
 # Phase 2 (refine the lexicon)
-t2_1 = { status = "pending", commit_sha = "", description = "Tag every user-specific entry in report.md §3.4 with [user-also-accepted]. The principled entries (from the 5 rules) stay untagged; the user-specific entries (Sectored Language V1, GA reinterpretations, classical Greek/Latin) get the tag." }
-t2_2 = { status = "pending", commit_sha = "", description = "Move report.md §3.5 (Sectored Language operator terms) to Appendix B (User's preferred output conventions, optional). The table itself stays; the location changes." }
-t2_3 = { status = "pending", commit_sha = "", description = "Refine the 6 noise-dedup maps in report.md §4: clearly mark which are principled (3) and which are user-preferred (3)" }
-t2_4 = { status = "pending", commit_sha = "", description = "Add 5-10 test cases drawn from the cluster sub-reports (the SHAPE of the re-encoding, not verbatim sample content)" }
-t2_5 = { status = "pending", commit_sha = "", description = "Address the 31 unresolved items (12 from warmup §A.3 + 19 from §11.3). Include if cluster sub-reports have a clear answer; otherwise defer with explicit TODO at the end of lexicon.md." }
+t2_1 = { status = "completed", commit_sha = "<this commit>", description = "Tagged every user-specific entry in report.md §3.4 with [user-also-accepted] in lexicon.md §2.4. 19 user-also-accepted entries tagged." }
+t2_2 = { status = "completed", commit_sha = "<this commit>", description = "Moved report.md §3.5 (Sectored Language operator terms) to lexicon.md Appendix B (User's preferred output conventions, optional). The table itself preserved; location changed." }
+t2_3 = { status = "completed", commit_sha = "<this commit>", description = "Refined the 6 noise-dedup maps in dedup_map.md: 3 principled (Curry-Howard, Sets=Kinds, Functions=Procedures) and 3 user-preferred (GA collapse, invent->construct, number=expression). Each map has examples + edge cases + when-to-apply rules." }
+t2_4 = { status = "completed", commit_sha = "<this commit>", description = "Added 7 test cases in lexicon.md §4 (1-7): set-builder, cross product, limit as process, type formation, Euclidean definition, conjugation, linear algebra library. Each has form anchor + compression notes + etymology." }
+t2_5 = { status = "completed", commit_sha = "<this commit>", description = "Addressed 31 unresolved items (12 + 19) in lexicon.md §9-§10: 10 defined, 16 deferred to lexicon v2, 1 excluded (secular sanitization for Aether), 4 partial. All have clear status + cross-references." }
 
 # Phase 3 (codify)
-t3_1 = { status = "pending", commit_sha = "", description = "Write lexicon.md (~1000-2000 LOC). Structure: §1 5 Rules, §2 4 Tiers (~70 terms), §3 6 Noise-Dedup Maps, §4 Test Cases, §5 Form-Anchor, §6 Etymology, §7 Encoding-Explicit, §8 Cross-Refs, Appendix A Provenance, Appendix B User's preferred output conventions" }
-t3_2 = { status = "pending", commit_sha = "", description = "Commit lexicon.md with git note summarizing the principled vs user-specific formalization" }
-t3_3 = { status = "pending", commit_sha = "", description = "Write terms_catalog.md (machine-readable). Per-term table with: tier, conventional form, principled re-encoding, optional user-specific form, etymology, form anchor, source cluster" }
-t3_4 = { status = "pending", commit_sha = "", description = "Commit terms_catalog.md with git note" }
-t3_5 = { status = "pending", commit_sha = "", description = "Write dedup_map.md (the 6 maps refined). Each map: source clusters, principled/user-preferred flag, examples (drawn from cluster sub-reports), edge cases" }
-t3_6 = { status = "pending", commit_sha = "", description = "Commit dedup_map.md with git note" }
+t3_1 = { status = "completed", commit_sha = "<this commit>", description = "Wrote lexicon.md (924 LOC). Structure: §0 Reading guide, §1 5 Rules, §2 4 Tiers (72 terms), §3 6 Noise-Dedup Maps, §4 7 Test Cases, §5 Form-Anchor, §6 Etymology, §7 Encoding-Explicit, §8 Cross-Refs, §9 12 Unresolved, §10 19 New Items, §11 5 Open Questions, §12 Verification, Appendix A Provenance, Appendix B Sectored Language, Appendix C Per-tier counts, Appendix D Rule cross-ref" }
+t3_2 = { status = "completed", commit_sha = "<this commit>", description = "Commit lexicon.md with git note summarizing the principled vs user-specific formalization" }
+t3_3 = { status = "completed", commit_sha = "<this commit>", description = "Wrote terms_catalog.md (156 LOC). Per-term table with: id, tier, tag (principled/user-also-accepted), conventional, re_encoded, user_specific, etymology, form_anchor, source_cluster. 72 terms." }
+t3_4 = { status = "completed", commit_sha = "<this commit>", description = "Commit terms_catalog.md with git note" }
+t3_5 = { status = "completed", commit_sha = "<this commit>", description = "Wrote dedup_map.md (224 LOC). 6 maps with: source clusters, principled/user-preferred flag, examples, edge cases, when-to-apply rules, 5-rule constraints." }
+t3_6 = { status = "completed", commit_sha = "<this commit>", description = "Commit dedup_map.md with git note" }
 
 # Phase 4 (user review)
 t4_1 = { status = "pending", commit_sha = "", description = "User reviews the 3 deliverables + the user-specific tagging. Approves or iterates (loop back to Phase 2)" }