Memory tiers + the learning loop

The brain — optional, and not read by any audit

This page describes the brain, corral’s optional coordination daemon. Nothing on it is required for a verdict: corral certify, the GitHub Action, verify, ui, seal and scans never contact a brain. And nothing on it is read by an audit — an audit’s prompts are built from the goal, the code and its symbols, never from shared memory, skills or a prior run. See the brain, and what it is not.

Memory tiers

Memory entries start advisory — written by any agent (add_memory), searched by everyone (search_memory), but not yet trusted enough to shape behavior automatically. CORRAL.md + docs/corral/*.md are ingested the same way, tagged to the repo — code review is the trust gate for that knowledge, same as for code. Promotion to vetted (shared=true) requires the human gate below; only vetted guidance is injected into later audit runs’ task instructions.

The learning loop

A periodic sweep clusters recurring finding signatures (the same Type+Target, seen 3 or more times) and similar lessons into proposals: an LLM drafts corrective guidance plus a reusable skill, Shep announces the pending proposal at standup — even with an empty queue — and the operator approves or rejects it, from the Proposals tab (a live count badge, kept off the Progress tab so a busy sweep doesn’t crowd the view) or corral-admin proposals. Approval fans the guidance out to vetted memory and a versioned skill artifact. The injection of the top vetted lessons into a later run’s task instructions — fence-wrapped under LESSONS FROM THE HERD (vetted) and capped at 3 — is built but not wired: InjectLessons exists and is covered by its tests, and no production path calls it. The hosted pool creates its tracking mission and starts the driver without retrieving vetted lessons. Nothing an audit does today is changed by an approved proposal, and this page will say so until that changes.

The sweep re-feeds the full finding/lesson history every tick rather than accumulating counts, so a signature’s count always reflects what’s true right now, not what’s ever been true. Once a signature’s proposal is approved, that settles it: further sweeps of the same signature are a no-op — the question moved from “is this worth flagging” to “is the fix actually working,” which is the efficacy watchdog’s job. If the same signature recurs 2 or more times after promotion, a revision proposal reopens against the approved one for the human to reconsider. A rejected proposal is suppressed until its recurrence count doubles past the count it was rejected at, then reopens as fresh.

See corral-admin proposals list|show|approve|reject in the CLI reference.