Notifications

The notify.* family (2 verbs). Every verb enters through the one front door: it is capability-checked, permission-checked, scope-checked and audited before it runs (see Security & permissions). Each entry below lists its capability, risk class (which fixes the minimum autonomy level), the minimum caller permission, its availability tier, whether it is idempotent, and any outbound egress.

Sendnotify.send

Exactly one notification row lands in the recipient’s inbox (status=UNREAD). Idempotent-ish: a re-fired send for the same non-ARCHIVED (recipient, kind, subject) dedups to the existing row.

This is the ACTION-VERB a trigger dispatches (EPIC-TRIGGER: notify is a named trigger action). When a PRODUCER fires it as a side-effect of its own transition it must do so FIRE-AND-FORGET (INV-2) - see route_notification, the shared write path a producer calls on a separate committed tx so a notify failure never blocks/rolls back the source. The verb itself (this entrypoint) is a normal in-tx write: the AuditEvent is emitted by the dispatch (INV-8), the row commits atomically with it.

Input { recipientId, kind, subjectType?, subjectId?, title, body?, payload? } (fields ending in ? are optional)

Call POST /v/notify.send with a JSON body; returns JSON (or { error, code }). Also exposed as the MCP tool notify.send.

Taxonomynotify.taxonomy

([2026] CC-OPBOX 39): the fixed kind taxonomy + per-kind suppression lockability - the ONE render source for the preference matrix. Static (no store read).

Call POST /v/notify.taxonomy with a JSON body; returns JSON (or { error, code }). Also exposed as the MCP tool notify.taxonomy.