The result was there. The record was not: repairing outcome capture

A task can finish successfully and still leave the learning system with an incomplete record. That was the gap here: the outcome existed, but the writer and reader did not agree on how to preserve the result and its correlation.

Finding the mismatch

Fable traced the problem across the existing OQS writer, the KPBI client endpoint and the readers that expected the stored outcome. The review found more than an authentication mismatch. Even if the old HTTP call had been admitted, its identifiers and classification fields would not have landed in the shape the readers used.

The recommendation was deliberately small: keep KPBI's hardened client boundary intact and repair the established OQS writer through the already-sanctioned service-role path. The content policy stayed signal-only, and the task question and result text were not carried into the training record.

Repairing the existing path

OQS/Astra implemented that bounded writer repair. The stored record now places the outcome and correlation fields where the existing readers look for them, while both content fields remain the literal placeholder [CONTENT NOT COLLECTED].

The change did not create a new endpoint, reopen KPBI's browser authentication contract or alter the database schema. It repaired the existing capture function and preserved its non-blocking behavior.

Independent review and recorded readback

Grok independently reviewed the repaired path. The signal-only policy, correlation, non-blocking behavior and route boundary passed, along with 15 capture-and-detector tests.

For the recorded readback, Astra selected one genuine historical success result that had already completed. A precheck found no prior capture for it. The repaired function was invoked once from local code against the live data path—without rerunning the task—and the same capture was returned by the existing outcome reader and the KPBI Training interface.

Seven bounded checks passed: identity, task correlation, source outcome, signal-only placeholders, unchanged source evidence, reader identity and reader outcome.

What this proves

This is a recorded repair of outcome capture and readback. It shows that one existing historical result could be stored once under the signal-only policy and recovered through the established reader and review interface.

It does not establish a fresh governed task run, hosted-handler acceptance, continuous automatic capture, non-null assembly or flight-record filtering, training approval, SQL execution or whole-product KPBI acceptance.

Evidence

The captured source retains the implementation commit, test record, independent review and bounded readback evidence. Technical identifiers and hashes stay with that provenance rather than interrupting the public story.