Separate kinds of statements
Ask the AI to distinguish observed facts, inferences, assumptions and proposals. That makes review much easier.
Level 2
Give AI enough context to reason correctly
Once the task depends on your situation, the quality of the answer depends on the quality and authority of the context you supply.
A reusable request structure
GOAL What outcome are we trying to achieve, and why? CONTEXT What facts, rules, prior decisions, terminology or audience details does the AI need? AUTHORITY If sources conflict, which source wins? TASK What exact work should the AI perform? CONSTRAINTS What may it change? What must it preserve? What must it not assume? OUTPUT What form should the result take? VERIFICATION How will we know it is correct? What should be flagged as uncertain?
Context should be authoritative, not merely large. A short locked decision can matter more than 5,000 lines of old implementation.
Make uncertainty visible
Say “Do not silently invent missing values. If a material fact is missing, identify it.” This is far safer than allowing plausible filler.
Example: project review
Goal: review this system without accidentally redesigning it. Authority order: 1. current instruction 2. locked decisions 3. design documentation 4. configuration/schema 5. existing code Task: identify where the implementation conflicts with higher-authority design. Rules: do not treat existing behavior as intended merely because it exists. Separate definite conflicts from open questions. Prefer root-cause mechanisms over special-case patches. Output: findings by severity, each with evidence, affected area, root cause and recommended correction. Verification: cite the exact source used for every design claim.Level 3: files and data →