Decisions get made in Slack and email, never written down, then reopened weeks later. We define what counts as a decision and where the log lives — and AI drafts each record for a person to confirm. The log becomes the single source the team trusts.
Common pain points
Decisions are made inside threads, so once the thread scrolls the decision and its reasoning are effectively gone.
Nobody agreed what counts as a decision, so some get recorded, most don't, and there is no line between a decision and a passing comment.
A decision has no owner and no date, so it is unclear who is accountable or when it takes effect.
Weeks later the same question comes back, and with no record the team re-litigates a call it already made.
When someone asks why a decision was made, the reasoning lives in someone's memory, not in a record anyone can read.
Meeting notes capture what was said, not what was decided, so the decisions are buried in pages of discussion.
A decision capture system defines what counts as a decision for your team, who owns recording it, and where the log lives. AI watches the channels you agree on and drafts a decision record — what was decided, who owns it, when it takes effect, why, and whether it can be reversed — for a person to confirm. The log is the single source; the decision and the confirmation stay with a person.
How we work
We define what counts as a decision for your team, who records it, and where the log lives — agreed with the people who make the calls.
We connect AI to the channels you agree on to draft each decision record in the schema, and flag threads that decided something with no record.
We set the rule for how a recorded decision is reopened and by whom, and hand over a runbook the team operates and edits.
What we build
Area 1
We design the structure of the log: the fields every decision carries — what was decided, owner, date, reasoning, reversible? — and where the log lives inside the tools you already use. The structure is the same for every decision, so the log is scannable and a new person can read it without a tour.
Deliverable
A decision-log structure: the required fields per decision and its location inside the team's existing tools.
Area 2
We write what counts as a decision for your team — the line between a decision and a discussion — and who is responsible for recording each type. The rules are agreed with the people who make the calls, so the criteria are shared, not imposed.
Deliverable
A written capture rule set: what qualifies as a decision, by type, and the named owner who records each.
Area 3
We connect AI to the channels you agree on. It drafts each decision record in the agreed schema and flags threads where a decision was made with no record. What AI may draft and what it may never do — record a decision a person has not confirmed — is written down. AI drafts; a person confirms.
Deliverable
An AI-draft to human-confirm flow with the written limit: AI drafts the record, a named person confirms before it enters the log.
Area 4
Not every message is a decision. We define, with examples, how to tell a decision from a discussion, a proposal, or a passing comment — so the log fills with real decisions and not noise. The classifier is a shared rule, not an AI guess the team cannot check.
Deliverable
A decision-versus-discussion rule with worked examples of the edge cases that confuse the most.
Area 5
A recorded decision should not be quietly re-argued. We define how a decision is formally reopened — who can, on what grounds, and how the change is recorded — so the team stops re-deciding settled calls by attrition and starts reopening them on purpose.
Deliverable
A re-litigation rule: who can reopen a recorded decision, on what grounds, and how the change is logged.
Area 6
We hand the system over as a runbook: the log structure, the capture rules, the classifier, the AI limits, and the re-litigation guard. The goal is for the system to live without us — the team can keep the log, adjust the rules when the work changes, and bring a new owner up to speed without rebuilding it.
Deliverable
A runbook with the log structure, capture rules, classifier, AI limits, and the re-litigation guard the team owns.
Every real decision has a record with an owner, a date, and the reasoning, so "what did we decide?" has an answer anyone can read.
The line between a decision and a discussion is written down, so the log fills with decisions, not chatter.
AI drafts each record from the channels you already use, and a person confirms — so capture does not depend on someone remembering to write it up.
Reopening a decision is a deliberate, recorded act, so the team stops re-litigating settled calls by accident.
The reasoning behind a decision lives in the log, not in one person's memory, so it survives that person being away or leaving.
The rules, the classifier, and the log live in a runbook the team operates and edits, not in the consultant's head.
No. A notetaker records what was said; this records what was decided — with an owner, a date, the reasoning, and whether it can be reversed. Meeting notes bury decisions inside pages of discussion; a decision log is the short, scannable record of the calls themselves, kept in one place.
No. AI drafts the record of a decision a person has already made, in the agreed schema, and flags threads that decided something with no record. A person confirms every record before it enters the log. The line between drafting and deciding is written into the system.
Inside the tools you already use, by default — a database, a doc, a wiki, whatever the team already opens. We do not sell or build a decision-log platform. If a specific tool would genuinely help, we will say so without a referral fee.
A wiki is a place; this is a system. The difference is the capture rules, the named owner, and the AI-draft-to-confirm flow that keeps the log current without depending on discipline. A wiki goes stale because nobody owns it; a decision log stays current because recording is part of the flow.
The re-litigation guard: a written rule for who can reopen a recorded decision, on what grounds, and how the change is logged. It does not stop people from changing their minds — it makes reopening a decision a deliberate, recorded act instead of a quiet re-argument that wastes the team's time.
It does not include a project-management tool, a wiki or knowledge-base build, an AI that makes decisions for the team, or a policy on how decisions should be made. It also does not include change-management or facilitation training. If what you need is one of those, we will tell you and point you to the right partner.
Three months on, nobody remembers why you decided something — and you're about to re-decide it, maybe contradicting a call from Q2. We build the living trail…
Read moreOperating cadenceMeetings multiply because there is no rule for which conversations need to be live. We classify each recurring meeting and move status to a written async cad…
Read moreOperating cadenceSomeone spends hours every week copying numbers into a status report — and the figures still don't match. We define the source-of-truth fields and the cadenc…
Read moreBook a 30-minute call to look at where your decisions are getting lost. We will talk through what counts as a decision for your team, where they are made today, and what a log the team can actually keep would look like. If the real problem is how decisions are made rather than recorded, we will tell you and point you to the work that fits.
Book a 30-min call