---
name: Inbox Topology - {{instance_name}}
description: Declared inbox-outbox pairs for {{instance_name}}. Each pair has typed entries, cadence, owners on both sides, and audit trail. Reduces cross-pod meetings; makes slow failures visible; provides the quarterly audit surface.
type: governance-artifact
populated_from: Q9 (ticketing/comms conventions), Q7 (instances), Q8 (cross-platform glue surfaces that produce inbox traffic)
---

# Inbox Topology - {{instance_name}}

- **Last reviewed:** {{capture_date}}
- **Review cadence:** quarterly + on-event when a new pair is declared or drained
- **Status:** active

## Maturity self-assessment

| Aspect | State | Evidence |
|--------|-------|----------|
| Inbox pairs declared | none / stubbed / partial / mature | ... |
| Each pair has typed entry schema | none / stubbed / partial / mature | ... |
| Each pair has named owners (both sides) | none / stubbed / partial / mature | ... |
| Each pair has drain cadence | none / stubbed / partial / mature | ... |
| Each pair shows recent drain evidence | none / stubbed / partial / mature | ... |

A mature inbox topology has every declared pair drained on cadence with audit trail. A partial topology has pairs declared but never drained; that is the silent-failure mode this discipline catches.

## Why declared pairs matter

Async work flows between sessions, projects, and tiers (operator-to-pod, pod-to-pod, ops-to-engineering, customer-to-product). Without declared inbox-outbox pairs, this work either:

- Happens in meetings that should have been async writeups
- Goes invisible until something breaks
- Lands in the wrong place because the path was never named

A declared pair has typed entries, dated, drained on a cadence, with audit trail. That is the discipline.

## Pair declaration template

For each inbox-outbox pair this deployment maintains:

```markdown
### Pair: {{from_pod}} -> {{to_pod}}

- **Inbox path:** `{{instance_name}}/inbox/from-{{from_pod}}.md`
- **Outbox path:** `{{from_pod}}/outbox/to-{{instance_name}}.md`
- **Typed entries:** {{entry_types}}
- **Cadence (drain):** {{cadence}}
- **Owner (this side):** {{owner_role}}
- **Owner (other side):** {{owner_role}}
- **Last drained:** {{date}}
- **Recent activity:** {{count_of_open_entries}} open / {{count_drained_this_quarter}} drained this quarter
- **Audit:** quarterly review confirms entries either resolved, escalated to ADR, or moved to BACKLOG
```

## Standard pair patterns to consider

These are common pair shapes worth declaring at deployment time:

- **Product -> Platform** (capability requests, failure patterns observed in 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 `{{instance_name}}` is `customer-facing-ai` or `b2b-platform` or `b2c-product`
- **Engineering -> Compliance** (privacy / regulatory reviews needed)
- **{{source_pod}} -> {{instance_name}}** (mirror sync events; populated only if L4 posture is `partial-internal`, `mature-internal-mirror`, `mature-external-mirror`, or `mirror-this-kit`)

Not every deployment needs every pattern. Declare the ones the function actually flows work through; mark `none-applicable` for the rest with one-line rationale.

## Declared pairs

[The deploy skill populates this section based on Q7 instances and Q8 cross-platform concerns. Each pair gets one block following the template above.]

### Pair: {{example_pair}}

[Block per template]

[More pairs follow]

## Drain protocol

For each entry in any inbox:

1. **Read** the entry; confirm it has the typed shape (date, source, type, state, priority, target close).
2. **Classify** the next move:
   - `acknowledge` - entry is informational; no action needed; state goes to `acknowledged`
   - `actioned-here` - resolved in this drain; named follow-up if any; state goes to `done`
   - `escalate-to-ADR` - decision required; ADR scaffolded; state goes to `escalated`
   - `move-to-BACKLOG` - work too large for drain; lands in `BACKLOG.md`; state goes to `parked`
3. **Update** the entry's state and date in the inbox file.
4. **Ping** the other side's owner if the resolution requires their action.

A drain that produces no state changes is suspicious; either no traffic arrived or the inbox is being read-only-glanced at. Both are findings.

## Audit posture

Every quarter:

- Count entries per pair: opened, drained, escalated, parked
- Identify pairs with zero traffic in a quarter (candidate for retirement)
- Identify pairs with backlog growing faster than drain (candidate for cadence increase or scope split)
- Cross-check `decisions/` for ADRs that should have come from inbox escalations but didn't

## Inheritance and dependencies

This inbox topology inherits from: org-level inbox conventions if any (e.g., a portfolio-level Inbox Flow standard).

This inbox topology is consumed by: every session log that drains an inbox; the quarterly review that audits the topology.

## Cross-references inside this instance

- `inbox/` - the actual inbox files this topology declares
- `policies/strategy.md` (L0) - the strategic context that determines which pairs are needed
- `BACKLOG.md` - destination for entries parked on drain
- `decisions/` - destination for entries escalated to ADR
- `sessions/` - drain events leave session log entries
