Record what a meeting decision does not decide

Record what a meeting decision does not decide. A durable entry should contain the choice, its reasoning, its scope and the most important exclusion, the nearby question that remains open.

Without that boundary, a sensible local decision travels. “Use the assisted onboarding path for the pilot” becomes “all customers require assisted onboarding.” “Keep the current retention period for launch” becomes “the retention policy can never change.” The record has preserved the sentence and lost the conditions that made it true.

A correct decision can be used incorrectly

Suppose a team is preparing a ten-company pilot. In the meeting, they decide:

We will onboard pilot customers with a guided setup call.

That may be the right decision. The pilot is small, the workflow is new and the team needs direct feedback.

Two months later, a colleague finds the entry while planning self-serve launch. The record says nothing about scope, so the colleague reasonably reads it as the company's onboarding model. A decision made for ten pilot companies has become a rule for every future customer.

Nobody misquoted the meeting. Nobody forgot the decision. The error entered through the empty space around it.

Add one sentence:

Scope: The first ten pilot companies during the October validation period.

Not decided: The onboarding path for self-serve customers after the pilot.

Now the future reader can use the decision without extending it.

Write the boundary in operational terms

“This is limited in scope” is not a boundary. Name the dimension that separates included from excluded cases.

Useful boundaries often describe:

• audience: pilot customers, internal users, enterprise accounts;
• product area: browser recording, not uploaded transcripts;
• geography: one market, not every operating region;
• time: this launch window, this quarter, the duration of an incident;
• workflow stage: review, not final approval;
• authority: a team implementation choice, not a company-wide policy.

Choose the dimension that would change someone's action. The pilot example needs an audience and time boundary. An incident workaround may need a product-area boundary and an expiry condition. A legal wording decision may need an authority boundary so it is not mistaken for a change in policy.

Avoid empty labels such as “temporary” or “for now.” Temporary until when? For now under which conditions? If the decision is conditional, give the condition an owner, deadline and fallback rather than leaving it as atmosphere. A conditional decision needs an expiry rule.

Separate exclusions from rejected alternatives

These two parts of a decision record answer different questions.

Rejected alternatives explain why the team chose this path inside the problem it considered.

We rejected fully self-serve onboarding for the pilot because the team needs direct observation of setup failures.

Exclusions identify a related problem the meeting did not decide.

We did not decide the onboarding path after the pilot.

Mixing them creates false certainty. If the record lists self-serve as “rejected” without the pilot boundary, a future reader may assume the option was evaluated and rejected for general launch. It was not.

Use three distinct lines:

Decision: Guided setup for the first ten pilot companies.

Reason: Direct observation is needed during workflow validation.

Open: Choose the post-pilot onboarding model after reviewing pilot evidence.

The open line does not weaken the decision. It protects the decision from claiming authority it never had.

Test the decision against three future readers

Before finalising the record, ask how three people might misuse it.

The adjacent team sees a familiar problem and assumes the decision applies to their workflow too.

The new joiner sees the conclusion but does not know which constraints were temporary.

The executive reader sees a local implementation choice and treats it as organisation-wide policy.

For each reader, complete this sentence:

This decision should not be used to conclude that…

If the answer would change real work, put the shortest version in the record.

For example:

• This does not set the onboarding model after the pilot.
• This does not change the retention policy for uploaded transcripts.
• This does not authorise customer communication before Legal review.

You do not need to list every hypothetical misunderstanding. Record the one or two overextensions that are both plausible and consequential.

Give the open question a destination

An exclusion should not become a hiding place for work the meeting avoided.

If the excluded question matters, decide where it goes:

• a named owner gathers the missing evidence;
• a later meeting decides after a trigger occurs;
• a different authority receives the question;
• the team explicitly closes it as out of scope.

In the pilot example:

Open question: Post-pilot onboarding model.

Owner: Mira gathers setup evidence from the ten pilot companies.

Return point: Product review after the tenth onboarding or on 30 October, whichever comes first.

This keeps the current decision firm while giving the unresolved part a legitimate path back. It also prevents “not decided” from being read as “not important.”

When the return point arrives, either make the broader decision or preserve the gap again with a reason. If the new decision replaces the old one, link the two records and state which one supersedes.

Keep the boundary beside the reasoning

A scope note buried in a follow-up message will drift away from the sentence it qualifies. Store the choice, reasoning, boundary and open question together.

That structure matters because people retrieve decisions by subject, not by remembering the conversation that produced them. A decision log earns its keep when a future reader can find the relevant constraint.

In Scripta, teams can keep decisions with the source meeting, minutes, action items, files and follow-up discussion. Use that connected record to preserve the source and later consequences. Scripta cannot infer the boundary the room never states; write it into the decision while the people who know the context are still present.

Use a five-line decision boundary

For decisions likely to travel beyond the room, write:

Decision: [the choice in active language].

Reason: [the constraint or evidence that made this choice appropriate].

Applies to: [the audience, product area, period or situation governed].

Does not decide: [the nearest consequential question left open].

Return point: [when, why or by whom the open question comes back].

This is not a larger decision template for its own sake. The last three lines exist only to stop a local choice from becoming an accidental universal rule.

Correct overreach without reopening the choice

Sometimes the misuse appears after the record is published. A colleague says, “I thought this applied to every account,” and the team realises the boundary was never written.

Do not reopen the underlying decision if the original choice still stands. Correct the record transparently:

Clarification added 30 September: This decision applies to the ten-company pilot only. The self-serve launch path remains open.

The clarification should narrow the interpretation, not rewrite history. If the meeting genuinely intended a company-wide rule, that is new information worth confirming with the decision owner. If the scope itself has changed, record a new decision rather than quietly expanding the old one.

A useful decision record helps the next person act without recreating the meeting. To do that, it must say not only “yes, this,” but also “here, under these conditions, and no further.”