What the PR description is actually saying

The setting

1. DESIGN_filing_path_decoder_handoff.md §11 — the filing path decoder
2. DESIGN_expression_encoder_future.md §11 — the process-expression encoder (a planned learned encoder for "process expressions," the little DSL strings like e5(routing(e5,haiku,t=[0.02],menus=[10])) that describe composed scoring/routing pipelines)

Part 1 — "Stage A of the filing path decoder"

• SELECT_EXISTING — "file it in this existing folder," where the folder is simply the first eligible candidate in the parent task's frozen ranking order (no re-scoring, no re-ranking), and
• ABSTAIN — with a typed reason code (ambiguous_existing, no_eligible_candidate, resource_censored, …).

• Schemas (filing-path-request.v1, -decision.v1, etc.) — versioned JSON contracts for the request that goes in and the decision receipt that comes out.
• "Parent re-derivation through the landed read_task_file path with an exact QID join" — the request doesn't trust a caller-supplied task summary. It re-reads and re-verifies the original routed-task.v2 file (the "parent"), finds exactly one row with the requested query ID, and derives row_sha256 itself from that canonical row rather than accepting a hash the caller asserts. A request that tries to restake a claim on anything the parent already owns (source, privacy, candidates, ranking, policy — the FORBIDDEN_REQUEST_KEYS set) is rejected outright. This is the "additive layer" principle: Stage A may only add the graph/path supplement, never re-declare inherited authority.
• "Typed folder identity" — folders are identified by a triple (node_type, corpus_or_account, stable_value), never by title. Two folders both named "first" stay distinct; titles are display text, never join keys.
• "Breadcrumbs copied verbatim from frozen principal-path records" — a folder reachable by several graph edges (multi-parent) still displays the one canonical path the catalog recorded. Search reachability ≠ display authority. And the code never generates or "repairs" a path — it copies it or refuses.
• "Dynamic path depth" — no hard-coded slot limit (the tests exercise depth 1, 27, 30, 40).
• "Bounded deterministic scan returning best_so_far" — the scan over candidates has explicit node/step budgets; if it runs out, the receipt reports resource_censored and the deterministic best found so far, never whatever happened to be the last thing examined.
• "Privacy derived from the reverified parent" — privacy class is recomputed from the parent's receipts (public only if both the privacy and catalog policy IDs match the known public policies; otherwise unknown). Sending anything to an external naming service requires a receipt bound to the exact request hash, item content hash, and privacy-receipt hash, unexpired, and policy-enabled. unknown privacy is local-only under all circumstances — no authorization can override an unclassified input.
• "No-replace decision receipts" — decision files are written with no-clobber semantics; a receipt is never silently overwritten. Confirmation re-validates that the catalog and path-record digests haven't changed between recommendation and the user saying yes — and even then authorizes_mutation: False.

Part 2 — "Step 1 of the encoder handoff"

• process_identity.py — the identity contract: a process is identified by sha256(registry_version | canonical_identity_string) as a full 64-hex digest, bound to a factory fingerprint. The existing process_cards.ast_sha keeps its short 16-hex key for caches (P0 behavior unchanged), but handoff artifacts loudly reject the compact form instead of silently accepting a weaker identity. Synthetic (grammar-valid but not executable) samples get bound to an immutable generator_spec_sha256 and can never be "promoted" to deployed identities.
• process_expression_contract.py — freezes three layers: the resolved AST DTO (every registry default and derived KIND/OUTPUT field filled in), complete typed role paths (each token's full root-to-leaf path like ARG(0,process)/KWARG(t,number_list)/LIST_ITEM(0,number), instead of a lossy (depth, index) coordinate), and a reference token stream (structural tags, with literal payloads expanded byte-by-byte as BYTE:0x…).
• PROCESS_EXPRESSION_GOLDEN_v1.json — 18 frozen golden rows covering all 9 registered processes plus edge cases (UTF-8, escapes, pins, negative numbers, variadic args), each recomputable from its expression alone and protected by an overall golden_sha256.

The "Scientific boundaries" section

• PROPOSE_NEW has no reachable code path — _build_decision and validate_decision both raise on it, and require_proposal_authorization demands a calibration artifact fitted on the same population from a prospective naturally-absent cohort (a simulated-absence artifact can only license a labeled, owner-reviewed research pilot).
• A low margin between the top two candidates yields ABSTAIN with an explicit note that it's ambiguity, not evidence a folder is missing — the code never converts it into a "novelty probability."
• Abstention thresholds may only be fitted on inner train/calibration partitions; a policy pointing at outer/test data fails closed at load time.
• Provenance failures raise and produce no decision — they're never laundered into an ordinary abstention.

"Two things the tests recorded rather than assumed"

1. On a real registered process (sonnet-lin-n20), the lossy (depth, breadth) coordinate demonstrably collapses two different positions (t's first list item vs. menus' first list item) into the same coordinate — concrete justification for the complete typed role paths.
2. Registry v0.3 actually caps modifiers at one per node (llm.element.subcat raises ParseError), so MOD(index>0) is schema-legal but currently unreachable — recorded as a test so step 2 measures this limit rather than inheriting it.

"Review focus"

My review

• The fail-closed discipline is remarkably consistent. Every artifact loader re-derives and compares digests (policy_id binds its own content, edge_table_sha256, principal_path_records_sha256, ranking_sha256, decision_sha256, golden_sha256), and every mismatch raises rather than warns.
• The trust boundaries are drawn in exactly the right places: row_sha256 derived not asserted, privacy derived not accepted, candidate order inherited not rebuilt, paths copied not generated. The FORBIDDEN_REQUEST_KEYS rejection is a clean enforcement of the "additive only" contract.
• The circular-hash reasoning around request_sha256 excluding the naming receipt is correct, and there's a test proving the hash is stable across receipt attachment.
• The abstain/block distinction (ordinary hard case → ABSTAIN; provenance fault → raise) is enforced both in code and at the CLI level (exit code 2 with blocked:), so operators can't confuse "we don't know" with "something is forged."
• Tests are genuinely acceptance-grade: they follow the design doc's numbered list, include a hand-written expected token stream (so the fixture constrains the code, not vice versa), test tamper detection by re-binding digests, and assert byte-identical inputs after a decision. The two "recorded not assumed" tests are exactly how design rationale should be pinned down.
• The scope honesty is refreshing: the PR repeatedly states what it does not do, and the CI workflow comments explain why these suites can run in CI while sibling mu_cosine suites can't (numpy + pytest only).

1. ABSTAIN_REASONS is half-dead in Stage A. proposal_need_uncertain, outside_calibration_support, and privacy_restricted_naming are defined and validated but never emitted by any reachable path. That's presumably deliberate headroom for Stages B/C — worth a one-line comment saying so, since a reader will otherwise hunt for the emitters.
2. resource_censored is structurally always False in SELECT_EXISTING receipts. The loop breaks immediately on finding the first eligible candidate, before the budget check can fire — so censoring only ever appears in abstentions. Harmless, but the receipt schema implies a combination that can't occur; a comment or an assertion would document the invariant.
3. check_external_naming's public branch is a pass with a comment — the logic is right (a supplied receipt must still bind the exact request), but restructuring so the public case doesn't flow through the same mandatory-field validation as private would make the intent clearer. As written, a receipt on public data is held to private-data binding rules, which is conservative and fine, just subtly implicit.
4. sys.path.insert in the new modules matches the existing prototype style, so consistent — but if these suites are now in CI, they're one refactor away from import-order fragility. Not for this PR.
5. The PR itself flags the best open question: the allowed_roots → ineligible (abstain) vs. illegal transition → provenance fault (block) split. I think the choice is correct — scope is a caller-supplied narrowing, not a claim about the world, so it shouldn't be treated as forgery — and the tests pin both directions, which is the right way to leave it.
6. The doc nit (the IDENT-00x row for "typed stable ID, never title") is real and cheap to fix; I'd take the author's suggestion rather than let it linger.

Yes — I recommend merging

• #3982 froze the P1 protocol and hardened the P0 parser/registry — this is what gives process_cards its canonical identities and typed signatures that #4000 builds on.
• #3983 captured the encoder/decoder theory as future work, explicitly gated behind P1/P3.
• #3995 converted those sketches into the two implementable handoff documents, with §11 of each naming exactly the first engineering slice.
• #4000 implements precisely those two slices, nothing beyond them, with 166 green tests and all CI green.

On your non-blocking concern — I half agree, and the code supports your instinct more than the presentation does

• The encoder half is already standalone. process_identity.py, process_expression_contract.py, and the golden JSON import only from process_cards — a self-contained module from #3982. No filing imports, no routed_policy, no privacy machinery. The PR even wires it into CI separately with the comment "pure stdlib over process_cards — no embedder, no torch, no corpus." Nothing about bookmark filing is needed to understand or use it. Step 2 (tokenizer/generator) is explicitly scoped to stay that way.
• The filing half is coupled by design, not by accident. Stage A's entire value proposition is "additive over routed-task.v2" — it re-derives the parent through the landed code path precisely so it can't drift into a second authority. Decoupling it from the filing stack would mean reimplementing the provenance primitives (canonical_json_bytes, atomic no-clobber writes, strict JSON), which is the exact "second convention" sin these documents exist to prevent — the same reason the PR asserts full_ast_digest is byte-identical to the P1 protocol's digest rather than minting a new one.

What I'd suggest instead of restructuring (all non-blocking, post-merge)

1. Split future steps into per-workstream PRs. "Stage B of the filing decoder" and "step 2 of the encoder handoff" have no shared code; shipping them separately keeps each review focused. The only reason they're together here is that #3995's two §11s happened to authorize their first steps simultaneously.
2. Add a short reader's guide to the mu_cosine README: the chain #3982 (language + P1 protocol) → #3983 (theory) → #3995 (handoff contracts) → #4000 (first implementation), with a note that the encoder track needs only #3982 as background. That fixes the on-ramp without touching code.
3. Keep the option open to extract the process-expression track later. Because step 1 kept its dependency surface to process_cards alone, pulling process_cards + process_identity + the contract fixtures into a standalone package remains cheap if the encoder work matures — the PR's discipline is what preserves that option.

Verdict: approve — merge once the two in-progress jobs finish green

Verifying each claim against the diff

One small gap worth a follow-up (non-blocking)

On the stated next step

Independent verification of the combinatorics

• 15 source atoms (9 names + allowed modifiers; one modifier max, validator-enforced), plus e5 as a score-atom.
• Only atoms produce source; only e5, margin, e5(…) produce score. Claude's claim that the type system is the binding constraint checks out — kalman/blend/lineage/menu can only consume flat atoms, so they can't recurse.
• The growth driver is e5(process) — process is a wildcard accepting any output type, so e5(e5(routing(…)))-style nesting is the only recursive channel, and it compounds at each depth level.

The two findings are the best part of the answer

My answers to Claude's three questions

1. Caps: depth ≤3, provisional. Depth ≤2 saves compute but drops the single most compositionally interesting real process. Since the downstream ledger doesn't exist yet, "provisional" is the honest label. I'd additionally ask that the node-count cap (≤5) be stated explicitly in the spec — my enumeration shows it's doing as much work as the depth cap.
2. Pins: yes, mandatory, synthetic-only. The golden fixtures already contain a pinned row (…@run/2026-07-25), so the contract already demands tokenizer support; the generator is the only way to supply alignment-side coverage. Allowlisted synthetic/pin-* strings, never real manifest IDs — as Claude proposes.
3. Strings: include them. The golden fixture already freezes UTF-8 and escaped-string rows; shipping a generator that leaves the string byte path untested would contradict the fixture authority that #4000 just established. A small allowlist (one ASCII, one UTF-8, one escaped) is enough — routing.manifest is the only string field.

Two things to watch that Claude didn't mention

• Corpus skew. With e5(process) as the only recursion, the 285k will be dominated by deep e5(…) chains. Ask for per-template / per-depth metric reporting, or the aggregate will mostly measure how well the model encodes nested e5 calls.
• Storage sanity. 285k rows × 384-d float32 teachers ≈ 440 MB per view, ~1.3 GB for three views — fine locally, but worth stating in the spec since it constrains how the vectors are stored and versioned.

1. Enumeration defines the support; it shouldn't define the frequency

• The corpus (what exists): exhaustive enumeration is correct here. It's the frozen contract — it guarantees the tokenizer and decoder are never asked to reconstruct an unseen structure, and it makes the LOCO split meaningful. You can't hold out a template you never enumerated.
• The sampling distribution (what the model sees how often): nothing about exhaustiveness requires uniform frequency. Uniform is a choice, and it's the one you're objecting to — kalman(gpt-5.5-low, gemini) and e5(pick(e5(pick(...)))) are grammar-legal but semantically vacuous, and under uniform sampling they dominate the 285k.

• Weighting must not break the contract. The exhaustive corpus, the template-digest LOCO split, and the golden fixtures stay untouched; weighting lives only in the sampler. Zero weight is never allowed — down-weighting to zero is how assumptions sneak back in as silent exclusions.
• It must be an ablation arm, not an assertion. Uniform vs. distance-weighted, same budget, compared on held-out templates near the witnessed set (that's the distribution production will actually draw from) — if weighting doesn't help there, it goes.

2. "The decoder captures the numerics" — only under conditions that aren't yet guaranteed

1. Digit coverage. This is the sharp one. With the observed-value grid (t ∈ {0.02, 0.03}, menus ∈ {10, 20}, decay 0.85, 0.5), the byte tokens the decoder ever sees for numerics cover digits {0, 1, 2, 3, 5, 8} — 4, 6, 7, 9 never appear in training at all. The tokenizer emits bytes, so an unseen digit byte is an untrained token: ask the decoder to reconstruct decay=0.47 and it must compose glyphs it has literally never seen, in a positional pattern it has never seen. A reversible byte-level tokenizer needs a coverage invariant: every byte value the tokenizer can emit appears in training, in varied positions and magnitudes. That's a measured test, not a prose sentence — and it argues for widening the numeric grid beyond observed values even as structure stays capped.
2. Capacity competition. "Co-trained" doesn't mean "free." Reconstructing digit sequences competes for latent capacity with structure and alignment. §3.3's fixed-Fourier/FiLM numeric channel exists precisely because a generic shared bottleneck tends to allocate poorly for exact numerics. The decoder captures numerics if the numeric path is explicit — the co-training alone doesn't buy it.
3. The alignment path doesn't inherit the fix. Whatever the decoder learns, the e5-alignment head still maps toward teachers that put decay=0.85 and decay=0.5 at cos 0.9725. If downstream retrieval/ranking ever uses the alignment view, numeric distinctions are weak there no matter how well reconstruction works. So the honest statement is: the decoder can own numeric semantics for identity and reconstruction, and the alignment view should be evaluated with numeric distinctions explicitly excluded (or explicitly measured as a known weakness) — recorded before training, not discovered after.

Net effect on the step-2 spec

Likely-distribution first, coverage as the safety net — not the other way round

On exploring numeric encodings — structure it as a preregistered comparison

• Exact channel — guarantees identity. The canonical lexical string (0.85, byte for byte) must round-trip, because the whole identity contract of #4000 rests on canonical bytes. Frequency-encoded features alone can't guarantee this: a Fourier/FiLM representation of a float is smooth and approximately invertible, but "approximately" isn't good enough when the downstream consumer is a SHA-256 of the rendering.
• Smooth channel — carries numeric semantics into the latent. This is where frequency encoding earns its keep: Fourier features are well-established for helping networks represent fine distinctions between nearby scalars (0.85 vs 0.5), which is precisely the capability finding 2 showed e5's teacher lacks.

1. Exact-match reconstruction on the production numeric distribution (weighted — your point);
2. Tail robustness: exact-match on held-out digit/magnitude combinations — and here's the nice part: you can measure generalization directly with a digit-holdout split (train never sees 7, test does; train sees only two decimal places, test sees three). That turns "what might generalize best" from an argument into a measurement, in the same spirit as the template LOCO;
3. Latent numeric sensitivity: does the embedding actually separate decay=0.85 from decay=0.5 — the direct repair target for finding 2.

Anchoring on the current test distribution is the right v1

1. The weighting rule is spec, not training detail. Same status as the caps: versioned, reproducible, with the mass split (e.g., witnessed / 1-edit / floor) stated as numbers a test can reconstruct. If the split is 50/30/20, those numbers were chosen somehow — write down how, even if the honest answer is "initial guess, ablation pending."
2. Keep the floor non-zero. Upweighting to exclusion is the failure mode — the moment a far template gets zero mass, the exhaustive-corpus contract silently shrinks to the neighborhood. The floor is what keeps "generalization later" possible at all.

The caution: don't let the weighting anchor eat the evaluation

• Near slice: held-out templates in the 1-edit neighborhood of witnessed ones — this estimates performance on the distribution production will actually draw from next;
• Far slice: held-out templates far from any witnessed one — this is the canary for whether prioritization is collapsing the tail.

On the later learned weighting

Why decay is the ideal case

The conditions that keep it honest

1. The sweep is a preregistered experiment, not a byproduct. If the decay curve doesn't exist yet as a measurement, it needs its own small protocol: which corpus (digest), which metric, which partition, what grid resolution. A curve read off an ad-hoc run is the numeric version of "descriptive curves treated as calibrated probabilities" — the filing track already has a standing rule about exactly this (RANK-006: descriptive, not calibrated).
2. Provenance travels with the generator spec. The decay distribution is corpus- and metric-dependent — a curve fitted on the pearltrees sample is evidence about that corpus (transductive), and it interacts with graph density, so it may not transfer. Record it the way the filing track records calibration artifacts: fitted-on population, metric, partition, all hash-bound in the generator spec. If the encoder is later used on a different corpus, anyone can see the numeric prior came from elsewhere — the same "outside calibration support" logic #4000 already enforces for proposals.
3. The floor applies here too. The curve says where mass concentrates, not where support ends. Poor-performing decay values still appear at low frequency — the exact-reconstruction channel must handle any legal value, and today's bad decay can be tomorrow's good one on a denser graph. Empirical weighting shapes the smooth channel's priorities; it must never gate the exact channel's coverage.
4. No circularity between fitting and evaluation. The sweep that produces the decay distribution can't also serve as evidence the encoder improves numeric sensitivity — same inner/outer separation as everything else. The sweep is an input; the encoder's numeric evaluation needs its own held-out basis.

The general rule this establishes

The measurement problem is qualitatively different

• Most enumerated structures can't be measured at all right now. That's precisely why #4000's process_identity.py marks grammar-valid samples synthetic_only and refuses promotion without a separately verified factory fingerprint. An effectiveness weighting presupposes executability that the synthetic corpus explicitly doesn't have.
• The evidence base doesn't exist yet. Claude noted the caps are provisional because "the downstream-ledger source doesn't exist yet" — the ledger from the P1 protocol (#3982) is what would eventually produce per-structure effectiveness readings. So effectiveness-weighted structure can't be v1; it's a downstream consumer of the very ladder this encoder is a rung of.

The circularity trap — this one has teeth

The tractable path: features, not templates

Where it lands in the classification

• v1 (now): structure = witnessed anchor + floor. That's the only evidence on file.
• v2 (once the P1/ledger runs land): structural features graduate to measured, with independent-evaluator grading and inner/outer separation between the runs that fit the weights and the runs that evaluate the encoder.
• Per-template effectiveness weighting: probably never, and that's fine — the feature level is where the signal is measurable, and the corpus floor covers the rest.

The preregistration is the weighting signal

One refinement: resolution in the neighborhood, not mass on the point

• Mass on the witnesses themselves — the model memorizes the 9 canonical expressions. Low value: those are already verified; there's nothing left to learn about them.
• Resolution across the perturbation ring — the one- and two-edit neighbors of each witness: swap the source atom, change the threshold, add the distill wrapper, reorder blend args. That ring is where the next verifications live, and it's where encoder sharpness converts directly into experimental signal — the difference between the model cleanly separating e5(routing(e5,sonnet.lineage,…)) from e5(routing(e5,haiku,…)) versus blurring them.

The standing caveat, one last time

Why relaxing exactness is legitimate here

The three consequences

Effect on the arm comparison

PR #4003 review: approve

• All 15 envelope tests pass locally against the PR branch (0.07s, no numpy needed — the CI comment trail stays accurate).
• Independent spot-checks with my own code, not theirs: envelope is exactly depth 3 / 5 nodes / arity 3 / 2 kwargs / 1 mod / 0 pins; digit bytes present are {0,1,2,3,5,8} with 4,6,7,9 genuinely absent; the elision trap is real (parse("lineage(graph,decay=0.85)") drops the kwarg, canonical() restores it — so the first measurement being wrong, and both views now being tests, is exactly right); V2≡V3 holds for all nine registered processes.

The 75% stochastic verification idea — yes, and it's better than a fixed tolerance

1. Verify per field, not per expression. Whole-expression canonical equality is all-or-nothing — one wrong digit in a 120-token row fails the entire verification, giving a very sparse training signal. Verifying each numeric field separately (parse the decoded candidate, compare field values) gives dense signal and matches the per-field tolerance structure we discussed. Integers verify exactly, always — they're exempt from closeness anyway.
2. The 25% still needs a loss. On unverified rows, plain byte cross-entropy would silently re-impose exactness — that was consequence #1 from the closeness discussion. So the full objective is: p × verifier reward + (1−p) × tolerance loss (scalar head or digit-distance-weighted CE). The verifier doesn't replace the closeness loss; it punctuates it.
3. Watch for mode collapse onto common values. If the exact-hit reward is large, the decoder can maximize it by always emitting the most frequent canonical value (0.85 forever) — high verified-exact rate, dead numerics. The guard is already in the spec's metric list: report verified-exact rate alongside latent numeric sensitivity. High exact rate + flat sensitivity = collapse, and seeing both numbers makes it diagnosable rather than mysterious.