ACTION REQUIRED (8 nights old) — nightly 2026-08-24: a low-confidence finding was promoted as unqualified fact - #21
Open
jaydubya818 wants to merge 1 commit into
Open
Conversation
promoteDiscovery read `confidence`, `related_sources` and `evidence_count` off the bus item to build the scorer candidate, then dropped all three when serializing the promoted page. The V2 provenance block recorded how the promotion was decided (promotion_score, promotion_decision, contradiction_status, explicit_approval) but not what it was decided *about*. Reproduced by promoting two candidates from opposite ends of the evidence scale through the same gate: `confidence: high` with evidence_count 9 and three cited sources, and `confidence: low` with evidence_count 1 and none. Both cleared as `learned` (0.702 and 0.566) and produced promoted frontmatter identical on every qualifier — nothing on the page distinguished them. So an uncertain observation read as unqualified fact to any consumer loading the promoted page, and the evidence links that justified it were reachable only by following `source_path` back to the bus item and re-reading it. This is the failure mode docs/LOSSY-BOUNDARIES.md section 5 catalogues: recoverable in one hop, but invisible at the point of use. Now carried onto the page. Defaults match the ones scorePromotion applies to the candidate (medium / [] / 0), so the page records what was actually scored rather than a second interpretation of the same input, and an unscored promotion states the same fields instead of omitting them. Field names and the `|| []` shape match publishBusItem, which is where these values originate.
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
1 participant
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.
Recommended merge order: 4 of 9 — but flagged regardless of content: this is the oldest branch on the repo.
Age: 8 nights (2026-08-24) — the longest-lived unmerged branch here, and it is 80 commits behind
main. Commits: 1. Files:lib/agent-runtime/promotion.mjs,tests/agents/promotion-provenance.test.mjs.Why it needs a decision now
Not because the fix is urgent — because an 8-night-old branch is a process failure. It has survived seven nightly runs without being merged or closed. Either merge it or close it; leaving it is the outcome that keeps costing.
Content
The promotion path emitted a low-confidence finding into canonical wiki content without its qualifier, so a tentative result read as established fact downstream. That is a knowledge-integrity bug in a knowledge base: the damage is silent and compounds, because later readers cannot tell the claim was ever hedged.
Verification
Rebased onto current
main: 605 pass / 0 fail, despite being 80 commits behind — it rebases without conflict and its regression test still holds.Risk if this is wrong
Promotion output becomes more conservative — a finding that previously promoted cleanly may now carry a qualifier or be held back. Failure direction is under-promotion, which is recoverable; the current behaviour's failure direction is not.
Standing facts, measured on this run (2026-09-01)
All eight pre-existing nightly branches were re-measured against
mainat commitf42213ee:git merge-tree --write-tree main <branch>reports zero conflicts for all eight. (The brief described all eight asdiverged; that is a GitHub compare status meaning "both refs have unique commits", not a conflict prediction.)git log --cherry-pick --right-only main...<branch>returns a non-empty commit list for every one of the eight, so no branch is closable without merging on supersession grounds.mainand the full root suite run. All green (counts per-PR below). Root suite only —web/has no test suite, so branches touchingweb/are unverified on their actual subject matter.Opened by the nightly maintenance run. Not auto-merged and not self-approved.