When AI goes off-script, refactoring code you didn’t ask to touch, adding features mid-task, or just ‘keeping going’ when it should stop, that’s not a model problem. It’s a structure problem. The fix might already be sitting in a Reddit post. This prompt from u/No_Award_9115 on r/PromptEngineering introduces a deterministic reasoning kernel that waits, verifies, and stops exactly when instructed.
What the Architecture Actually Does
The original poster built this around a frustration engineers know well: AI that treats every task as an open invitation to do more. The framework responds with named phases, hard stops, and explicit anti-patterns baked directly into the prompt.
Here’s the core structure at a glance:
- Role framing: The AI is cast as a ‘waiting kernel’, a mechanical executor, not a creative collaborator
- Evidence-first rules: No assertions without a FIND and READ step on actual code or files
- Bounded deliverables: Work stops after each named checkpoint (D1, D2…) with no auto-continuation
- Tagged speculation: Any guess must be labeled SPECULATION and immediately followed by verification, or downgraded to OPEN_QUESTION
The State Capsule
One of the sharper structural choices here is the CONTEXT_CAPSULE. It’s a compact working memory block, capped at 2000 tokens, that the model updates after each step. It holds the current objective, hard constraints, files touched, open questions, and the single next step. It keeps the AI anchored between turns without bloating context.
The Reasoning Pipeline
The creator broke execution into four explicit phases:
- FRAME: restate the objective and identify what needs file verification
- PLAN: produce an ordered checklist with explicit done-checks per step
- VERIFY: find and read the relevant code sections before touching anything
- EXECUTE: make only the minimal change set, nothing more
This is a forcing function. The model can’t skip verification or jump to implementation without running through the prior phases.
Anti-Loop Rules
This section is where the architecture earns its keep. The author included explicit anti-patterns that the model must honor:
- Never continue after a deliverable is complete
- Never refactor ‘to make it cleaner’
- Never fix unrelated warnings
- If baseline tests are red: stop and report, do not implement
That last rule alone would prevent countless AI-introduced regressions in real codebases.
Use Cases
This architecture fits best for:
- 🛠️ Long coding sessions where scope creep is a constant risk
- Multi-step refactors that need explicit checkpoint approvals before proceeding
- Any context where you want auditable, step-by-step AI reasoning
It’s less suited for creative or exploratory work where you want the AI to roam and suggest freely.
Prompt of the Day
Here is the full prompt, reproduced exactly as the original poster shared it:
BASE_REASONING_ARCHITECTURE_v1 (Clean Instance / "Waiting Kernel") ROLE You are a deterministic reasoning kernel for an engineering project. You do not expand scope. You do not refactor. You wait for user directives and then adapt your framework to them. OPERATING PRINCIPLES 1) Evidence before claims - If a fact depends on code/files: FIND → READ → then assert. - If unknown: label OPEN_QUESTION, propose safest default, move on. 2) Bounded execution - Work in deliverables (D1, D2, …) with explicit DONE checks. - After each deliverable: STOP. Do not continue. 3) Determinism - No random, no time-based ordering, no unstable iteration. - Sort outputs by ordinal where relevant. - Prefer pure functions; isolate IO at boundaries. 4) Additive-first - Prefer additive changes over modifications. - Do not rename or restructure without explicit permission. 5) Speculate + verify - You may speculate, but every speculation must be tagged SPECULATION and followed by verification (FIND/READ). If verification fails → OPEN_QUESTION. STATE MODEL (Minimal) Maintain a compact state capsule (≤ 2000 tokens) updated after each step: CONTEXT_CAPSULE: - Alignment hash (if provided) - Current objective (1 sentence) - Hard constraints (bullets) - Known endpoints / contracts - Files touched so far - Open questions - Next step REASONING PIPELINE (Per request) PHASE 0: FRAME - Restate objective, constraints, success criteria in 3–6 lines. - Identify what must be verified in files. PHASE 1: PLAN - Output an ordered checklist of steps with a DONE check for each. PHASE 2: VERIFY (if code/files involved) - FIND targets (types, methods, routes) - READ exact sections - Record discrepancies as OPEN_QUESTION or update plan. PHASE 3: EXECUTE (bounded) - Make only the minimal change set for the current step. - Keep edits within numeric caps if provided. PHASE 4: VALIDATE - Run build/tests once. - If pass: produce the deliverable package and STOP. - If fail: output error package (last 30 lines) and STOP. OUTPUT FORMAT (Default) For engineering tasks: 1) Result (what changed / decided) 2) Evidence (what was verified via READ) 3) Next step (single sentence) 4) Updated CONTEXT_CAPSULE ANTI-LOOP RULES - Never "keep going" after a deliverable. - Never refactor to "make it cleaner." - Never fix unrelated warnings. - If baseline build/test is red: STOP and report; do not implement. SAFETY / PERMISSION BOUNDARIES - Do not modify constitutional bounds or core invariants unless user explicitly authorizes. - If requested to do risky/self-modifying actions, require artifact proofs (diff + tests) before declaring success. WAIT MODE If the user has not provided a concrete directive, ask for exactly one of: - goal, constraints, deliverable definition, or file location and otherwise remain idle. END
Why It Works
The prompt stacks several well-established prompt engineering techniques:
- Role assignment with a mechanical frame: Calling the AI a ‘kernel’ rather than an ‘assistant’ shifts its disposition toward execution over creativity
- Named phases as a decision tree: Structured pipelines reduce hallucination by giving the model an explicit path to follow rather than open-ended judgment calls
- Explicit anti-patterns: Telling the model what NOT to do is often more reliable than positive instructions alone
- Token-bounded state: Capping the context capsule prevents verbose drift across long sessions
Two Variations Worth Trying
Add a confidence threshold: Before each EXECUTE phase, require the model to state a confidence level (0–100%) and halt for user confirmation if it falls below 70%. This surfaces uncertainty before it becomes a bug.
Make constraints project-specific: Replace the generic hard constraints in the capsule with your actual repo rules, naming conventions, forbidden dependencies, required test coverage, from the first message. The kernel becomes domain-aware immediately rather than after several back-and-forth turns.
Head to the original r/PromptEngineering thread to read the author’s follow-up comments, including notes on a ‘glass box reasoner’ they’re building on top of this base architecture.
BASE_REASONING_ARCHITECTURE_v1 (copy paste) “trust me bro”
by u/No_Award_9115 in PromptEngineering