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, optionaledits(title/content_markdown/tags). Flips the note topromotedand triggers an immediate recompile for a DB-backed brain, so it's in the knowledge map right away. Use theeditsto 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 — callpromote_triage_itemindividually when an item needs cleanup first.dismiss_triage_item—note_id, optionalreason. Flips the note todismissedand 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 sharedreason.
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.