Documentation

Brain Triage Lane

A holding lane for monitored or auto-ingested hits, excluded from a brain's compiled map until you promote or dismiss them.

Monitoring and auto-discovery write a lot of raw hits. Dropping them straight into a brain would pollute its compiled knowledge map with noise nobody asked for. The triage lane gives every brain a holding area instead: a monitored note arrives marked pending, stays out of the compile, and waits for you (or an agent) to promote it in or dismiss it as not worth keeping.

How a note ends up in triage

Nothing in the normal note-writing path sets triage state on its own — post_notes and update_brain create ordinary notes, included in the next compile as always. A note enters the triage lane only when something marks it triage_state: pending at write time (the monitoring pipeline that will write there once it lands; see the roadmap). Until then, the lane is fully usable by hand for anything that wants a review-before-it-counts step.

A pending note carries lineage in triage_source — where it came from (source_type, url, monitor_id, relevance_score) — so you can judge it without opening the full note.

Working the queue

  • list_triage — brain_id. Returns every pending item on that brain, oldest first, lineage included.
  • promote_triage_item — note_id, optional edits (title / content_markdown / tags). Flips the note to promoted and triggers an immediate recompile for a DB-backed brain, so it's in the knowledge map right away. Use the edits to trim a raw hit down to what's actually worth keeping as part of promoting it.
  • promote_triage_items_batch — note_ids. Same effect, no per-item edits — call promote_triage_item individually when an item needs cleanup first.
  • dismiss_triage_item — note_id, optional reason. Flips the note to dismissed and archives it — a dismissed hit stops being a live note at all, not just excluded from the compile.
  • dismiss_triage_items_batch — note_ids, optional shared reason.
list_triage({ brain_id: "<uuid>" })
promote_triage_item({ note_id: "<uuid>", edits: { title: "Cleaner title" } })
dismiss_triage_item({ note_id: "<uuid>", reason: "not relevant" })

get_brain's response includes pending_triage_count, so an agent sees there's a queue waiting without calling list_triage speculatively.

What the compile actually does

A DB-backed brain's compile includes a note when triage_state is NULL (an ordinary note) or promoted. pending, dismissed, and expired are excluded. This only changes anything for a brain that has triage items at all — a brain that never receives one behaves exactly as before.

Known gap: only the compile is filtered. A pending note keeps status: active, so it can still surface in notes search/list tools and in a brain's note_count before anyone has decided whether it belongs. This is fine while the lane is used by hand; it's worth revisiting once 2/6 lands monitoring and pending items start arriving in volume.

Expiry

An item nobody promotes or dismisses doesn't wait forever. Each brain has its own triage_expiry_days (default 14, set via patch_brain). A daily job archives whatever is still pending past that window, marking it expired so the reason it left the compile stays visible on the note.

Related

  • Brain Task Reminders: a brain task is something a brain is waiting on from a person. Triage is different — it's content a brain is waiting to decide about.
Want this page as machine-readable markdown? GET /docs/features/brain-triage-lane.md