Concepts

Alerts

Buzo fires two SDK-driven alerts when your agent interacts with content it has already flagged for review: SERVED_FLAGGED and CITED_FLAGGED. The difference is the strength of evidence.

SERVED_FLAGGED

Fires when a retrieval trace returns a vector whose fragment is currently QUARANTINED and has not been user-approved. Detection runs on a short cadence over the retrieval-traces table, so alerts typically reach you a few minutes after the retrieval.

Requires the Buzo SDK to be instrumenting your retriever — LangChain callback, a wrap() call, or a direct recordRetrieval call. Nothing else to configure.

Signal strength: exposure. The flagged vector was returned into the agent's context, but Buzo doesn't know whether the LLM used it in the final response.

CITED_FLAGGED

Fires when the content of a quarantined vector actually appears inside the LLM's generation output — verbatim substring, or n-gram overlap above the paraphrase threshold. This is the strictly stronger signal: not just exposure, evidence.

Requires both retrieval instrumentation and output capture enabled:

  • Set outputCapture to 'redacted' or 'plaintext' on the Buzo client (default is 'off') — see Capture modes.
  • Stamp a shared correlation id — parentQueryId on recordRetrieval and the same value as runId (or parentRunId) on recordGeneration. The LangChain callback handler does this for you automatically via LangChain's run tree.

Without output capture, SERVED_FLAGGED will still fire — CITED_FLAGGED simply has nothing to match against.

Coverage. With the default resultsCapture: 'ids-only', citations are detected only for vectors Buzo has a stored content_snapshot for (typically the scanned subset of the corpus). Setting resultsCapture to 'plaintext' or 'redacted' extends detection to every retrieved vector by shipping its content alongside the id — see Capture modes.

Delivery channels

AlertEmailSlack / Teams webhook
SERVED_FLAGGEDYes — sent to admin recipients for the org.Yes — if SLACK_WEBHOOK_URL / TEAMS_WEBHOOK_URL are configured.
CITED_FLAGGEDNot yet — webhook-only today. Email template is on the roadmap.Yes — same webhook configuration as above.

Deduplication

Alerts are throttled so a single flagged vector served thousands of times per hour doesn't bury your inbox.

  • SERVED_FLAGGED email throttle: one email per(organization, vector, hour). Additional retrievals inside the same hour still show up in the audit log and still increment vector_read_counts, but no new email is sent.
  • CITED_FLAGGED dedup: at most one alert per(organization, vector, generation). Each new generation event that cites the same vector fires its own alert.

Responding to an alert

Both alert types link back to the affected vector in your Buzo dashboard. From there you have two reversible actions:

  • Mark as verified — the vector stays in your store but is no longer flagged. Future retrievals won't fire new alerts unless Buzo re-flags it on a later scan.
  • Remove from database — executes a delete against your vector store and captures a snapshot so you can restore within the retention window. Requires typing REMOVE to confirm.

Every action is recorded in the tamper-evident audit chain — nothing destructive happens without an explicit human action.

Relationship between the two alerts. SERVED_FLAGGED is a superset of CITED_FLAGGED — every citation first required a retrieval. Expect to see more SERVED_FLAGGED volume than CITED_FLAGGED in your feed. Treat CITED_FLAGGED as the high-priority signal.