Async Decision Log¶
Tool or artifact — instantiates Coordination Scaffold Load Control
Replaces standing status and decision meetings with a durable written record — each decision captured with its rationale, owner, and the artifact it governs — so coordination happens by reading, not by convening.
An Async Decision Log is a durable, append-only record in which each non-trivial decision is captured the moment it is made — the question, the options weighed, the choice, who made it, and the system or artifact it governs — so that communicating a decision, and defending it later, no longer requires assembling people in a room. Its defining idea is substitution: it trades a read-once artifact for the recurring synchronous coordination — status meetings, "let me loop everyone in," the third re-litigation of a settled question — that a decision would otherwise keep generating. It is a record of decisions taken, not a map of who is allowed to take them.
Example¶
A remote-first software team is spread across eight time zones, and no single hour catches everyone awake. They keep an ADR-style decision log in the code repository: one Markdown file per decision, committed alongside the change it justifies. A proposal lands to swap the message broker from one queue technology to another. Instead of scheduling a synchronous design review that half the team would miss, the proposer opens an entry — context, the two options, the choice, the owning engineer, the date, and the services affected — and leaves a 48-hour async comment window. Reviewers weigh in on their own clocks; the entry is amended, then marked accepted.
The outcome shows up months later. A newly hired engineer asks why the team runs the broker it does rather than the more fashionable alternative. The answer is a single link, not a rehashing meeting and not a slow-motion thread reconstructing memory. A coordination cost that would otherwise have surfaced as a recurring standup topic — and re-surfaced every time a newcomer arrived — has collapsed into a read.
How it works¶
The log is append-only and one-decision-per-entry: superseded decisions are never deleted, only linked forward to the entry that replaced them, so the reasoning chain stays intact. Every entry names two things a passing note omits — the person who held the authority to decide, and the concrete artifact or system the decision governs. Entries are searchable and live next to the work, not in a separate meeting-minutes silo. The distinguishing move is decoupling the decision from the meeting: the log lets a decision be made, communicated, and audited on three different clocks instead of forcing them into one shared hour.
Tuning parameters¶
- Entry threshold — how consequential a decision must be to warrant an entry. Lower it and the log captures more institutional memory but risks drowning in trivia; raise it and it stays lean but loses the small decisions that quietly matter later.
- Rationale depth — how much "why" each entry must carry. Richer entries survive personnel turnover; heavier entries slow the writer and discourage logging at all.
- Review window — the length of the async comment period before an entry is settled. Longer windows widen participation; shorter ones keep decisions from stalling.
- Curation ownership — who keeps the log coherent and prunes dead entries. Naming an owner prevents rot; over-owning it recreates a gatekeeper.
- Artifact linkage — how tightly each entry is bound to the code, ticket, or document it governs. Tight linkage makes the log navigable; loose linkage lets it drift into a write-only archive.
When it helps, and when it misleads¶
Its strength is killing re-litigation and the status meeting whose only product is shared awareness: a decision written once is a decision that need not be re-explained. It onboards newcomers cheaply and, over time, makes the team's real authority boundaries legible — you can see who has been deciding what. The lineage generalizes the Architecture Decision Record from architecture to any coordination decision.[1]
Its failure mode is log rot: a write-only archive nobody reads is pure metawork, the very overhead the mechanism exists to cut. A subtler misuse is turning the log into an approval gate — requiring sign-off on every entry — which quietly rebuilds the synchronous coordination it was meant to remove, now with a paper trail. The guarding discipline is to log outcomes, not permission: keep entries cheap to write, treat the log as a record of what was decided rather than a queue for approving it, and periodically confirm entries are actually being read.
How it implements the components¶
artifact_decision_trace— each entry ties a decision to its rationale and to the artifact it governs; the log is the trace, made durable and searchable.decision_authority_boundary— every entry names who was authorized to make that call, so the de facto boundary of authority becomes visible in the accumulated record.
It records decisions but neither draws the authority map nor watches for exceptions: local_autonomy_envelope and coordination_burden_owner are defined by delegation_authority_matrix, and exception_trigger_model belongs to exception_based_oversight. This log is the trace of decisions made within those boundaries, not the boundaries themselves.
Related¶
- Instantiates: Coordination Scaffold Load Control — supplies the durable record that lets coordination happen asynchronously instead of in standing meetings.
- Consumes: delegation_authority_matrix — each logged decision is made within the authority that matrix grants; the log records the exercise, the matrix defines the right.
- Sibling mechanisms: coordination_artifact_kill_switch · coordination_load_audit · delegation_authority_matrix · exception_based_oversight · governance_forum_consolidation · handoff_path_pruning · meeting_budget · support_layer_sunset_review · work_before_metawork_ratio_dashboard
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Replaces standing status and decision meetings with a durable written record — each decision captured with its rationale, owner, and the artifact it governs — so coordination happens by reading, not by convening, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Async Decision Log as 'Replaces standing status and decision meetings with a durable written record — each decision captured with its rationale, owner, and the artifact it governs — so coordination happens by reading, not by convening', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Distributed-work management developed durable decision logs and decision records as substitutes for synchronous coordination meetings.
Related originating lineages:
- Computer Science & Software Engineering — Software architecture decision records supply the structured rationale, owner, and governed-artifact format.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
The append-and-supersede rule is load-bearing: deleting a reversed decision destroys exactly the reasoning a future reader needs, so the log grows monotonically and reversals are recorded as new entries pointing back. A log that lets entries be edited in place looks tidier but loses its value as a trace.
References¶
[1] Architecture Decision Record — a lightweight document capturing a single decision, its context, and its consequences, introduced by Michael Nygard in 2011; the async decision log generalizes the ADR beyond architecture to any coordination decision worth a durable record. withdrawn registry ↩