Decision Making — Skills

Option Comparison & Trade-off Analysis

Compares the options on the table against criteria someone else weighted — scoring only where there is evidence, and naming what would change the answer.

Deliverable

One Markdown document, option-comparison.md, in the structure set out under Output below. It is the input to Decision Record Authoring.

Required inputs

The decision to be made — stated as a question with exactly one answer, with who asked it and when.
The options on the table — at least two, each separately choosable.
The criteria that matter, with their weights — supplied by the requester, not chosen here.

If any of the three is absent, stop and report it. Never invent a criterion or a weight: a weight the skill chose is the skill deciding, dressed as analysis.

Optional inputs

Evidence for any option: measurements, trials, references, vendor documentation
Constraints that rule an option in or out: budget ceiling, deadline, regulation, contract
The people affected by each option, and who must agree
Options already rejected before this comparison, and why
The date by which the decision must be made, and what is lost by missing it

Each absent optional input leaves its cell unscored rather than estimated; the matrix carries the gap and names the evidence that would close it.

Execution

1 — Restate the decision as a question. Write the decision as a single question with exactly one answer, with its source and date. If the question can only be stated by naming one of the options, the decision has already been made elsewhere — write that down and continue.

2 — Fix the option set. One line per option, with what choosing it commits to. Include the option of doing nothing, because it is always available. Merge duplicates. Options that a supplied constraint rules out move to a separate list beside the constraint that ruled them out.

3 — Record criteria and weights as supplied. Copy each criterion and its weight verbatim, with who supplied it and when. A criterion with no weight is listed unweighted; the skill does not assign one.

4 — Score only where there is evidence. For each option-criterion pair: a score and the evidence that supports it, with its source. A pair with no evidence is marked unscored and never given a number. An unscored cell is information, not a hole to fill.

5 — Assemble the matrix. One line per option: the score for each criterion in order, or unscored, and the weighted total computed only from scored criteria. State how many criteria each total covers, because a high total over few criteria is not a high total.

6 — Name the recommendation and its sensitivity. The option the scored evidence supports, and the criteria whose change of weight would flip it. If a small change in one weight changes the answer, the decision rests on that weight and not on the evidence.

7 — State what would change the recommendation. For each unscored cell and each contested weight: the evidence that would settle it, who can produce it, and what getting it would take. Order by how far the answer would move.

Output

option-comparison.md, in this order:

1. Decision — the question, who asked it, when, and the date it must be answered by
2. Options — one line each: name, what choosing it commits to, who proposed it
3. Criteria and weights — criterion, weight, who supplied it, when; unweighted where none was given
4. Scores — one line per option and criterion: the score or unscored, and the evidence with its source
5. Matrix — one line per option: the scores in criteria order, the weighted total, and how many criteria that total covers
6. Recommendation — the option, what the evidence supports, and what it does not
7. Sensitivity — the criteria and weights whose change flips the recommendation
8. Evidence that would change the answer — what is missing, who can produce it, what it would take
9. Rejected before scoring — options excluded by a constraint, with the constraint and its source

Validation

The comparison is ready when all of these hold:

Section 1 states a question, not a preference
Every option in section 2 appears in section 5, including doing nothing
Every weight in section 3 names who supplied it; none was chosen by the skill
Every score in section 4 carries evidence with a source; every cell without evidence reads unscored
Section 5 states, per option, how many criteria its total covers
Section 7 is non-empty, or states that no single change of weight flips the recommendation

Fail the run if any cell carries a number without evidence, or if a weight appears that no named person supplied.

Failure handling

Only one option supplied — add doing nothing as the second option and say so plainly. If the requester rejects that pairing, stop: a single option is a proposal, not a decision.
No weights supplied — produce sections 1 to 5 with every criterion unweighted, report the scores criterion by criterion with no total, and name who must set the weights. Do not total unweighted criteria.
No access to the evidence — mark every affected cell unscored, deliver the matrix with its gaps visible, and state that no option was compared on those criteria.
Contradictory evidence for one cell — record both, name both sources, mark the cell contested and raise it in section 8. Do not average them.
Partial material — score what the evidence supports, mark the rest unscored, and deliver. A matrix with honest gaps supports a decision; a full one built on guesses conceals who made it.

Download .md

Decision Record Authoring

Turns a decision that has been made into a record the next reader can judge without having been in the room.

Deliverable

One Markdown document, decision-record.md, in the structure set out under Output below. It takes the matrix from Option Comparison & Trade-off Analysis and feeds Post-Decision Review.

Required inputs

The decision that was made — in one sentence, in the words of whoever made it.
The context that forced it — what was happening that made a decision necessary.
The alternatives that were rejected — at least one, with who rejected it.

If any of the three is absent, stop and report it. A record written without the rejected alternatives documents an outcome rather than a decision, and the next reader cannot tell whether the option they are about to raise was already considered.

Optional inputs

The comparison that preceded it, if one exists — option-comparison.md is the expected form
The people who were consulted, and the position each held
Constraints that narrowed the field: budget, deadline, regulation, contract, existing systems
The consequences the decider accepted knowingly
The date, event or measurement that should trigger a review

Absent optional inputs are recorded as gaps in the record itself, each naming who could fill it. The record is still issued: a decision with an incomplete record is better documented than a decision with none.

Execution

1 — Fix the decision in one sentence. What was decided, who decided it, and on what date. A sentence that describes a direction rather than a choice is not a decision: ask for the choice, and record the direction as context.

2 — Write the context that forced it. What was happening, what it was costing, and why the decision could not be deferred. Context is what a later reader needs in order to judge whether the decision still applies. Keep it to what the inputs state.

3 — Set the status. proposed, accepted, superseded or reverted, with the date it entered that status and who put it there. A record whose status nobody set is proposed, whatever the surrounding conversation implies.

4 — Carry the alternatives across. Each rejected alternative with what it would have given, why it was not chosen, and who rejected it. Where a comparison exists, take the reasons from it rather than restating them from memory; a reason that contradicts the comparison is a discrepancy and is flagged as one.

5 — Record the consequences accepted. What the decision makes harder, slower, more expensive or impossible, and who carries each one. Separate consequences accepted knowingly from consequences discovered since. A record that lists only benefits was written to defend the decision.

6 — Name the revisit conditions. The specific fact, event or measurement whose change should reopen this decision, and who is watching for it. A record with no revisit condition becomes permanent by neglect.

7 — Link the record to what it binds. The work, documents and other records this decision governs, and any record it supersedes. A superseded record is marked as superseded, never deleted.

Output

decision-record.md, in this order:

1. Title and identifier — the decision in one line, with the date it was made
2. Status — proposed, accepted, superseded or reverted, with the date and who set it
3. Context — what forced the decision, and what deferring it would have cost
4. Decision — what was decided, by whom, and on what authority
5. Alternatives rejected — one line each: the alternative, what it offered, why it lost, who rejected it
6. Consequences accepted — what becomes harder, slower or impossible, and who carries it
7. Revisit conditions — the fact, event or measurement whose change reopens this
8. Bound work and records — what this decision governs, and any record it supersedes
9. Gaps — what the record could not establish, and who can supply it

Validation

The record is ready when all of these hold:

Section 4 names a decider and an authority, not a group with no name in it
Section 5 lists at least one rejected alternative with a reason
Section 2 carries a status and the date it was set
Section 6 names at least one consequence that is not a benefit
Section 7 names a condition someone could observe, not a change of circumstances in general
Every statement in sections 3 to 6 traces to an input, with its source

Fail the run if the record lists no rejected alternative, or if section 6 contains only benefits.

Failure handling

No alternatives supplied — stop. Report that a record with no rejected alternatives cannot be told apart from an announcement, and name who can list them.
The decider is not identified — issue the record with section 4 marked DECIDER UNRECORDED and raise it in section 9. Record the person who reported the decision, and state plainly that they are the reporter and not the decider.
No access to the comparison that preceded it — write the record from what was supplied, mark section 5 reasons as reported, and state that they were not checked against a comparison.
The stated reasons contradict the comparison — record both, name both sources, and raise the discrepancy in section 9. Do not quietly prefer the later account.
Partial material — issue the record with every section the inputs support and the rest marked INCOMPLETE — pending <question>. An incomplete record written now is worth more than a complete one written from memory later.

Download .md

Assumption & Evidence Audit

Separates what a document has evidence for from what it is assuming, and ranks the assumptions by what they would cost if they are wrong.

Deliverable

One Markdown document, assumption-register.md, in the structure set out under Output below. It feeds Reversibility & Blast Radius Assessment and any record written about the decision it audited.

Required inputs

The document to audit — a plan, a proposal or a decision record. Its statements are the unit of work.
The decision or commitment it supports — what the assumptions are load-bearing for.
The people whose statements the document carries — named, so a confidence can be asked for rather than invented.

If the document or the commitment it supports is absent, stop and report it. If the people are named but cannot be reached, proceed with every confidence marked unstated; the audit never supplies a confidence of its own, because an invented confidence is indistinguishable, later, from one a person gave.

Optional inputs

The source material the document cites: measurements, transcripts, contracts, tickets, logs
Earlier versions of the same document, and what changed between them
The people who would be affected if a given assumption is wrong
The budget or time available for testing assumptions
Assumptions already tested elsewhere, with their results

Absent optional inputs do not stop the audit. Each becomes a line saying what could not be checked and who holds the material that would check it.

Execution

1 — Split the document into statements. One line per claim the document makes. A sentence carrying two claims becomes two lines; a claim spread across several paragraphs is recorded once, with every place it appears.

2 — Classify each statement. evidenced when a source was supplied that a reader could go and check, assumed when it was not, contested when the supplied sources disagree. A statement everyone agrees with and nobody has measured is assumed — agreement is not evidence.

3 — Attach the source to every evidenced statement. What the evidence is, where it lives, its date, and who produced it. Evidence whose location cannot be handed back to a reader is downgraded to assumed, and the downgrade is recorded with its reason.

4 — Record each confidence as its holder stated it. For every assumption: who holds it, and the confidence they state, in their words. Where nobody was asked, write unstated. The audit assigns no confidence of its own, at any point, for any reason.

5 — Establish what is load-bearing. For each assumption: what fails if it is wrong, how far that failure reaches, and whether the commitment can proceed without it. Rank the register by that cost rather than by likelihood — a cheap certainty matters less than an expensive maybe.

6 — Define the cheapest test. For each assumption in rank order: the smallest action that would confirm or refute it, who can run it, and what it needs. Where no action would settle it before the commitment is made, write untestable before commitment and say so plainly.

7 — Report back to the document. List the statements the audited document should change: downgrades, missing sources, contested claims. Return them as edits for its author to make. Never edit the audited document from inside the audit.

Output

assumption-register.md, in this order:

1. Document audited — what it is, its version or date, and who wrote it
2. Evidenced statements — statement, evidence, where it lives, its date, who produced it
3. Assumptions — in rank order: statement, who holds it, the confidence they stated or unstated
4. Load-bearing analysis — per assumption: what fails if it is wrong, how far it reaches, whether the commitment can proceed without it
5. Tests — per assumption: the cheapest action that would settle it, who can run it, what it needs
6. Contested statements — the claim, each source, and what they disagree about
7. Untestable assumptions — those that cannot be settled before the commitment, and what that means for it
8. Edits requested — the changes the audited document needs, one line each
9. What could not be checked — material that was not available, and who holds it

Validation

The register is ready when all of these hold:

Every statement in the audited document appears once, in section 2, 3 or 6
Every evidenced statement names a source a reader could go and check
Every confidence in section 3 is attributed to a person, or reads unstated
Section 3 is ordered by the cost in section 4, not by likelihood
Every assumption in section 3 has a line in section 5 or in section 7
No confidence, likelihood or cost figure appears that no input supplied

Fail the run if the audit assigns a confidence nobody stated, or if a statement of the audited document is missing from the register.

Failure handling

No document supplied — stop. Report that the audit has no input, and that a register cannot be assembled from a conversation about a document.
The named people cannot be reached — audit the document as written, mark every confidence unstated, and list in section 9 who must supply them before the register is used to commit anything.
No access to the cited sources — classify on what the document itself provides, downgrade every uncheckable citation to assumed, and state in section 9 that no citation was verified.
Sources contradict each other — record both in section 6 with both names, and do not choose. A contested statement is a finding, not untidiness to be resolved.
Partial material — register what the material supports, mark the rest NOT AUDITED — pending <material>, and deliver.

Download .md

Reversibility & Blast Radius Assessment

Classifies a proposed change by what it would cost to undo and how far it reaches — and sets the scrutiny accordingly, in both directions.

Deliverable

One Markdown document, reversibility-assessment.md, in the structure set out under Output below. Its classification and rollback plan go into Decision Record Authoring.

Required inputs

The proposed decision or change — what would be done, stated concretely enough to be undone.
What it touches — the systems, data, people, contracts and commitments in reach, as supplied rather than inferred.
The state before the change — what would have to be restored for the change to count as undone.

If any of the three is absent, stop and report it. Never infer the reach of a change from the change itself: what a change touches is a property of the environment, and the environment has to be described by someone who can see it.

Optional inputs

The stages the change passes through: release, migration, announcement, signature, public commitment
Existing rollback tooling, backups, feature flags or contractual exit clauses
Who would have to be told if the change were undone
Earlier attempts to reverse a comparable change, and what they cost
The deadline the decision is under, and what is lost by delaying it

Where no stage list is supplied, the assessment treats the change as a single stage and says so. Where rollback tooling is unknown, the rollback plan is written as manual and unverified. Neither gap is filled with an assumption about what exists.

Execution

1 — State the change as an action that could be undone. One sentence, in the form of the thing a person would have to reverse. A change that cannot be phrased that way — an announcement, a published commitment, a message sent — is already partly irreversible, and that is the first finding.

2 — Classify reversibility. reversible when undoing restores the prior state, costly when it restores it at a price someone must pay, partial when some effects persist, irreversible when they all do. Classify from what the inputs state about tooling and commitments, not from how large the change feels.

3 — Map what it touches. One line per system, data store, team, customer group, contract or public commitment in reach. Mark each direct where the change acts on it, or indirect where it acts through something else. Anything nobody supplied is not on the map; it is in the gaps section.

4 — Establish who it reaches. For each affected group: how many where an input states it and unknown where none does, whether they would notice, and whether they must be told. Never estimate a population.

5 — Cost the undo at each stage. Per stage: what undoing it takes, who has to do it, what stays changed afterwards, and what has to be communicated. A cost nobody supplied reads unknown; the shape of the cost is still recorded.

6 — Find the point of no return. The last stage at which undoing still restores the prior state, and what crossing it commits. Everything before that point can be decided quickly; everything after it cannot be decided a second time.

7 — Set the scrutiny the decision deserves. A reversible change with narrow reach is decided by whoever owns it, immediately, and the assessment says so. An irreversible change with wide reach names the review it needs and who must sit in it. Deliberation is itself a cost, and this step spends it where undoing is expensive.

Output

reversibility-assessment.md, in this order:

1. Change assessed — the action, who proposed it, and when
2. Classification — reversible, costly, partial or irreversible, with the input that makes it so
3. Reach — one line per item touched: name, direct or indirect, and what happens to it
4. People reached — group, how many or unknown, whether they would notice, whether they must be told
5. Stages and undo cost — per stage: what undoing takes, who does it, what stays changed
6. Point of no return — the stage that crosses it, and what crossing it commits
7. Rollback plan — the steps, their owner, and whether each is confirmed or unverified
8. Scrutiny required — the review this decision warrants, who must be in it, and what may be decided without it
9. Gaps — what could not be mapped or costed, and who can supply it

Validation

The assessment is ready when all of these hold:

Section 2 carries one of the four classifications and the input that supports it
Every item in section 3 came from an input; none was inferred from the change
Section 4 reads unknown wherever no population was supplied
Section 6 names a stage, or states that the change has no point of no return
Section 7 marks every rollback step confirmed or unverified
Section 8 matches scrutiny to classification and reach, and says what may proceed without review

Fail the run if a population or cost figure appears that no input supplied, or if section 8 demands review of a change section 2 classified as reversible with narrow reach.

Failure handling

No description of what the change touches — stop. Report that reach cannot be derived from the change itself, and name who can describe the environment.
Rollback tooling unknown — write the rollback plan as manual steps, mark every step unverified, and state in section 8 that an unverified rollback raises the scrutiny the decision needs.
No access to the affected systems — map only what was reported, mark section 3 reported, and state that nothing was checked.
Inputs disagree on what is affected — record both, name both sources, and set section 8 from the wider map while showing the narrower one beside it. Scrutiny set from the smaller map is the failure this assessment exists to prevent.
Partial material — assess the stages the material covers, mark the rest NOT ASSESSED — pending <material>, and deliver rather than wait.

Download .md

Post-Decision Review

Compares what a decision predicted with what happened, judges the process separately from the result, and returns corrections rather than blame.

Deliverable

One Markdown document, decision-review.md, in the structure set out under Output below. It takes the output of Decision Record Authoring, and its corrections return to the process that produced it.

Required inputs

The decision record being reviewed — decision-record.md is the expected form; any record carrying the decision, its reasoning and its rejected alternatives will do.
What actually happened — the outcome as observed, with the source that observed it.
The period the review covers — from when the decision took effect to the point the outcome was observed.

If any of the three is absent, stop and report it. A review run from memory produces the story the room already agrees on; the record, the observation and the period are what make it a comparison instead of a recollection.

Optional inputs

The assumption register that accompanied the decision, if one exists
Measurements taken before and after, with their sources
The people who held each assumption, and what they say now
Other decisions taken in the same period that moved the same outcome
The process the decision went through: who was consulted, how long it took, what deciding cost

Where measurements are absent, the review compares stated expectation with reported outcome and labels both as reported. It does not reconstruct a number that was never taken.

Execution

1 — Recover what was predicted. From the record: what the decision was expected to produce, what it was expected to cost, and the consequences that were accepted. Quote the record rather than paraphrasing it — a paraphrase written after the outcome is known drifts towards the outcome.

2 — Record what happened. The observed outcome, with a source and date for each observation, inside the period under review. Where an expectation has no matching observation, write not measured rather than judging it from impressions.

3 — Compare, one prediction at a time. For each prediction: what was expected, what occurred, the difference, and whether that difference is measured or reported. Do not summarise until every line exists.

4 — Separate the decision from the outcome. Judge the decision on what was knowable when it was made, and the outcome on what happened. A sound process can produce a bad outcome and an unsound one a good result; a review that merges them teaches an organisation to avoid risk rather than to decide well. Record which of the four cases this is.

5 — Find the assumption that failed. Where the outcome diverged, name the assumption behind the divergence, who held it, the confidence they stated, and whether anything available at the time would have refuted it. An assumption nobody could have tested is a different finding from one nobody tested.

6 — Review the process, not the people. What in how the decision was made let the failed assumption through: who was not asked, what evidence was not sought, what deadline compressed it. Name steps and roles. Do not name a person as a cause.

7 — Write corrections that bind. Each correction states what changes in the process, who owns it, and how the next review would tell whether it was adopted. A correction that cannot be checked is an intention.

Output

decision-review.md, in this order:

1. Decision reviewed — the record, its date, who decided, and the period covered
2. Predicted — quoted from the record: expected results, expected costs, accepted consequences
3. Observed — what happened, with source and date; not measured where nothing was taken
4. Comparison — one line per prediction: expected, actual, difference, measured or reported
5. Decision quality — process quality and outcome quality stated separately, and the case this falls into
6. Failed assumptions — the assumption, who held it, the confidence stated, whether it was testable at the time
7. Process findings — what in the method let it through, by step and role
8. Corrections — the change, its owner, and how adoption will be checked
9. Still open — what could not be compared, and what would settle it

Validation

The review is ready when all of these hold:

Section 2 quotes the record; nothing in it is written from memory
Every prediction in section 2 has a line in section 4, including those marked not measured
Section 5 states process quality and outcome quality separately
Every assumption in section 6 names who held it, or reads holder unrecorded
Section 7 names steps and roles, and no finding names a person as a cause
Every correction in section 8 has an owner and a check

Fail the run if the review judges the decision by its outcome alone, or if a comparison line carries a figure that no observation supplied.

Failure handling

No decision record — stop. Report that there is nothing to compare against, and that reconstructing the reasoning once the outcome is known produces a story rather than a review.
The outcome cannot be measured — compare stated expectation with reported outcome, mark every line reported, and state in section 9 that no measurement supports the comparison.
The record made no predictions — record that as the first process finding, review what can be reviewed, and make recording predictions the first correction in section 8.
Accounts of what happened disagree — record each with its source, mark the line contested, and carry it to section 9. Do not resolve it by seniority.
Partial material — review the predictions the material covers, mark the rest NOT REVIEWED — pending <material>, and deliver. A review held back until everything is available is written after everyone has forgotten what they believed.

Download .md