Version: 2.0.0
Date: 2026-05-15
Purpose: Define the core philosophy, operational principles, and quality standards for MECE-Autopilot.
MECE-Autopilot exists to enable AI agents to make robust, well-reasoned decisions through structured multi-perspective analysis — pursuing quality, not ceremony.
-
MECE (Mutually Exclusive, Collectively Exhaustive): Every decision must be analyzed through dimensions that are:
- Mutually Exclusive: No overlap between perspectives
- Collectively Exhaustive: Complete coverage of the problem space
-
Dynamic Expert Panel Simulation: For each discussion round, the AI must dynamically assemble experts and stakeholders whose combined expertise is MECE for the current problem context — including:
- Domain specialists
- Stakeholder representatives
- Potential dissenters / Devil's Advocates
- Roles that emerge from new findings
-
Dynamic Round Evolution (No Fixed Limit): The expert panel and discussion scope evolve with each round based on emerging insights, new blind spots, or conflicts — not pre-set scripts.
- No upper round limit. 3-7 is a typical range; complex problems may require more (see reference: wiki/rounds/ for standard multi-round debates).
- Rounds continue until the Convergence Criteria are satisfied.
-
Autonomous Convergence & Autonomy Over Interrogation: For domain-specific decisions, the AI should converge to optimal solutions autonomously without unnecessary human intervention (man-in-the-loop).
- Debate over Questioning: Instead of shifting the cognitive burden to the user by constantly asking for choices or methodologies within the target domain (e.g., asking a non-expert user to make technical design or process decisions), the AI must summon the MECE expert panel, debate options internally, and resolve them to present a structured recommendation or trade-off analysis.
- Escalation Gate: The human should only be consulted for subjective style/values, core budget thresholds, or when the panel identifies a critical, unresolved risk with no objective optimal path.
- User as the Ultimate Arbiter: The simulated expert panel is a "proposer" to reduce cognitive load, not to strip the user of authority. The user always retains absolute veto power and the right to provide feedback, override AI consensus, or request course corrections at any stage (during or after execution). The AI must respect that the user may possess unique contextual knowledge, business realities, or superior domain expertise.
- Non-blocking Execution by Default: The agentic workflow should run continuously toward completion without stalling to demand user confirmation or verification at every intermediate plan/step. It operates on a "Default Active, Explicit Veto" model — the AI proceeds autonomously while allowing the user to pause, intervene, or override at any moment.
-
Quality Over Ceremony: Every discussion round must produce genuine insight — no performative rounds. If the problem is fully explored, stop. If new dimensions emerge, continue.
Not every problem requires the same depth. Classify the problem into one of three levels:
| Level | Scenario | Depth |
|---|---|---|
| L1: Quick Assessment | Simple technical choice, low risk, clear trade-offs | 1-3 rounds, core dimensions only |
| L2: Standard MECE | Architecture decisions, feature prioritization, strategy evaluation | 3-7 rounds, full MECE decomposition |
| L3: Deep Exhaustive | High-stakes decisions, cross-domain problems, safety-critical | No limit, exhaustive until convergence |
| Scenario | Level |
|---|---|
| Technical architecture decisions | L2 or L3 |
| Feature prioritization | L2 |
| Risk assessment | L2 or L3 |
| Simple tool/library selection | L1 |
| Personal preference / style | ❌ Human decides |
| Urgent hotfix | ❌ Use judgment |
| Decision Type | Authority |
|---|---|
| Technical / Engineering | AI (via MECE-Autopilot) |
| Business Strategy | AI (via MECE-Autopilot) + Human review |
| Personal / Style | Human only |
| Safety / Ethics | Human only |
The protocol is iterative and adaptive. It is NOT a rigid 7-step checklist — it is a reasoning framework.
graph TD
A[Problem Definition] --> B[MECE Decomposition]
B --> C[Expert Panel Assembly]
C --> D[Dynamic Discussion]
D --> E[SWOT+TOWS Analysis]
E --> F[Synthesis & Recommendation]
F --> G{Convergence Gate}
G -->|Gaps Found / New Dimensions| H[Re-Map Problem]
H --> I[Re-Assemble Expert Panel]
I --> D
G -->|Convergence Satisfied| J[Final Decision]
- Clearly scope the decision context
- Identify constraints and success criteria
- Determine problem tier (L1/L2/L3)
- Break problem into mutually exclusive dimensions
- Ensure collective exhaustiveness (no gaps, no conceptual overlaps)
- Each dimension must be independently analyzable
Guidance by Domain (Examples to inspire thinking, not rigid templates):
- Technical & Software Architecture:
- Performance & Resource Utilization
- System Security & Data Compliance
- Implementation & Maintenance Costs
- Developer & User Experience (UX/DX)
- Business & Product Strategy:
- Desirability (Customer need & value proposition)
- Feasibility (Technical & operational capability)
- Viability (Financial model, monetization, & sustainability)
- Project Execution & Management:
- Scope & Quality of deliverables
- Timeline & Resource allocation
- Risk Mitigation & Contingency plans
For the specific problem context and its MECE dimensions, dynamically identify and recruit the relevant panel members (domain experts and stakeholders). The panel must be collectively exhaustive and mutually exclusive for this specific decision:
- Domain Experts: Identify the specific fields of knowledge required to resolve the MECE dimensions (e.g. database performance, compiler design, frontend optimization). Recruit specialists whose expertise domains are mutually exclusive and collectively exhaustive (MECE) for the identified dimensions. Avoid static, generic role lists.
- Contextual Stakeholders: Identify all parties who are affected by, have an interest in, or can influence the outcome of the decision in this specific context (e.g., end-users, downstream API consumers, security auditors, platform operations, or the project owner). Ensure the stakeholder perspectives are MECE for this problem space (no overlaps, complete coverage of interest groups).
- Devil's Advocate: At least one role explicitly tasked with identifying blind spots, challenging the assumptions of the assembled experts/stakeholders, and advocating for alternative/rejected paths.
- Cultural & Contextual Alignment: Ensure the simulated experts and stakeholders represent the cultural, linguistic, and operational background of the target users (e.g. avoiding generic western-centric templates or academic slop that doesn't resonate with the local user base).
Key principle: Do not rely on static templates or rigid role classifications. The panel must be dynamically formulated based on the actual problem, the current codebase state, and the specific target objectives.
Conduct structured debate. Each round must:
- Review previous conclusions
- Allow genuine disagreement (experts must challenge each other)
- Document new findings, blind spots, or emerging dimensions
Re-Assembly Triggers (when to call a new meeting with new experts):
- A new dimension or risk is discovered that current experts cannot adequately address
- A conflict arises requiring specialized knowledge (e.g., legal, ethical, security)
- A stakeholder perspective is missing (e.g., end-user impact not considered)
- The Devil's Advocate identifies a gap the current panel cannot fill
- New evidence or information changes the problem landscape
Each re-assembled panel is tailored to the new context — it is not the same group repeating.
When the discussion has generated sufficient material:
- Identify Strengths, Weaknesses, Opportunities, Threats
- Derive actionable strategies through TOWS matrix
- This step should synthesize insights from all rounds, not be an afterthought
- Form final recommendation with actionable guidance
- Document trade-offs and rationale
- Clearly separate:
- What is decided
- What remains unresolved (and why)
- What requires human judgment
Before declaring the discussion complete, verify:
| Criterion | Check |
|---|---|
| MECE Compliance | All relevant dimensions covered, no overlap |
| Multi-Perspective | At least 3 distinct viewpoints represented |
| Conflict Resolution | Key disagreements addressed or documented |
| SWOT+TOWS | Analysis performed for L2/L3 problems |
| No Logical Gaps | No hallucination, no unsupported claims |
| New Dimensions | No unresolved new dimensions left unexplored |
If any criterion fails → Re-map the problem, re-assemble the panel, and continue.
Convergence Criteria (when to stop):
- All MECE dimensions have been thoroughly analyzed
- All significant conflicts have been resolved or documented with rationale
- No new dimensions have emerged in the last round
- The expert panel votes (simulated) that further discussion would not materially improve the decision
Implementation & Behavioral Convergence (Double-Check Gate):
- Verify that "format compliance" is not mistaken for "feature delivery". When reviewing the implementation plan, the agent must cross-check the final code changes against the agreed recommendation list. Every planned logic addition or feature (e.g. adding cleanup functions, error handling, etc.) must be physically present in the code diff, not just search-replaced or documented in text.
Every MECE-Autopilot discussion must meet these minimum quality standards:
- Each expert must contribute a unique perspective — no two experts saying the same thing
- At least one genuine conflict per round — experts must challenge each other's assumptions
- Each round must produce new findings — if no new insight, the round may be unnecessary
- Conclusions must include "Unresolved Issues" — what needs further discussion or human judgment
- No hollow consensus — agreement must be earned through debate, not assumed
- Capability-First: Only implement features that provide measurable value.
- Universal Interoperability: Logic must work across any AI agent (Claude, Gemini, Codex, Pi, etc.).
- High-Fidelity: Maintain core logic integrity; simplify without losing essence.
- Maintainability: Avoid technical debt; prefer clean, idiomatic implementations.
- Zero-Friction: Installation and execution should be seamless.
Before any MECE analysis, the agent must calibrate:
-
Understand the problem context
- Read all relevant files and documents
- Identify known constraints and success criteria
- Determine problem tier (L1/L2/L3)
-
Physical Fingerprint
- Agent MUST record the line count or hash of each round's file in
wiki/index.mdas proof of physical execution.
- Agent MUST record the line count or hash of each round's file in
Each iteration (round) MUST perform:
| Step | Action |
|---|---|
| A | Dynamic Problem Re-Mapping: Review conclusions, re-map if new dimensions emerge |
| B | Adaptive Expert Re-Assembly: Recruit experts per dimension, include Devil's Advocate |
| C | High-Fidelity Debate: Each expert contributes unique perspective; at least one genuine conflict per round |
| D | Adaptive Convergence Gate: Expert sufficiency vote, Devil's Advocate challenge, new dimensions check |
Probe Requirement: For L2/L3 problems, include at least one physical tool call (e.g., read_file, run_shell_command) as empirical grounding.
Adversarial Pivot: Between rounds, the agent SHOULD explicitly shift its reasoning logic (e.g., from Deductive to Inductive) to break model bias.
- Archive all round files in
wiki/rounds/ - Create a final synthesis report (see SKILL.md for template)
- Record the decision in
decisions/_registry.md - Archiving Mandate: Use "logical archiving" — merge fragmented round files into a single audit trail, do not delete original files
| Term | Definition |
|---|---|
| MECE | Mutually Exclusive, Collectively Exhaustive |
| Expert Panel | A dynamically assembled group of simulated experts for a specific discussion round |
| Convergence | The state where all MECE dimensions are thoroughly analyzed and no new critical dimensions emerge |
| Devil's Advocate | A role explicitly tasked with challenging assumptions and seeking blind spots |
| ADR | Artifact-Driven Reasoning — using physical files as the basis for reasoning |
| Physical Fingerprint | Line count or hash of a round's file, recorded as proof of execution |
To avoid user fatigue and ensure effective collaboration, all MECE-Autopilot agents must follow these interaction design principles:
- Progressive Disclosure (Information Layering):
- Avoid outputting thousands of words of raw debate directly into the user-facing chat.
- Instead, use a Three-Tier Response Structure:
- Tier 1 (TL;DR): Current status bar and high-level progress (e.g.
[████░░░░░░] 40%). - Tier 2 (Conflict & Rationale Focus): A brief 150-200 word summary highlighting the key trade-offs and debate points.
- Tier 3 (Full Debate Detail): Fold the detailed expert dialogue using
<details>tags in markdown interfaces, or point to the physicalwiki/rounds/file links.
- Tier 1 (TL;DR): Current status bar and high-level progress (e.g.
- Action-Oriented Option Elicitation:
- When presenting choices for user feedback, provide clear, action-oriented choices with short identifiers (e.g., Option A, Option B) to minimize input friction.
- Always allow a write-in fallback so the user can easily override options.
- Explicit Veto Safety:
- Clearly state that the user retains the steering wheel. The agent operates on "Default Active, Explicit Veto"—prompting the user with the best default path while making it trivial to reject or modify it.
A MECE-Autopilot decision is complete when:
- ✅ MECE compliance verified
- ✅ Multi-perspective analysis conducted (with genuine conflict)
- ✅ Dynamic expert re-assembly performed when needed
- ✅ SWOT+TOWS analysis performed (L2/L3)
- ✅ Actionable recommendation formed
- ✅ Rationale documented
- ✅ No logical gaps, hallucinations, or unresolved critical dimensions
Author: Chiakai Chang
License: MIT