Christian Ullrich
January 2026
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.
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.
The system works by eliminating ambiguity at every step. It starts from a minimal project title 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.
The project title is a short, concrete name that identifies the initiative being worked on. It states the object, scope, and setting in plain terms so everyone knows which project the decisions apply to. The title must be descriptive but non-interpretive: it should not explain intent, justify choices, or imply how the work will be done. Its only function is identification. All decision probes and decisions are assumed to belong to the project named in the title and to no other.
Project title 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
The project description is an explicit but non-binding overview used only to generate project areas and decision probes. It describes the intended shape of the initiative as it is currently understood, including tentative structures, working assumptions, and design ideas. The description may contain preferences, examples, and partial solutions, but none of these are treated as facts or commitments. Its role is to provide enough shared orientation to ask meaningful decision probes, not to justify or pre-decide outcomes. All statements in the description are expected to be challenged, corrected, or discarded once decision probes are turned into explicit decisions.
Prompt
Write a project description for the “TBD Project”, based on the answers to the project overview questions below.
- What is this project about in one plain sentence, without justification or solution language?
- TBD…
- What problem or situation triggered the project to exist?
- TBD…
- What outcome or change is the project meant to produce if it works as intended?
- TBD…
- What are the main areas, dimensions, or aspects the project needs to address?
- TBD…
- What constraints, limits, or conditions shape the project environment?
- TBD…
- What assumptions are currently being made about how the project will work or what will be true?
- TBD…
- What feels unclear, unstable, or potentially conflicting in the project as it is currently understood?
- TBD…
Project description (optional) example
The SharePoint Async Work & Wiki Setup Project establishes a voluntary, organization-wide space that complements existing sites rather than replacing them, providing a safe and structured hub where anyone can contribute without forced migration or loss of local ownership. It deliberately combines the strengths of a wiki with those of async collaboration tools. Page content is the primary artifact and represents curated, durable knowledge, while comments are used for time-bound discussion and sense-making rather than being the primary carrier of information. The site is governed by clear, simple rules enforced through structure rather than control: pages are the primary collaboration unit, not files; text, lists, and spreadsheets come before presentations; and each page represents exactly one topic. Pages can follow a recommended layout with a clearly described challenge at the top, a prominent decision proposal or outcome beneath it, and asynchronous discussion taking place in comments at the bottom; this pattern is encouraged as an effective way to move from discussion to written outcomes, but it is not enforced and represents only one standard way pages may be used, with the shared principle being that conclusions and durable knowledge are continuously promoted from discussion into the page body rather than remaining in comments. In this way, pages act as long-lived topic threads similar to lightweight async tools, but with the explicit goal of producing and maintaining high-quality written outcomes, especially decision proposals that capture options, rationale, ownership, impacted teams, and deadlines. Metadata such as owner, team tags, topic category, status, and archive flags keep the system navigable and prevent content overload. Editing follows wiki-like principles while prioritizing psychological safety: anyone may comment, minor edits are allowed freely, and substantive changes to another person’s content require prior written consent. Leadership maintains the rules, templates, metadata, and FAQ but does not curate or approve content, acting as custodians of the system rather than gatekeepers of ideas. A clear landing page explains purpose and usage, highlights active topics and recent decisions, and links to a living FAQ that evolves with fundamental questions, making the site a shared reference point for async collaboration, decision-making, and institutional memory without becoming noisy, bureaucratic, or mandatory.
Decision probes are early commitment signals collected from stakeholders before any decisions are finalized. They capture what people implicitly expect the project to decide, including incomplete statements, hidden assumptions, local constraints, and preferred outcomes. Probes are organized by project area so stakeholders can state what they believe will be committed to, without resolving conflicts or checking consistency. These probes are not decisions and do not need to be correct. They exist to surface where expectations diverge, where trade-offs are being assumed, and where proposed commitments are likely to fail under pressure, so the final decision backbone reflects real positions rather than a polished consensus story.
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 Title: USERINPUT
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, write exactly ten questions.
- Each question must start with “Will we”.
- Each question must be answerable as a short commitment statement starting with “We will…” or “We will not…”.
- Each question must lock a single, specific, observable project decision.
- Avoid scope policing questions phrased as “what content belongs” or “what should be documented”.
- Do not ask for opinions, preferences, or rankings.
- One concern per question.
- Do not use hypothetical scenario phrasing, such as “imagine” or “what if”.
- Project Title: USERINPUT
- Project Description: USERINPUT
- Project Areas: USERINPUT
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.
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.
- 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 title or any previously corrected list.
- Only acknowledge the received notes.
- Project Title: USERINPUT
- Notes: See below.
Prompt
The following are general instructions for item generation. Acknowledge receipt only. Do not generate any content beyond acknowledgment.
- 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 Title and Notes.
- Generate only as many decisions as there are distinct, unavoidable commitments in the material, and do not create additional decisions to improve coverage, balance, or completeness.
- 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.
- When multiple plausible alternatives or downsides exist, choose the single alternative and downside that most meaningfully constrain behavior in practice.
- If a concrete downside is not explicitly stated in the input, infer the most likely real-world cost of the choice based on typical organizational, political, or governance constraints, preferring loss of enforceability, authority, closure, or conflict resolution power over generic variability, quality differences, or user behavior drift.
- 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 state what attractive or plausible alternative is rejected clearly.
- The “instead of” clause must name a concrete, executable alternative action, process, or governance setup that could plausibly be chosen, not an outcome, effect, intention, preference, abstract standard, or any restatement, negation, or mirror of the benefit clause.
- 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.
- The downside after “and accept that” must be caused by choosing this option rather than the alternative, and must not still hold if the alternative were chosen.
- 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.
Prompt
- Generate the decisions for the selected Project Area in accordance with the general instructions above.
- Project Area: USERINPUT
AI is used only to generate rough draft sentences quickly. 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.
Each sentence is tested by attacking it. The question is simple: does it hide a trade-off, assume freedom the project does not have, blur ownership, create contradictions, or promise something unrealistic? Anything that fails is corrected or removed entirely. The aim is not perfect language but sentences that survive pressure from stakeholders who will question them later.
Decision rework
Access timing
We decide to activate ChatGPT access for all experienced users this week because this gives us immediate productivity gains instead of waiting for a full stakeholder review and accept that some teams may feel rushed by the sudden availability.- We decide to activate ChatGPT access for all experienced users without waiting for a specific launch window because this gives us earlier productivity gains instead of tying the rollout to a fixed week and accept that some teams may feel unprepared when access appears sooner than expected.
Discussion location
We decide to route all usage questions through a single chat channel because this gives us faster alignment instead of forming a multi department working group and accept that niche concerns might be answered less comprehensively.- We decide to centralize all ChatGPT related discussions in the existing async collaboration tool because this gives us focused visibility instead of opening a new chat channel and accept that some users may miss the immediacy of real time exchanges.
Onboarding approach
- We decide to skip mandatory onboarding sessions because this gives us quicker adoption by motivated users instead of designing a full training curriculum and accept that some colleagues may misuse features until they learn through practice.
Knowledge sharing
We decide to allocate only one coordinator to oversee the rollout because this gives us tighter decision making instead of distributing responsibilities across a committee and accept that the coordinator may become a temporary bottleneck- We decide to let early adopters publish suggested prompts freely because this gives us rapid knowledge propagation instead of creating an approval workflow and accept that a few low quality examples may circulate.
Team stewardship
- We decide to assign ChatGPT rollout stewardship to the small team collectively rather than appointing a single coordinator because this gives us balanced workload distribution instead of centralizing control with one person and accept that some decisions may take longer due to group alignment.
Once the individual decisions are solid, the whole list is checked together. All items must fit the same project universe without contradictions, double ownership, or hidden assumptions that reopen closed choices. No sentence may depend on another to be understood. If any conflicts arise, the decisions are adjusted so the backbone works as a coherent set rather than a collection of plausible but incompatible ideas.
The backbone is a working control document, not a presentation. It sits behind plans, slides, and meeting discussions as the single reference for what truly has been decided. Stakeholders review individual sentences rather than debating entire decks, turning alignment into a simple accept, reject, or adjust process. When new documents, vendor proposals, or internal drafts appear, they are checked against the backbone. Anything that contradicts a decision is rewritten or escalated as a change request. As the project moves forward, the backbone is deliberately updated, so the reasoning stays stable even as communication and narratives change around it.