D-DCR-4 consolidation: the ruled entropy atom gets its first consumer - #1154
Conversation
The census (PROBE-ENTROPY-SURFACE-CENSUS-1) licensed exactly one routing, and this is it. `insight::confidence_entropy` drops its own Shannon loop and hands its 10-bin histogram to `contract::thought_atoms::normalized_entropy` — taking that operator-ruled module's consumer count from zero to one. A ruled home with no caller is a vacancy the next session re-implements beside. C1 made this a substitution rather than a hypothesis: the log base is inert under normalization, measured to `0.00000000`, so the caller's and the atom's normalizations are the same function and no tolerance argument is needed. C2 named the one hazard, and it is silent. The caller returns 0.0 for an empty arena; the atom's zero-mass convention is Some(1.0). An empty arena builds an all-zero histogram, so the early return is load-bearing — without it an arena holding no uncertainty reports maximal uncertainty, in range and unremarked. It now says so in its own doc comment and is pinned by `an_empty_arena_has_zero_truth_entropy_not_one`, disable-verified: deleting the guard fails that test and only that test. Its paired can-fire half exists because the guard test is satisfiable by a stub returning 0.0. `the_routed_atom_still_spans_the_confidence_range` asserts full range on non-trivial input and, third, that normalization is by the bin count and not the occupied count — the assertion that would catch a plausible-looking rewrite dividing by however many bins happened to be full. Forms C/D/E are untouched (two live in workspace-excluded crates, so no in-workspace caller can reach them) and F/G deliberately so: C3 measured them moving 92.103409 under a 10x mass scaling and going negative above 1, which means they are not entropies of a distribution. Correcting them is a lab behaviour change and needs its own gate, not this one's. Gates: 411 passed / 0 failed, clippy --all-targets clean, fmt clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
|
Warning Review limit reachedNext included review available in 22 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 85 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (8)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (6)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthrough
ChangesEntropy consolidation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Confidence entropy now uses the shared normalized-entropy implementation while preserving the existing zero result for empty arenas. The documented behavior and range cases are covered, with no current merge-blocking risk identified. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 1 files. (5 skipped: 5 unsupported.) ✨ Finishing Touches📝 Generate docstrings
Comment |
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_f5e4367d-1220-474c-99d6-1dc2a217a1ab) |
![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: a1c9488e9d
ℹ️ 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".
Codex P2 on #1154: the probe still printed that form A has "ZERO callers in the tree today", which the consolidation in this same PR made false. Correct, and re-running the cited grep found the sharper problem underneath — the claim was already false at the census commit. This file imports form A and calls it at line 325, so the grep it cites as "returning nothing" never returned nothing. It was run before the file existed and was never re-run. That is the failure mode this repo names as a P0: a measurement recorded as evidence, invalidated by the very commit recording it, with nothing re-running it. An executable probe is the worst place for it, because the number reads as measured rather than asserted. The block now carries its commit and its command, states the one production caller by file:line, separates that from the probe's own use, and keeps the pre-consolidation zero as what the census was run to establish. The comment above it records both errors so the next reader re-runs the command instead of trusting the number. Probe still exits 0 with C1 PASS / C2 RESTATED / C3 PASS. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
The census's caller count was wrong twice — the review bot caught the staleness the consolidation introduced, and re-running the cited grep found that the claim had never been true, because the probe file itself imports and calls the symbol it reported as uncalled. The generalizable half is why an executable probe is the worst host for a claim about the tree: the same sentence that reads as an assertion in a plan reads as OUTPUT inside a running program, borrowing credibility nothing earned. An unasserted println is not a measurement, it is a comment with better formatting — and every claim in that file gated by an assert survived this while the one printed without one did not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
…rate-harvest-pvfbs9
A cross-session audit read this module against a plan that mints a contradiction verb, correctly declined the tempting unification, and then observed that the header never says which family the module is in. The distinction was recorded — in #1145's PR body, verbatim: "No population-basin work: family 3 stays the accepted vacancy." So the knowledge existed, was correct, and was still unavailable, because a boundary recorded only in a PR body is not self-defending. The next reader greps the tree, not the PR archive. The header now declares family (1) episodic / Markov loci verbatim from the ruling, states that Locus::Contradiction here is a signed offset and not family (3) epistemic population basins, and names the specific confusion it forecloses. The board is where a decision is justified; the source is where it has to be enforced. Doc-only. 46/46 witness_fabric tests unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
|
@codex review Requesting explicitly because three commits since your review are uncovered, including the fix to your own finding:
CodeRabbit is capped (org spending cap; 84 attempts/7d → 1 review/hour), but that is only half the gap. You aren't capped — you re-review only on open, mark-ready, or this comment. So on any PR that receives a finding, the fix for it ships unreviewed by default, which is exactly the case here and is the least-checked commit on the PR. Worth a close look at Generated by Claude Code |
The lance-graph-java session flagged five consecutive PRs merging with no external review, and attributed it to CodeRabbit's spending cap. The cap is real, but it is the visible half. Measured on this PR's own review metadata: the second reviewer is not capped and still saw only one of four commits. Its triggers are opening a PR, marking a draft ready, and an explicit review comment — a push is not one. So the sequence every reviewed PR follows (review lands, author fixes, author pushes, merge) ends with the fix for the finding as the least-reviewed commit on the PR. Here the reviewed commit was the one carrying the defect and the unreviewed ones included its correction. Raising the cap does not touch that. It is trigger semantics, it costs one comment to work around, and it applies to every PR in this workspace that has ever received a finding and fixed it. The failure is that the PR looks reviewed: there is a review, it found something real, the thread is resolved. Coverage earned by one commit is read as a property of the whole PR — the same shape as a probe printing a measurement taken before the tree changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 156a727cae
ℹ️ 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".
| h / (BINS as f32).log2() // normalize to [0, 1] | ||
| // BINS is a non-zero constant > 1, so the atom's empty/single arms are | ||
| // unreachable here; the default is defensive, never taken. | ||
| normalized_entropy(&hist).unwrap_or(0.0) |
There was a problem hiding this comment.
After this delegation changes the live confidence_entropy, running entropy_surface_census still evaluates the former implementation copied in examples/entropy_surface_census.rs:68-104; that transcription even says the source still builds a [usize; 10] histogram and performs its own log2 loop. Consequently the probe's table and C2 results no longer census the seven implementations at this head, despite presenting B as planner insight::confidence_entropy; update or relabel the transcription when replacing the source implementation.
Useful? React with 👍 / 👎.
| for b in arena.entries() { | ||
| let idx = ((b.truth.confidence.clamp(0.0, 1.0) * BINS as f32) as usize).min(BINS - 1); | ||
| hist[idx] += 1; | ||
| hist[idx] += 1.0; |
There was a problem hiding this comment.
For an arena with more than 16,777,216 beliefs in any confidence bin, repeatedly adding 1.0 to an f32 stops increasing that bin because integers above 2^24 are not represented at unit precision. For example, bins containing 20 million and 40 million beliefs both end up as 16,777,216.0, so the shared atom sees them as equally populated, whereas the previous usize histogram preserved their 1:2 ratio. Keep the counts integral and convert each completed count to f32 only when constructing the atom's input.
Useful? React with 👍 / 👎.
… real defects
A 5+3 council on the three EPIPHANIES entries and two source-doc blocks that
sat on this PR unseen by either review bot. The board is append-only, so this
was the last moment the text was amendable rather than permanent-with-regrade.
The spec's position was "ratify all five as written, zero edits." Five savants
falsified it and three reviewers then found more, including in the amendments.
No BLOCK; every section came back FIX.
Two real code defects, both external findings, both verified:
- the histogram accumulated into f32, which silently stops counting above
2^24 (f32(2^24) + 1.0 == f32(2^24), measured). Counts are usize again and
widen once at the boundary.
- the census presented a retired implementation as live form B. It is now
labelled a fossil as-of its commit rather than re-transcribed, because
re-pointing it at the new code would convert a measured falsification into
a comparison of form A against itself.
And the census caller count is finally falsifiable. Two revisions shipped a
decaying claim; the second added the commit and the command, which is real
provenance and still not falsifiability, because nothing failed when the count
changed. It is now sourced from the caller at compile time and asserted at run
time — disable-verified: remove the delegation and the probe panics with
"found 0".
What the council caught in my own work, in descending order of how much it
would have cost:
- Entry B claimed the boundary was recorded "only in a PR body". False: the
same sentence is on this board. The finding survives stronger as "absent
from the SOURCE" — it was in two durable places and still missing where
the misreading happens.
- The spec's own citation of the ruling it froze was stale, because an
append-only board renumbers under every prepend. That is the exact defect
one of the entries is about, committed in the document written to catch it.
- I widened a savant's crate-scoped grep into a repo-wide claim and shipped
a false verification inside an amendment about false verifications.
- Entry C's aphorism proved too much — it condemned legitimate output two
lines earlier in the same file. Narrowed on provenance (a value the run
computed vs one the author transcribed), which is the axis that
discriminates, and which preserves the mechanism the regrade had just
named as the entry's only novel part.
- Entry C is a new instance of a pattern already ruled in the knowledge
docs, not a new rule.
- Entry A inferred coverage from an absence when the bot's own rule makes
absence ambiguous; confidence is now split, and its defect-hedge was kept
alongside the new one rather than replaced.
A knowledge doc asserting the bot "reviews every PR diff" is falsified by one
of these entries and is corrected in this commit, so the next reader does not
load the false one.
The commit-trailer question a savant raised is escalated in LATEST_STATE, not
resolved here.
Gates: planner 411/0, contract 1309/0, probe exits 0 with C1 PASS / C2
RESTATED / C3 PASS, clippy zero diagnostics on touched files, fmt clean,
supersession index regenerated last with no diff, and zero deletions against
the merge-base on every board file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
|
@codex review Applying the rule this PR canonizes, to this PR. It acts on both of your P2s and on a 5+3 council's findings:
Worth your attention specifically, because it is where I would expect to be wrong: Generated by Claude Code |
Both sides prepended a dated entry to the top of LATEST_STATE.md, an append-only log, so the conflict is positional and neither entry is wrong. #1154's council-on-the-canon-entries delta and this PR's dangling-reference regrade both survive; mine sits on top as the later arrival. Post-check per the workspace law: 2944 -> 2995 lines, a net gain. An append-only file that got shorter is always a defect, and a prepend conflict resolved by picking one side is exactly how that happens. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DCfrD5y19cvFc4AoyydXYv
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1688d9097c
ℹ️ 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".
| /// — the `use` line and every doc-comment mention lack the paren, so they do not | ||
| /// inflate it, and this comment lives in a different file so it cannot self-match. | ||
| fn production_call_sites() -> usize { | ||
| INSIGHT_SRC.matches("normalized_entropy(").count() |
There was a problem hiding this comment.
production_call_sites does not actually distinguish production calls from text: if the live delegation is commented out while leaving normalized_entropy(&weights) in that comment, or if a test/doc example later contains that spelling, the asserted count remains or becomes 1 even though the production-call invariant is false. Since this probe is intended to prevent another stale census, base the assertion on something that cannot match comments, strings, or cfg-disabled code rather than a raw substring count.
Useful? React with 👍 / 👎.
| /// `crates/lance-graph-planner/src/nars/insight.rs:176-198` | ||
| /// (`fn confidence_entropy(arena: &BeliefArena) -> f32`), verified at | ||
| /// that range on read. | ||
| /// that range on read **as of `a1c9488e`**. |
There was a problem hiding this comment.
Fresh evidence after the prior Form B finding shows that the new provenance is still incorrect: git show a1c9488e:crates/lance-graph-planner/src/nars/insight.rs already contains the delegated implementation at lines 198–210, whereas the transcribed log2 loop exists in parent c7002ee at lines 180–198. Labeling this fossil as verified at a1c9488e therefore points future readers to a different implementation and defeats the stated reproducibility; cite the pre-consolidation revision instead.
Useful? React with 👍 / 👎.
2 participants
The census in #1153 (PROBE-ENTROPY-SURFACE-CENSUS-1) licensed exactly one routing. This is it, and nothing wider.
lance_graph_planner::nars::insight::confidence_entropydrops its own Shannon loop and hands its 10-bin histogram tolance_graph_contract::thought_atoms::normalized_entropy— taking that operator-ruled module's consumer count from 0 to 1. It had never been called. A ruled home with no caller is not a home; it is a vacancy the next session re-implements beside.Why this was a substitution and not a hypothesis
C1 had already established that the log base is inert under normalization —
log2/log2(10)andln/ln(n)agreed to0.00000000on every fixture. So the caller's normalization and the atom's are the same function, and the routing needed no tolerance argument at all.The one hazard, and it is silent
C2 recorded that the two conventions are OPPOSITE on zero mass: the caller returns
0.0for an empty arena, the atom returnsSome(1.0)("nothing prefers anything — indistinguishable from uniform"). An empty arena builds an all-zero histogram, so the caller'sis_emptyearly return is load-bearing — without it, an arena holding no uncertainty reports maximal uncertainty, and since1.0is in range nothing downstream would object.The guard now says so in its own doc comment and is pinned by
an_empty_arena_has_zero_truth_entropy_not_one. Disable-verified: deleting the early return fails that test and only that test (13 passed / 1 failed), restoring it returns 14/14.Its paired can-fire half exists because that guard test is satisfiable by a stub returning
0.0.the_routed_atom_still_spans_the_confidence_rangeasserts full range on non-trivial input — one occupied bin ⇒0.0, ten evenly occupied ⇒1.0— and, third, that normalization is by the bin count and not the occupied count (five bins of two ⇒ln 5 / ln 10). That third assertion is the one that catches a plausible-looking rewrite dividing by however many bins happened to be full.Scope held deliberately
Forms C/D/E are untouched — two live in workspace-excluded crates, so no in-workspace caller can reach them. F/G are untouched on purpose: C3 measured them moving
92.103409between the same distribution at 1× and 10× mass and going negative on elements above 1, which means they are not entropies of a distribution at all. Correcting them is a lab behaviour change and needs its own gate, not this one's.Cross-session convergence, recorded rather than merged
rubicon-loco-rung-cognitive-fabric-v1.md§130 (#1152, merged the same day) reached the same fragmentation finding from the opposite direction: "Shannon entropy — EXISTS BUT NOT LOCO-ADDRESSABLE — ≥6 uncoordinatedentropy()surfaces" (the census measured seven). The arcs are complementary and the distinction is worth keeping sharp — that plan wants entropy to have an address, this one gives it a home. An address for a function that still exists in seven copies would just name one of them. Its accompanying rule, "Do not rewrite good SIMD in R2IL to claim purity", is the same restraint the F/G verdict already imposes here. Audited for contention: zero code overlap, board ledgers only.Gates
cargo test -p lance-graph-planner --lib— 411 passed / 0 failedcargo clippy -p lance-graph-planner --all-targets— cleancargo fmt— cleanBoard
EPIPHANIESE-A-RULED-HOME-NEEDS-A-FIRST-CONSUMER-OR-IT-IS-A-VACANCY-1,LATEST_STATEdelta,STATUS_BOARDD-DCR-4, plandismech-causal-replay-v1.mdW4 gate; supersession index regenerated last (no diff — current).🤖 Generated with Claude Code
https://claude.ai/code/session_01QHVUi6Q9XtmKgxh6pDRayP
Generated by Claude Code
Summary by CodeRabbit
Bug Fixes
Documentation