Table of Contents

Problem

Most project documents look structured, but collapse as soon as people ask hard questions. Teams mix decisions, assumptions, and wishes into a single narrative, so every stakeholder reads the same text differently and fills in the gaps with their own interpretation. The result is clean slides built on vague intent, hidden trade-offs, and choices that were never clearly made, leading to repeated meetings, circular discussions, and reviews that surface contradictions and missing ownership rather than confirming progress.

What the system does

The system turns messy, multi-stakeholder project material into a backbone of explicit, testable statements. Instead of blending decisions, assumptions, and intentions into paragraphs that need interpretation, it forces each point into a single concrete sentence that can be accepted, rejected, or corrected without debate. The backbone exposes trade-offs, narrows options, and makes ownership visible, so plans, slides, and meetings all refer to the same clear set of commitments.

Core principles

The system works by eliminating ambiguity at every step. It starts from a minimal project context and moves directly into a list of decisions, each as a single atomic sentence with no subclauses, no embedded choices, and no implied meaning. Any sentence that cannot withstand skeptical review against real incentives, constraints, and politics is corrected with the smallest viable change or removed, and the complete list must be internally consistent: no contradictions, no double ownership, no incompatible promises.

Project context

The project context is a short label that keeps the work within a single, concrete project universe without smuggling in narrative, politics, or hidden assumptions. It names what is being done, with what, and where, in just a few words. Its only job is to keep all decisions tied to the same situation while leaving real pressures and trade-offs to be captured explicitly in the decision list.

<aside> <img src="/icons/document_gray.svg" alt="/icons/document_gray.svg" width="40px" />

Project context examples

• Microsoft Copilot and ChatGPT implementation, rollout, and adoption
• ChatGPT introduction for contract drafting in the legal department
• GenAI-supported ticket handling in the central IT helpdesk </aside>

Situation block

The situation block captures only the hard constraints and fixed facts that shape the project but cannot be chosen or negotiated. It is a short list of concrete, verifiable statements that define the environment in which decisions must operate. Each item is a single clause, tagged as an external constraint, internal constraint, fixed fact, or non-negotiable. The block excludes opinions, pressures, assumptions, and intentions because those belong in the decision fragments or will be exposed later as trade-offs. Its purpose is not to describe the project story but to anchor decision-making in the realities that cannot be changed, so every subsequent decision is tested against the same explicit boundaries.

Decision fragments

Decision fragments are the rough inputs collected from stakeholders before any real decision-making starts. They are messy on purpose: incomplete thoughts, hidden assumptions, local pressures, and ideas people think the project should commit to. A simple list of project areas is used to sort these fragments so everyone can write down what they believe the project will decide, without worrying about correctness or consistency. These fragments are not decisions. They are only raw material for spotting angles, tensions, and failure patterns, so the final backbone reflects what people actually mean, not the clean story they present.

<aside> <img src="/icons/robot_gray.svg" alt="/icons/robot_gray.svg" width="40px" />

Prompt

• Answer in LANGUAGE language.
• Do not perform a web search.
• Avoid general definitions or concept explanations.
• Do not use en or em dashes; hyphens are acceptable.
• Do not use thematic breaks.
• Generate a numbered list of topics.
• Topics must represent clearly distinct angles or sub-problems.
• Topics must be meaningfully different from each other.
• Do not generate any item-level sentences; produce only topic labels.
• Project Context: USERINPUT </aside>

<aside> <img src="/icons/robot_gray.svg" alt="/icons/robot_gray.svg" width="40px" />

Prompt

• Answer in LANGUAGE language.
• Do not perform a web search.
• Avoid general definitions or concept explanations.
• Do not use en or em dashes; hyphens are acceptable.
• Do not use thematic breaks.
• For each Project Area, generate a numbered list of questions.
• Each question must be short, concrete, and framed so that a stakeholder’s answer will always be a decision fragment, and may also surface assumptions, implied commitments, constraints, dependencies, or trade-offs.
• Each question must force the stakeholder to express what they think the project will commit to, avoid, accept, depend on, limit, or reject.
• Do not ask abstract or generic questions.
• Do not combine multiple concerns into a single question.
• Do not use hypothetical scenario phrasing, such as "imagine" or "what if".
• Every question should push toward a concrete project choice, not a preference or opinion.
• Project Context: USERINPUT
• Project Areas: USERINPUT </aside>

Decision structure

Decisions are the real commitments the project must stand behind. Each one cuts options, accepts a downside, or rules out something attractive. Every decision is a single, atomic sentence that states the choice, the reason for it, the option being rejected, and the downside being accepted. This forces the team to confront trade-offs directly rather than hide them in soft wording or broad intent. The result is a set of clear statements that anyone can challenge, agree to, or correct without interpretation.

<aside> <img src="/icons/robot_gray.svg" alt="/icons/robot_gray.svg" width="40px" />

Prompt

• The following notes are rough team input, not approved statements.
• They may contain assumptions, opinions, contradictions, and incomplete thoughts.
• Treat them only as raw material that may or may not be helpful.
• Do not copy wording from the notes.
• Do not assume any note is correct or binding.
• Use them only to identify possible angles, pressures, or candidate ideas for the following category.
• Accept nothing as a fact unless it can be expressed as a valid item in the required format.
• Ignore anything that represents narrative, speculation, or preferences that do not survive scrutiny.
• The notes do not replace or alter the project context or any previously corrected list.
• Do not answer this prompt.
• Project Context: USERINPUT
• Notes: USERINPUT </aside>

<aside> <img src="/icons/robot_gray.svg" alt="/icons/robot_gray.svg" width="40px" />

Prompt

The following are general instructions for item generation. Recognize them only. Do not answer.

• Answer in LANGUAGE language.
• Do not perform a web search.
• Avoid general definitions or concept explanations.
• Do not use en or em dashes in sentences or headers; hyphens are acceptable.
• Do not use thematic breaks.
• Base every decision on the defined Context and Notes.
• Generate a list of decisions for the selected topic, choose the number yourself, and include only items that are meaningfully different from all already-created items.
• Each item must contain exactly one sentence and no subheadings.
• Each sentence must start with the phrase "We decide" in the output language.
• Each sentence must express a fundamental trade-off instead of an indecision, a trivial choice, or a general good-practice statement.
• Each decision must either reduce options, commit resources, exclude alternatives, accept a risk, or create a meaningful constraint.
• In each sentence, after stating the decision, add a short benefit clause introduced with the phrase "because this gives us" in the output language, explaining why this option is chosen with a concrete operational effect in the Situation.
• After the benefit clause in the same sentence, include the phrase "instead of" in the output language to clearly state what attractive or plausible alternative is rejected.
• After the "instead of" clause in the same sentence, add a short consequence clause that states what downside is accepted, using the phrasing "and accept that" in the output language, followed by a concrete negative outcome.
• Avoid soft or vague verbs such as ensure, promote, support, enable, improve, or similar phrasing that describes intentions rather than hard choices.
• Avoid universally agreeable statements or management platitudes.
• Each decision must be operational and specific enough that someone could take concrete action based on it.
• For any subsequent review rounds after your initial output, when I mark a specific decision item with feedback or a change request, you must adjust only that item and copy all other items from the previous version word-for-word without modification. </aside>

<aside> <img src="/icons/robot_gray.svg" alt="/icons/robot_gray.svg" width="40px" />

Prompt

• Generate the decisions for the selected topic in accordance with the general instructions above.
• Category: USERINPUT </aside>

How AI is used

AI is used only to quickly generate rough draft sentences. These drafts are then challenged, corrected, or deleted based on real constraints, incentives, and stakeholder pressures. AI provides speed and variation, but the actual decisions come from the correction process, not from the model.

How items are tested