docs: §8 fourth-mode refinements — Pillar-11 in-workspace anchor + corrected Passthrough/i8/i4+i2 tier split#244
Conversation
…llar 11; only the ladder->signature mapping stays [S] Follow-up to merged #243 (branch restarted from master). The §8 fourth-mode sentence said the Hambly-Lyons anchor was analogy-grade "until a ladder->signature probe exists" without noting the theorem side already ships in both repos: - THIS repo: src/hpc/pillar/signature.rs (Pillar-11 B7 — signature transform + Hambly-Lyons sig-kernel, Gram-matrix PSD check, certification probe over 1,000 Levy paths). - lance-graph: crates/jc/src/hambly_lyons.rs (Pillar 11, feature hambly-lyons -> sigker; forward/converse probes on signature_truncated). Amended so only the ladder-levels -> signature-levels MAPPING for the residual cascade stays [S], with its probe building on the existing Pillar-11 harnesses. Blackboard note appended. Mirrors lance-graph ec58954 (PR #700). Knowledge-doc suite green (117/117). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
…/ i8 20% / i4+i2 70% Mirrors the codex P2 fix on lance-graph #700: classify_rows_by_lfd sends the hardest ~top-10% LFD rows to Passthrough (exact original stored, no index+residual representation), next ~20% to i8, bottom ~70% to i4+i2. The earlier "i8 for outlier rows" wording was false for the hardest rows. Knowledge-doc suite green (117/117). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_81a3836f-ffa7-4fac-999c-35b59b1c8a21) |
|
Warning Review limit reached
Next review available in: 17 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…urbovec/PolarQuant/helix Mirrors lance-graph 88dcf6b: the fourth-mode paragraph now notes the adaptive codec was engineered before today's lane inventory existed and points at the queued engineering follow-up review (TD-BGZ-TENSOR-PRE-LANE-REVIEW: i4+i2 cascade vs turbovec Lloyd-Max/NativeLut, Hadamard vs PolarQuant rotation findings, residual coding vs helix — consume-the-lane / demarcate / retire). Knowledge-doc suite green (117/117). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d1daecbd9a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ladder→signature probe exists. Canonical text: lance-graph | ||
| cascade up to tree-like equivalence) — **already in-workspace on both | ||
| sides** (corrected 2026-07-16): THIS repo's `src/hpc/pillar/signature.rs` | ||
| (Pillar-11 B7 — signature transform + sig-kernel, Gram PSD check, |
There was a problem hiding this comment.
When this §8 anchor is used to plan the ladder→signature probe, it overstates what the ndarray Pillar-11 harness certifies. The local code does not perform a Gram PSD check: prove_pillar_11 only checks positive self-kernels plus pairwise Cauchy–Schwarz violations on the 50-path subset before marking the report passed (src/hpc/pillar/signature.rs:299-319). Pairwise conditions are not equivalent to checking the Gram matrix is PSD, so downstream docs/probes can rely on proof coverage that is not actually present.
Useful? React with 👍 / 👎.
…signature as trajectory checksum (probe-gated) Follow-up to merged #244 (branch restarted from master). Two candidate adoptions for the Morton-tile stacked inverse pyramid, operator-proposed, recorded [H]/[S] with named probes: - [H] One Walsh-Hadamard family for BOTH pyramid sides: OGAR canon already frames the bipolar-phase pyramid's sign side as the WH transform of the address tree; bgz-tensor's proven hadamard_rotate is the same family on the stored-magnitude side (outlier-flattening preconditioner before cheap uniform quantization). Proposal: WHT16 on a 4x4 tile's magnitude vector before nibble quantization; two-algebra rule untouched (the rotation is a coding-side preconditioner, not a merge mode). PROBE-WH-MAG: WHT16+i4/i2 vs direct i4/i2 on real tile magnitudes — the row-level win does not automatically transfer. - [S] Hambly-Lyons signature as the replayable-trajectory checksum: tree-like equivalence = the digest's exact null space — the formal version of "which detours leave no comma" (the §7 X-Trans/comma framing). PROBE-SIG-CHECKSUM on the existing Pillar-11 harnesses (jc forward/converse + hpc/pillar/signature.rs B7). Neither adds a stored field to the tile. Both stay conditional on the §10 honesty ledger; no kill condition touched. Blackboard entry appended. Knowledge-doc suite green (117/117). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
2 participants
Summary
Small follow-up to the merged #243 (branch restarted from master). Two corrections to the §8 "honourable fourth mode" paragraph, mirroring the lance-graph #700 review round:
src/hpc/pillar/signature.rs(Pillar-11 B7 — signature transform + Hambly–Lyons sig-kernel, Gram-matrix PSD check, certification probe over 1,000 Lévy paths) and lance-graph ships jc Pillar 11 (crates/jc/src/hambly_lyons.rs, featurehambly-lyons→sigker, forward/converse probes onsignature_truncated). Only the ladder-levels → signature-levels mapping for the residual cascade stays [S]; its probe builds on the existing Pillar-11 harnesses.adaptive_codec.rs::classify_rows_by_lfd): the hardest ~top-10% LFD rows escape toPassthrough(exact original stored — no index+residual representation), next ~20% get an i8 residual, bottom ~70% the i4+i2 cascade. The earlier "i8 for outlier rows" wording was false for the hardest rows.Blackboard note appended. Companion: lance-graph #700 (commits
ec58954+67fb9c7).Verification
pillar/signature.rs,jc/src/hambly_lyons.rs,adaptive_codec.rs:97-135).🤖 Generated with Claude Code
https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
Generated by Claude Code