ideal-outcomes

name

ideal-outcomes

description

Generate ideal (best-case) outcomes for a stakeholder group — the ceiling when everything has gone perfectly to plan, not the floor of what's acceptable. Use this skill when the user asks for ideal outcomes, best-case outcomes, or the best-case scenario for a stakeholder group, or when generating outcomes and the user wants the ceiling not the floor. Also use when the user has asked for ideal outcomes and the response is drifting toward acceptable or realistic outcomes.

Ideal Outcomes

What "ideal" means here

Ideal outcomes are the ceiling, not the floor. They describe what a stakeholder group experiences when everything has gone perfectly to plan — every assumption holds, every dependency delivers, every constraint is removed, every risk fails to materialise. The ideal outcome is the best-case scenario, unconstrained by current friction, hedging, or pragmatic compromise.

This is distinct from:

• Acceptable outcomes — what could realistically happen, hedged against constraints, what's "good enough." The floor.
• Realistic outcomes — what is likely to happen given current conditions and known risks. The middle.
• Ideal outcomes — what would happen if everything went perfectly. The ceiling.

The user is asking for the ceiling. Defaulting to the floor or the middle is the failure mode this skill exists to prevent.

A "stakeholder group" is any group affected by or with an interest in the system — served users, affected parties, constraining bodies, or any other group that holds a stake in the system's outcomes.

Generation protocol

1. Identify the stakeholder group. Confirm who the outcomes are for. If the user named a specific group, use that. If the group is ambiguous, ask one clarifying question — but do not stall on disambiguation if the group is clear from context.

2. Imagine the best-case scenario. Before writing any outcome statements, construct the scenario where everything has gone perfectly:

   • Every assumption the system makes about this group holds.
   • Every dependency the group relies on delivers fully and on time.
   • Every constraint that currently limits this group is removed.
   • Every risk that could affect this group fails to materialise.
   • The system operates at its theoretical best, not its practical average.

3. Describe what the stakeholder group experiences in that world. From the group's perspective, what is their experience when the system has delivered perfectly? What do they have, what do they avoid, what changes for them? This is the substance of the outcome.

4. Write outcomes as present-tense statements of that experience. Each outcome is a single, concrete statement of what is true for this group in the best-case world. Present tense, active voice, specific. One idea per statement.

5. Think big. The ideal outcome should feel ambitious — not implausible, but at the edge of what the system could deliver if everything aligned. If an outcome feels safe, comfortable, or hedged, it is probably an acceptable outcome in disguise. Push it further: what would make this outcome remarkable for this group?

Anti-pattern: acceptable drift

The failure mode this skill exists to prevent. The agent generates outcomes that are acceptable — realistic, hedged, pragmatic — instead of ideal. This happens when the agent optimises for plausibility over ambition, or when it anchors on current constraints instead of removing them.

Indicators of acceptable drift — if any of these appear, regenerate silently before delivering:

Indicator	Example	Why it's drift
Hedging language	"could", "might", "if feasible", "where possible"	Ideal outcomes are stated as what is true in the best case, not what might be
Constraint-anchoring	"given current limitations", "within existing scope"	The best case removes constraints; anchoring on them produces the floor
Compromise framing	"a reasonable outcome would be", "a balanced approach"	Ideal is not balanced — it is the ceiling
Realism qualifiers	"realistically", "in practice", "practically speaking"	These signal the middle, not the ceiling
Softening adverbs	"largely", "mostly", "substantially"	Ideal outcomes are complete, not partial
Defensive scope	"at a minimum", "at least"	These describe the floor; ideal describes the ceiling
Risk-adjusted language	"accounting for", "mitigating against"	The best case assumes risks do not materialise

When drift is detected: Do not deliver the drifted version. Regenerate the outcomes from the best-case scenario in step 2, removing the constraint or hedge that caused the drift. The user never sees the acceptable version — this matches the Thinking Partner principle that capabilities are invisible.

Self-check

Before delivering, verify each outcome against this checklist. If any check fails, regenerate silently.

#	Check	Pass condition
1	Is this the best case or the realistic case?	Best case — everything has gone perfectly
2	Is there hedging language?	No hedging — outcomes stated as what is true in the best case
3	Is there constraint-anchoring?	No anchoring on current limitations — constraints are removed in the best case
4	Would removing a constraint make this outcome bigger?	If yes, the outcome is too small — regenerate with the constraint removed
5	Does this feel ambitious?	Yes — at the edge of what the system could deliver if everything aligned
6	Is each outcome one concrete statement?	One idea per statement, present tense, active voice, specific
7	Are these from the stakeholder group's perspective?	Yes — what they experience, not what the system does

Worked examples

Example 1 — Served stakeholder group

User asks: "Generate ideal outcomes for end users of the task management system."

Acceptable (wrong — drift detected):

• Users can complete their tasks efficiently.
• The system provides reasonable notifications about deadlines.
• Users have access to their task history when they need it.

Why this is drift: "efficiently" is vague and realistic, "reasonable" is a compromise qualifier, "when they need it" hedges on availability. These describe the floor, not the ceiling.

Ideal (right — best case, everything perfect):

• Users complete every task before its deadline without experiencing the deadline as pressure.
• The system surfaces the next right task at the exact moment the user is ready to act on it — no manual triage, no missed priorities.
• Users never lose context: every task carries its full history, decisions, and dependencies, available instantly without search.
• Users experience the system as an extension of their own thinking — it anticipates what they need before they articulate it.

Example 2 — Affected stakeholder group

User asks: "What are the ideal outcomes for the support team affected by the new deployment pipeline?"

Acceptable (wrong — drift detected):

• The support team receives adequate notice of deployments.
• Incidents are handled within reasonable timeframes.
• The team can access deployment logs when troubleshooting.

Why this is drift: "adequate" is a floor word, "reasonable timeframes" is the middle, "when troubleshooting" hedges on access. These are acceptable, not ideal.

Ideal (right — best case, everything perfect):

• The support team knows about every deployment before it reaches any user — no surprise rollouts, ever.
• Incidents are prevented, not handled: the pipeline surfaces regressions before they reach production, so the support team never fields a ticket caused by a deployment.
• The team has complete, instant visibility into what changed, when, and why — no investigation time, no log hunting, no guesswork.
• The support team's workload drops as deployment quality rises; they spend their time on users, not on cleaning up deployments.

Example 3 — Constraining stakeholder group

User asks: "Generate ideal outcomes for the compliance team that governs the system."

Acceptable (wrong — drift detected):

• The compliance team can review audit logs as needed.
• The system meets regulatory requirements with minimal gaps.
• Compliance reporting is generated on a regular schedule.

Why this is drift: "as needed" hedges, "minimal gaps" is a compromise, "regular schedule" is pragmatic. These describe acceptable compliance, not ideal.

Ideal (right — best case, everything perfect):

• Every action in the system is automatically logged with the provenance, actor, and timestamp the compliance team needs — no manual log assembly, no gaps, no reconstruction.
• The system provably meets every regulatory requirement, with continuous evidence generation that the compliance team can present to any auditor without preparation.
• Compliance reporting is real-time and continuous: the team sees the compliance posture at any moment, not on a lagging schedule.
• The compliance team shifts from auditing the system to trusting it — their governance role becomes strategic, not policing.