---
name: architect-inbox-flow
description: >
  Declares and drains inbox-outbox pairs between pods. Operationalizes the typed-dated-cadenced
  entry pattern. Triggered when the operator says: "set up an inbox", "declare an inbox-outbox
  pair", "drain the inbox", "inbox flow", "what's in my inbox", "process inbox entries", "wire
  up async coordination between pods", "what should we be tracking from the other team". Each
  pair has typed entries, dated, cadenced, with named owners on both sides and audit trail.
  Refuses to declare a pair without naming both sides' owners.
---

# architect-inbox-flow

Declares and drains inbox-outbox pairs. Typed-dated-cadenced entries; named owners both sides; audit trail. Reduces meetings; makes slow failures visible.

## When to invoke

- Operator says: "set up an inbox", "declare an inbox-outbox pair", "drain the inbox", "inbox flow", "what's in my inbox", "process inbox entries", "wire up async coordination", "what should we be tracking from the other team"
- A new cross-pod relationship surfaces (e.g., a new dependency on the platform team)
- Scheduled cadence drain (e.g., weekly drain of sdr-team inbox)
- Quarterly inbox-topology audit

## Operating modes

### Mode A: Declare a new inbox-outbox pair

1. Ask (or infer): which pod is the source? which pod is the consumer? what types of entries flow? what cadence is expected?
2. Required information per pair:
   - Inbox path: `{this_instance_root}/inbox/from-{source_pod}.md`
   - Outbox path on other side: `{source_pod}/outbox/to-{this_instance_name}.md` (other pod owns; you reference)
   - Typed entry vocabulary (e.g., `kit-sync-event`, `capability-request`, `deprecation-notice`)
   - Drain cadence (weekly, biweekly, on-event, etc.)
   - Named owner on this side (a role; not "the team")
   - Named owner on other side (a role)
3. **Refusal:** if the other side's owner is unnamed, refuse to declare. "We will figure that out later" is the failure mode that produces declared-but-inactive inbox pairs that never drain. Either name the owner or hold off.
4. Add the pair to `{instance_root}/inbox-topology.md`'s "Declared pairs" section
5. Create `{instance_root}/inbox/from-{source_pod}.md` with frontmatter and the schema reference
6. Send an outbound declaration entry to the other side's inbox (if reachable) or coordinate via Slack / email; record the coordination in this side's first entry

### Mode B: Drain an existing inbox

1. Read the inbox file
2. For each open entry (state != `acknowledged` / `actioned-here` / `escalated` / `parked`):
   - Confirm typed shape (date, source, type, state, priority, target close)
   - Classify next move:
     - `acknowledge` - informational; state -> `acknowledged`
     - `actioned-here` - resolved in this drain; state -> `done`
     - `escalate-to-ADR` - decision required; scaffold ADR via `architect-adr` skill; state -> `escalated`
     - `move-to-BACKLOG` - work too large for drain; add BACKLOG entry; state -> `parked`
   - Update the entry's state and date in the inbox file
   - If resolution requires action by the other side: add a corresponding outbox entry
3. Move drained entries to the inbox file's "Drained this quarter" table at the bottom
4. Log the drain as a session log entry (via `architect-handoff` skill); name which entries were drained and how

### Mode C: Audit inbox topology

1. Walk every declared pair in `inbox-topology.md`
2. For each pair check:
   - Last drain date within cadence window?
   - Open entries growing or shrinking?
   - Both sides' owners still named and reachable?
   - Pair still useful (any traffic in last quarter)?
3. Output:
   - Pairs healthy
   - Pairs overdue for drain (cadence exceeded)
   - Pairs with growing backlog (drain rate < arrival rate)
   - Pairs with zero traffic (candidates for retirement)
   - Pairs with stale owner names (need refresh)
4. Update `inbox-topology.md`'s "Audit posture" section with findings

## Drain refusal

A drain that produces no state changes is a finding, not a no-op. Either:

- Truly no traffic since last drain (recordable as a healthy state if the pair is low-volume by design)
- Inbox was glanced at without classification (silent skip; the failure mode this discipline catches)

In the second case, refuse to mark the drain complete; surface as a finding to the operator.

## Standard pair patterns to consider

These shapes are common enough to suggest by default:

- **Product -> Platform** (capability requests, failure patterns from production)
- **Platform -> Product** (deprecations, kit upgrades, new capabilities)
- **Ops -> Engineering** (regression alerts, drift flags, red-team findings)
- **Customer -> Product** (failure modes, UX issues, trust incidents) - applies if the function has external surface
- **Engineering -> Compliance** (privacy / regulatory reviews needed)
- **{source_pod} -> {this_instance}** for any L4 mirror posture other than `greenfield`

The skill does not pre-declare these; it asks if the operator wants any of them when running Mode A.

## Cross-references inside the kit

- `BOOTSTRAP-BRIEF.md` Section IX - concurrent-session protocol (inbox is the cross-pod coordination surface)
- `templates/inbox-topology.md` - the topology template
- `examples/martech-mature-instance/inbox-topology.md` - reference example with four declared pairs
- `examples/martech-mature-instance/inbox/from-platform-team.md`, `inbox/from-sdr-team.md` - reference inbox files
- `skills/deploy/SKILL.md` - the deploy skill scaffolds the initial inbox-topology
- `skills/architect-handoff/SKILL.md` - paired when a drain produces a session log
- `skills/architect-adr/SKILL.md` - paired when an entry escalates to ADR
