Status doesn't live in a chat.
It propagates.

The shape of it

One source of truth, four surfaces

The Postgres database is the only place that is the truth. Loop, ADO and Teams are projections of it — convenient windows for humans. Nothing is "logged to Loop" as a primary record; Loop reflects a row that already exists in the database.

Surface 1 — the database

The system of record wired

Every brief, decision, risk, comms draft and prep doc is a row in the haleon schema before it is anything else. Status is a column, not a message: a comms draft sits at awaiting_signoff; an ADR's status is one of proposed → accepted → superseded/rejected (the finer Reviewer/Compliance lifecycle stages are a procedural workflow, not values of adrs.status — see Open Issues); a write-back op carries an explicit status enum. Because the row exists first, the audit trail is a side-effect of doing the work, not a separate logging step.

Surface 2 — Loop

Human-readable status to Loop partial

Loop is where Charlie's wider audience reads status in prose. It is a Chief-of-Staff function, tied to briefs and ceremony prep documents — not a standalone "Loop logger" agent. The database backs the link directly:

So "status to Loop" means the CoS writing brief/prep content and flagging delivery — not a separate heartbeat. The exact firing cadence lives in the daily-brief and prep skill files; confirm there before relying on it.

Surface 3 — Azure DevOps

The ADO write-back queue enqueue wired drain built

The ring keeps ADO up to date through an enqueue-then-drain pattern rather than writing to the board directly: any agent that wants to change a work item appends an operation to a queue table at pending_approval; Charlie's approval flips it to queued; the ado-scribe drainer (built Batch 2) consumes only queued rows and applies them to ADO via the wit_* MCP tools, advancing each row through the CAS-guarded sp_update_ado_writeback state machine.

The enqueue path fully built & proven

A write travels: DAB entity AdoWritebackIn → view haleon.v_ado_writeback_in → INSTEAD OF INSERT trigger → haleon.sp_create_ado_writeback(…) → INSERT into the queue at status='pending_approval' (gate-by-default) with ON CONFLICT (idempotency_key) DO NOTHING.

-- one row per pending ADO change (idempotency_key UNIQUE)
id                  uuid        -- gen_random_uuid()
idempotency_key     text        -- UNIQUE → ON CONFLICT DO NOTHING
target_work_item_id bigint
operation           text        -- e.g. add-comment, set-state
payload             jsonb       -- the change body; left UNCHANGED on status-only updates
status              ado_writeback_status   -- enum, DEFAULT 'pending_approval'
                                -- = {pending_approval, queued, in_flight, committed, failed}
attempts            int         -- incremented on *→in_flight; cap=5
last_attempt_at     timestamptz
last_error          text        -- cleared on failed→queued retry as hygiene
committed_at        timestamptz
approved_by         text        -- set on pending_approval→queued (Charlie); RAISE if NULL
approved_at         timestamptz
enqueued_by_agent   text
-- INDEX idx_ado_q_status (status, enqueued_at)  ← drives drainer FIFO

The drain path built Batch 2

The ado-scribe drainer is live as an on-demand CoS skill; its 15-minute cadence is the declared intent for core-tick step 4 and will activate when Charlie enables the recurring ring-tick timer. One tick acquires the single-holder drainer_lease (re-entrant same-holder CAS; renew at TTL/2; abort immediately on lost re-acquire), reclassifies failed rows (transient → re-queue capped at MAX_ATTEMPTS=5; permanent → dead-letter; rescue via sp_reset_ado_writeback), reconciles stale in_flight against ADO using an invisible <!-- idk:KEY --> marker (required for every op — field-set AND add-comment — so an external setter can't produce a false commit), selects queued with per-target serialisation, claims queued → in_flight → committed/failed via CAS-guarded UPDATE. A lost CAS race returns no row = silent skip, never a double-write.

Surface 4 — Teams & the internal audit

Acks, briefs, and the agent_runs trail

Surface 5 — Scouts & the cadence substrate

Scout audit footprint & the 3-greens DB gate built recurring schedule deferred

When ring-tick's recurring cadence is enabled (Charlie's posture call), each scout-sweep tick spawns up to five scouts under a shared scout_lease. Every scout writes its own two-phase agent_runs row with class='scout_sweep', enqueues observations to signals through the idempotent sp_create_signal (K1: never NULL, never 23505; partial unique index signals_source_extid_uq is the DB-side backstop), and advances its watermark via ScoutWatermarkIn only after every enqueue in the unit-of-progress succeeds.

Be honest about the gaps

What is not wired yet

See how the database and MCP layer are configured →