Christian Ullrich January 2026

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 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.

Project title

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.

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

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 </aside>

Project description

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.

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

Prompt

Write a project description for the "TBD Project", based on the answers to the project overview questions below.

1. What is this project about in one plain sentence, without justification or solution language?
   • TBD…
2. What problem or situation triggered the project to exist?
   • TBD…
3. What outcome or change is the project meant to produce if it works as intended?
   • TBD…
4. What are the main areas, dimensions, or aspects the project needs to address?
   • TBD…
5. What constraints, limits, or conditions shape the project environment?
   • TBD…
6. What assumptions are currently being made about how the project will work or what will be true?
   • TBD…
7. What feels unclear, unstable, or potentially conflicting in the project as it is currently understood?
   • TBD… </aside>

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

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.

</aside>

Decision probes

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.

<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 Title: 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, 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 </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.
• 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. </aside>

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

</aside>

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

</aside>

How AI is used