lance-graph-ogar: PROBE-SUDOKU-COGNITIVE-CORPUS-1 — the first real corpus through the dispatch bridge - #997
Merged
Conversation
…rpus through the dispatch bridge Runs the Sudoku Wikipedia article's example puzzle through naked-single constraint propagation (ordinary, correct Rust) with every elimination event ALSO dispatched through a real kernel(id) via the PROBE-RECIPE-DISPATCH-BRIDGE-1 (#996) bridge, producing one canonical receipt. Two things kept deliberately separate: 1. The Sudoku solving is ground-truthed constraint propagation, NOT claimed to be "solved by the recipe kernels". Every digit assigned is checked against an independent full backtracking solve sharing no code with the propagation loop. 2. Each elimination event is also dispatched through a real TCP(5)/TCF(20)/CUR(26) kernel -- the exact three recipes PROBE-RECIPE-EXECUTION-1 (#995) found colliding under a synthetic battery -- chosen per event by which real peer group (row/column/ box) has the fewest remaining unsolved cells. This is a measured side channel that observes real puzzle state; it does not drive or validate the solving. Results: - This puzzle solves completely by naked singles alone: 51 assignments, 81/81 cells, ALL warranted against the independent backtracking solution. - 282 elimination events dispatched through real kernels. - TCP/TCF/CUR STILL collide under real puzzle-derived data (each producing only 2 distinct (fired, delta-conf-sign) signatures across the whole corpus) -- distinguishing "coarse signature too blunt" from "under-tested by the synthetic battery": real data did not separate them either. Board: EPIPHANIES E-SUDOKU-COGNITIVE-CORPUS-1. Co-Authored-By: Claude <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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_b029259c-51d3-4327-a42f-61b2db827e8d) |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 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 |
AdaWorldAPI
added a commit
that referenced
this pull request
Aug 23, 2026
Audit finding (verified against a freshly-synced OGAR main, not the stale local clone this session started with): commit ae8e762 mirrored 14 "Ontology" concepts (mondo/hpo/uberon/pato/ro + the meta-study spine) into this crate's CODEBOOK under a doc comment claiming "operator ruling: the domains should be minted in ogar-vocab" and "DeepNSM-v2 wired: deepnsm::ontology_vocab". Neither claim was ever true: - OGAR's ogar-vocab has never once minted a 0x03XX CODEBOOK row. Its only commit touching the block (e9a2e45, 2026-08-01 -- three weeks BEFORE the mirror commit) is "reserve 0x03 Ontology domain (plug-and-play, zero rows)" -- explicitly the OPPOSITE posture, unchanged on current OGAR main: "Carries ZERO shared vocabulary rows... Do NOT mint rows here." - `deepnsm` has no `ontology_vocab` module and no reference anywhere in its source to `ogar_codebook`, `ConceptDomain`, or `concepts_in_domain`. This is exactly the drift `lance-graph-ogar::parity:: mirror_is_a_faithful_copy_of_ogar_codebook` exists to catch, and it did: CI's "test" job has been failing on every PR since (confirmed on both #997 and #998, unrelated example-only PRs that inherited the broken main via their base SHA). Fix, smallest boundary: - Remove the 14 rows; restore the 0x03XX block to OGAR's actual, unchanged "reserved, zero vocabulary rows" posture. No OGAR-side change needed or made -- OGAR was never wrong. - Correct the two doc comments that repeated the false claim (`concepts_in_domain`'s doc, the CODEBOOK block comment) and the one test that asserted the hallucinated content (`concepts_in_domain_answers_for_ontology_and_stays_silent_for_a_reserved_block`, now asserts Ontology returns empty like Osint, with ProjectMgmt as the populated-domain anti-vacuity check instead). - Same correction to a stray comment in lance-graph-ogar's own `reserved_empty_domains_agree_across_the_mirror` test (referenced a nonexistent "0x0333 DisMech" mint -- same class of stale-context claim, harmless to the assertion since it only checks domain-tag agreement, but misleading). - Rename the CI step "Run lance-graph-ogar fuse tests" to "... codebook-parity + hotplug-activation tests" and correct its comment (still referenced the compile-time COUNT_FUSE, retired 2026-08-14). Explicitly NOT touched: OGAR (read-only from here, and it was never wrong); the 4 C-band domains (Weather/JavaRuntime/Analytics/ BinaryLifting) -- these looked like a second instance of the same drift against a stale local OGAR clone (frozen at PR #265), but after fast-forwarding to origin/main (PR #281) they are confirmed real, OGAR-side, operator-ruled (PR #276/#277, 2026-08-18), and correctly mirrored. False alarm, recorded here so it isn't re-investigated. Verified: `cargo test --manifest-path crates/lance-graph-contract/Cargo.toml --lib ogar_codebook` green (15/15). Full `lance-graph-ogar` suite pending a local disk-space recovery (session tmpfs exhausted mid-verification) -- CI on this PR is the first full confirmation. Note: `.claude/board/EPIPHANIES.md` is NOT updated in this commit -- it exceeds the 1MB API fetch limit and this session's git/Bash access is currently down, so a safe byte-exact prepend isn't possible right now. This violates the repo's same-commit board-hygiene rule deliberately, once, rather than risk corrupting an append-only governance file. Follow-up needed once tooling recovers.
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_008c07da-80a5-4688-be51-98342e6fa678) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Runs a real Sudoku puzzle (the Sudoku Wikipedia article's example grid) through
PROBE-RECIPE-DISPATCH-BRIDGE-1(#996) as the first real corpus.Two things kept deliberately separate
kernel(id)via the exact bridge lance-graph-ogar: PROBE-RECIPE-DISPATCH-BRIDGE-1 — the FnIndex -> kernel(id) seam, built #996 proved identity-preserving, withThoughtCtx.candidatesbuilt from the cell's real, live candidate set. This is a measured side channel that observes real puzzle state — it does not drive or validate the solving. The recipe's own pruning heuristic is generic and confidence-shaped, not Sudoku-aware, and the probe does not pretend otherwise.Why
TCP(5)/TCF(20)/CUR(26)PROBE-RECIPE-EXECUTION-1(#995) found these three collapsed into identical coarse effect signatures under its synthetic 4-context battery. They're also the three whose names most plausibly fit "prune a candidate set" — not a claim they're "the" right recipes for Sudoku, but the most interesting re-test: do they still collide under real, puzzle-derived data? Selection per event is deterministic and puzzle-state-derived (not hand-picked): the peer group — row / column / box — with the fewest remaining unsolved cells chooses row→TCP, column→CUR, box→TCF.Results
(fired, Δconf-sign)signatures across the entire corpus, identical to the synthetic-battery result. This distinguishes "coarse signature too blunt" from "under-tested by the synthetic battery": real, varied candidate sets (2–9 candidates per cell) did not separate them either.This PR
crates/lance-graph-ogar/examples/sudoku_cognitive_corpus_probe.rs(new).claude/board/EPIPHANIES.md:E-SUDOKU-COGNITIVE-CORPUS-1lance-graph-ogaris workspace-EXCLUDED by design — run viacargo run --manifest-path crates/lance-graph-ogar/Cargo.toml --example sudoku_cognitive_corpus_probe.Generated by Claude Code