[feature] prediction records: store what was expected, resolve it from an external verdict, score the calibration #597

The gap

Cortex stores what happened. It does not store what was expected to happen, so nothing can be wrong in a way it notices. Two measurements from 2026-09-16 make the gap concrete:

• Mining over the 374 transcripts under ~/.claude/projects returns 796 procedural skills, every one at proficiency 0.5, because core/procedural_memory.mine_skills treats a session with no outcome as neutral. The session log records no outcome: 0 of 413 entries carry a score (the hook writes none; handlers/record_session_end.py:226 does, on the path that hosts without hooks use).
• wiki.claim_events carries a confidence per claim, and ingest_findings separates finding,verified from finding,hypothesis, but nothing records a claim's prediction, and nothing later compares it to what was observed.

Recurrence is not expertise. A sequence repeated thirty times with no verdict is a habit, not a skill.

What this asks for

A first-class prediction record, its own table and tools, with an open state and a resolved state, owner-decided on 2026-09-16.

A record holds: the claim it belongs to, the prediction in falsifiable terms, the test that would settle it, the confidence at the time of writing (0 to 1), and, once resolved, the observed result, the verdict, and a reference to the evidence.

Verdicts: confirmed, refuted, abandoned (the test was never run and no longer will be). Only the first two score.

Calibration. Brier score over resolved records: the mean of (confidence - outcome)² with outcome 1 for confirmed and 0 for refuted, reported with its count and with a reliability breakdown per confidence bucket, scoped by domain or project. A Brier of 0.25 is what a constant 0.5 earns; anything above it means the confidences carry less than no information.

The resolution contract, and why it is repo-agnostic

The owner's decision is that the posted review verdict is the outcome signal, and that it must work in any repository where Cortex runs, not only this one.

So Cortex does not fetch the verdict and knows nothing about GitHub, this repository's review conventions, or the ZETETIC-REVIEW: marker its own merge gate enforces. The caller resolves a prediction by supplying the verdict, the observed result, a source_kind (review, ci, test, manual) and a source_ref (a URL or an opaque identifier). Cortex validates that shape and refuses a resolution without a reference, the same discipline as "no source, no implementation". A host working in another repository maps its own review convention onto the same four fields.

Backends

The table exists on both backends or the feature does not ship. procedural_skills is PostgreSQL-only and therefore dead on the default install (#596); repeating that asymmetry would make calibration invisible to most users.

Evidence required to close

A prediction written, resolved from a review verdict carrying its reference, and a calibration call returning a Brier score over at least two resolved records with different confidences; the same three steps passing on SQLite and on PostgreSQL; a refused resolution with no reference; and the tool count and its documentation updated the way CONTRIBUTING.md § Adding an MCP tool requires.