ADR 0022: Decisions waiting for you: inbox items, escalation and delegation limits

Status

Accepted

Date

2026-09-15

Deciders

Founder

Context

Approvals, questions, hand-offs and mentions reached people only through notifications and the thread they came from. A person with three programs and a twin needs one place that says what waits for them and lets them decide from a phone or an e-mail link without reading a private thread.

Decision

• inbox_items are transactional pointers created with their source (interrupt, approval, hand-off, mention, stage gate) and closed when the source resolves; kinds decision, signature, question, handoff, mention, information (R4 stage); every item carries “Why now”, age and the proposing twin.
• POST /me/inbox/{item_id}/resolve is the resolve path for the bound person and for delegates; it never requires reading the private thread. The program board shows persona columns of records, names only under program.twins.read.
• Escalation (decision_reminder, at most daily per item) goes only to holders of program.twins.read because it names a colleague’s pending decisions; recipients gain routing, not authority.
• Delegation: delegations rows, one hop, delegate must hold membership and the write’s own permission, at most 30 days with counted renewals, never for signatures or stage items (CHECK on the audit row), copy Routed under delegation from <Name>; decided by <Name> in their own right.

Consequences

• Per-person throughput appears only in the organisation audit export (named in the DPA and the validation package); program metrics aggregate by persona with by_user[] under program.twins.read.
• The daily brief (persona_brief) is a server-written artifact, not a model run; the e-mail carries record type, program name, id and link only.

Alternatives considered

• Approve by e-mail reply: an acting token in mail; rejected.
• Chained or open-ended delegation: privilege escalation; rejected.

Follow-ups

• Mobile push (later); chat-platform delivery stays designed.