This stack prevents an AI from collapsing an ambiguous or constraint-heavy problem into the first plausible answer. AI systems are structurally incentivized to resolve quickly — to pattern-match to the nearest familiar frame and produce output. That is useful for straightforward tasks and actively harmful for tasks that are easy to misread, over-simplify, or resolve with a fake compromise that satisfies no real constraint. Use this stack when you already suspect the obvious answer is wrong, or when the task carries enough complexity that a fast resolution should be treated as a warning sign.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/ai-protocol-kit/llms.txt
Use this file to discover all available pages before exploring further.
Pre-Task Expansion Protocol v1 (conditional)
Add this step if the task may collapse too quickly into the obvious answer. This protocol generates alternative framings, surfaces hidden tensions, and maps the surrounding shape of the problem before any solution is attempted. It does not produce a solution — it produces the expansion that makes a better solution possible.View protocol →
System Reading Protocol v0.2 (conditional)
Add this step if the real system behavior matters more than declared intent — that is, if there is a gap between what the system claims to do and what it actually does, and that gap is relevant to the task. This protocol extracts the operative principle governing that gap without jumping to a fix or framing it as a problem to be solved.View protocol →
PHI-Lens Protocol v4.a (conditional)
Add this step only if constraints interact and the output needs an explicit gate. When multiple forces are in play and a flat compromise would produce output that looks balanced but hides asymmetry, this protocol makes the dominant force and its counterforce explicit before any resolution is output.View protocol →
All three steps in this stack are conditional. Use the minimum that fits the actual task. Many hard tasks only need one of these protocols — adding all three by default adds process weight without adding clarity. Start with the protocol closest to the actual failure mode you are trying to prevent.
When to use this stack
- Hard architectural decisions where the right answer depends on which constraint is actually dominant
- Conflicting stakeholder requirements where a compromise resolution would satisfy no one and obscure the real tension
- System audits where declared behavior and observable behavior do not match, and the gap is the real finding
- Any task where “it depends” is being used as a resolution rather than as an invitation to examine what it actually depends on
- Planning or design work where the obvious framing is almost certainly the wrong framing