Fix

Fix is the third move of the Trust Loop. Understand showed you the reasoning. Prevent stopped a bad action. Fix is how you correct a wrong decision, in the exact context that produced it. A correction here is not an edit to a log. It is a first-class event on the run, attributed and kept, that changes what the system does next.

Correct in context, not in a vacuum

A correction lands on the decision itself, against the claims, evidence, and assumptions that produced it. That context is what makes the fix precise. You are not retyping an answer; you are overturning a specific claim or replacing a specific assumption, and the system records exactly what changed and why.

Take the refund run from Understand. The agent leaned on a low-confidence assumption, that the customer tier resolved to standard, and auto-approved on the back of it. A reviewer who saw that weak link can correct it directly on the step.

The reviewer replaced the inferred tier with the confirmed one. The original decision stays on the record, marked as superseded, and the correction sits beside it with who made it and when. Nothing is overwritten, because the point of a system of record is that you can still see what the agent originally believed.

A fix changes three things

A single correction propagates, in order:

1. The decision. The outcome is reversed or adjusted now. The refund that was auto-approved on a bad assumption is re-routed under the correct tier.
2. The record. The correction is appended to the run, attributed to the person who made it, with the before and after both visible. The run stays auditable, and the audit now includes the human judgment.
3. The future. The correction becomes reusable context. The next run that hits the same weak assumption starts from the corrected position rather than repeating the mistake. That hand-off is Remember.

Close the loop over the API

A correction does not require a person in the dashboard. The findings on a run carry fingerprints, and one write dispositions a finding (records your judgment on it): accept it, dismiss it, or mark it corrected. This is how a coding agent fixes its own agent, on the record. Setup (gateway URL, studio key, studio id) is the same as in Understand.

curl -s -H "X-API-KEY: $EXPLAINABILITY_API_KEY" \
  "$EXPLAINABILITY_GATEWAY_URL/v1/studios/$STUDIO_ID/runs/$RUN_ID/rml/v3/findings"

The findings response has two halves: findings.rules[] defines the rules that ran, and findings.results[] holds the actual findings. Each result carries its rule_id, a level, a plain-language message, a suggested fix, and the fingerprint the next call needs.

curl -s -X POST -H "X-API-KEY: $EXPLAINABILITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"fingerprint": "03d5d42fbce9338c", "disposition": "accepted", "note": "real issue, fixed in prompt v4"}' \
  "$EXPLAINABILITY_GATEWAY_URL/v1/studios/$STUDIO_ID/runs/$RUN_ID/rml/v3/feedback"

{
  "status": "recorded",
  "fingerprint": "03d5d42fbce9338c",
  "disposition": "accepted",
  "praxis_signal_published": true
}

Feedback request body:

Feedback response fields:

Accepted and dismissed dispositions accumulate into per-rule precision, so an agent that dispositions its findings is training the thing that grades it. Suppressions take effect at the next document build. Omit a required field and the error is precise (fingerprint is required, invalid disposition), so an agent can self-correct from the response instead of guessing.

The third step is checking a fix without re-running the agent. Re-grade the same stored run after a prompt or rule change:

curl -s -X POST -H "X-API-KEY: $EXPLAINABILITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}' "$EXPLAINABILITY_GATEWAY_URL/v1/studios/$STUDIO_ID/runs/$RUN_ID/rule-book/replay"

Replay request body (an empty object is valid):

A 404 from replay means the run has no archived spans to re-grade. Heuristic improvement suggestions for the run are one more read away, at .../runs/$RUN_ID/optimizations (add include_dismissed=true to include suggestions a person already dismissed). The learnings MCP server exposes all three steps as tools.

Escalations land here too

A Prevent policy that escalates rather than denies routes the decision to a person, and this is where it arrives. The reviewer sees the full reasoning, makes the call, and that judgment is recorded as a correction on the run, exactly like any other fix. Escalation and correction are the same loop: a human decision, attributed and carried forward.

Why this matters

• Decisions get better in place. You fix the cause on the run that produced it, not in a downstream patch that loses the context.
• Human judgment is captured. The reviewer's call becomes part of the permanent record and part of the system's future behavior. This is the BI half of AI + BI = CI: brain intelligence, recorded where the artificial intelligence can reuse it.
• The fix compounds. A correction made once is available everywhere the same situation recurs, which is the bridge from Fix to Remember.

Next steps