fix(feedback): make retrieval-exposure audit-only by default (#1086)

[robotrocketscience]

First step of #1086 (belief scoring is one-directional). Fixes the dominant driver: retrieval-exposure was treated as positive evidence.

Problem

A hook retrieval bumped the belief's Bayesian posterior (+0.1 to α via apply_feedback). But a retrieval is exposure, not endorsement — its own module docstring said so. Counting every surfacing as truth-evidence let whatever recurs float above genuine knowledge, with no counter-signal (all decay/demote sinks are dead or default-off).

Evidence (measured on a real 24,883-belief store)

• Junk (session scaffolding, fragments) carried ~3× the exposure-α of clean beliefs and scored higher: junk mean μ 0.554 vs clean 0.446.
• The most-exposed junk were recurring prompts surfaced ~240× each.
• Factorial counterfactual (exposure {on/off} × decay-sink {on/off}): removing exposure removes ~60% of the junk-above-clean gap (+0.053 → +0.021); a recency/decay sink is nearly inert here (junk is hot, not stale) and cold-hibernation is counterproductive — so the sink half of Belief scoring is one-directional: exposure promotes, no organic sink (junk percolates up, not down) #1086 is empirically deprioritised; exposure is the lever.
• Dual-matrix (each surfacing = a bet, payoff asymmetric): useful-hit-rate WR ≈ 0.62–0.75; break-even at k≈2–3, i.e. the store is net-negative at retrieval once acting-on-junk costs more than ~2–3× a good surface's value.

Fix

apply_feedback gains update_posterior: bool. When False, the event is still written to feedback_history (exposure frequency stays recoverable for the recurrence axis, #1086 fix #3) but the posterior update and valence propagation are skipped. record_retrieval passes it through, gated by AELFRICE_EXPOSURE_UPDATES_POSTERIOR — default off = the fix; set to 1 to restore the pre-#1086 behaviour (benchmark A/B and rollback).

Verification

Controlled: a belief retrieved 50× no longer outranks a once-seen belief — both stay at prior μ=0.5 (gap +0.000); under the legacy flag the recurred belief inflates to μ=0.857 (gap +0.333). The built fix reproduces the counterfactual prediction.

Tests

Two tests that encoded the old behaviour (exposure moves α) are updated to the new default and given legacy-flag coverage; three focused apply_feedback(update_posterior=False) unit tests added (posterior untouched, audit row still written, no propagation). Full suite: 5,649 passed.

Scope

• Does not close Belief scoring is one-directional: exposure promotes, no organic sink (junk percolates up, not down) #1086. Remaining: separate recurrence from truth (ci: history-scan should see all branches #3), decided-vs-floated status with active maybe→decision re-evaluation (feat: add Belief/Edge dataclasses and config module #4), and the residual ingest-prior misclassification.
• The #191 deferred-feedback sweep applies the same exposure-as-evidence pattern (currently inactive — 0 rows) and should get the same treatment in a follow-up.

[sourcery-ai]

Sorry @robotrocketscience, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

@robotrocketscience, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 32 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a6642a67-3551-4d22-82b2-f2730e17e91a

📥 Commits

Reviewing files that changed from the base of the PR and between 40ecfbe and 4630116.

📒 Files selected for processing (5)

• src/aelfrice/feedback.py
• src/aelfrice/hook_search.py
• tests/regression/test_hook_to_feedback_history_end_to_end.py
• tests/test_feedback_apply.py
• tests/test_hook_search.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/issue-1086-neutralize-exposure

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

PR-size soft cap

This PR is over the advisory size threshold:

• 149 changed lines (limit: 200)
• 5 changed files (limit: 3)

Bigger PRs collide with more open work, which under the parallel-session workflow tends to produce repeated attn:merge-conflict cycles (see #602). When practical, split into smaller PRs that each touch a focused surface.

This is advisory only — nothing is blocked. If the size is intentional (large refactor, module removal, generated code), apply the size:override label and this comment will be removed on the next push.

[robotrocketscience]

[claim:review:kulili:2026-07-05T06:43:29Z]

[robotrocketscience]

[claim:review:Garsecg:2026-07-05T06:44:17Z]

[robotrocketscience]

[release:review:Garsecg:2026-07-05T06:44:22Z]

[robotrocketscience]

[release:review:kulili:2026-07-05T06:45:15Z]

[github-actions]

merge-train: blocked

branch is not fast-forward on main (branch base 69417ce6e4c07e08666a414d0be49e60ff022200, current main 40ecfbee020db0fbbd130a05b5dad36ec0c905b9). Rebase locally (git rebase github/main), force-push, and re-add the label.

The ready-to-merge label has been removed. Address the issue above and re-add the label when you're ready for another attempt.

[github-actions]

merge-train: merged 4630116 → main via FF push.