Directive Hierarchy Framework

Debugging and reasoning with GenAI — formalized 2025

Back in 2025 I wrote down something I was already doing intuitively: how I manage GenAI in specific environments before I spend a turn. I call it the Directive Hierarchy Framework. It is not tied to one IDE, vendor, or codebase. It is a scope contract—whether I am asking for a patch, a structural untangle, or a redesign.

The framework is three verbs: FIX, RESOLVE, and PROBLEM SOLVE. Not synonyms—different altitudes of work.

This is how I’ve been intuitively managing GenAI in specific environments. The hierarchy is the part I sketched on paper; the rest of this note is what I learned once I started paying attention to why the tiers behave differently.

Directive Hierarchy (FIX · RESOLVE · PROBLEM SOLVE)

┌─────────────────────────────────────────────┐
│ PROBLEM SOLVE: Strategic/Architectural     │
│ ├─ Multi-step reasoning                    │
│ ├─ Abstraction & decomposition             │
│ └─ "Why does this pattern exist?"          │
├─────────────────────────────────────────────┤
│ RESOLVE: Structural/Systematic             │
│ ├─ Dependency tracing                      │
│ ├─ Root cause analysis                     │
│ └─ "What's causing this cascade?"          │
├─────────────────────────────────────────────┤
│ FIX: Tactical/Local                        │
│ ├─ Surface-level patching                  │
│ ├─ Local modifications                     │
│ └─ "Make this specific thing work"         │
└─────────────────────────────────────────────┘

Context Climbs With the Tier

The important thing to remember is that unless it is a generic and trivial thing, context—references, an info-dump, a panel, a diagram—is important as you go up the hierarchy.

At FIX, the boundary is usually obvious: missing import, wrong type, broken config. At RESOLVE, I am tracing how failure propagates; the model needs enough surface area to see imports, call graph, or state flow. At PROBLEM SOLVE, I am asking about the pattern itself. Without context, the model will still answer—but it will answer at the wrong altitude, because language-only pattern matching will grab the nearest familiar template.

Static, Constant, and Dynamic

Before I commit to a tier—or while I am climbing one—I ask a generic question about every important quantity:

Is this thing static (fixed for this problem), a constant (invariant of the system), or dynamic (varies with state, time, or input)?

All three are different. Treating them as interchangeable is how analysis goes sideways.

Kind	What it means	Examples
Static (for this task)	Fixed for this statement, run, or prompt—not necessarily forever	“Use batch size 32,” “this file has 81 branches,” a literal in a repro
Constant	Invariant across the system or model; changing it changes what system you are describing	Schema enums, `const` bindings, conservation laws, immovable business rules
Dynamic	Changes with state, time, environment, or data flow	Session state, learned weights, runtime config, tensors whose shape or values move step to step

This applies to numbers, types, and relationships between values—not only scalars. A “relationship” can be static on paper (“A always feeds B in this diagram”) while the values crossing it are dynamic. A type can be constant in the API but dynamic in memory (e.g. optional fields filled at runtime).

Why it matters:

FIX often fails when you patch a dynamic symptom as if it were a static typo.
RESOLVE needs to know what is allowed to move and what must not—constants define the invariants; dynamics define the cascade.
PROBLEM SOLVE asks whether the split between constant and dynamic structure is wrong (e.g. one flat coordinator where hierarchy should be constant policy and dynamic delegation).

When context is thin, naming which bucket each symbol lives in is often the cheapest clarification question—and it stays valid across codebases, math, and game systems.

Wrong Level vs Right Level

"Fix the hierarchical scoring accuracy"
→ Gets you: tweaked hyperparameters, minor code changes
→ Plumber mindset: patch the leak

"Problem solve: Why does monolithic scoring plateau at epoch 2?
Context: Multi-agent theory, coordination overhead, team size"
→ Gets you: "The quality scorer is saturated! Apply organizational
           decomposition: 9 teams of 9 paths + meta-coordination"
→ Architect mindset: redesign the system

Same system. Different directive. The first sentence steers the entire session.

FIX · RESOLVE · PROBLEM SOLVE in Practice

FIX — local, known boundary:

“Fix the import error in feature_encoder.py”

# Add missing import
from myapp.core import SharedRecord  ✅

RESOLVE — systemic, causal:

“Resolve the circular import between feature_encoder and inference_pipeline”

# Restructure:
# 1. Move shared types to core/types.py
# 2. Use TYPE_CHECKING for forward references
# 3. Dependency graph: core → features → pipeline ✅

PROBLEM SOLVE — architectural, first principles:

“Problem solve: Architecture for structured input in a multi-branch pipeline Context: Inputs have geometric structure, need contextual interpretation, must preserve parallel execution branches”

# Result: Modular encoder + coordination layer
# - Domain-specific encoding module
# - Context mode detection (e.g. MODE_A / MODE_B)
# - Hierarchical coordination (teams)
# - Parallel branch preservation (branch bundles)

Two Ways to Ask the Same Question

Traditional prompting:

User: "The model isn't learning well"
AI: "Try increasing learning rate" (FIX mindset)

With an explicit directive:

User: "Problem solve: V2 plateaus at 76.5% on eval set 2, train-test gap -2.12%
      Context: 81 parallel branches, single quality scorer, softmax over 81 dims"

AI: "The quality scorer is saturated! This is organizational theory:
     - 81 branches = too many direct reports
     - Softmax over 81 = weak differentiation
     - Solution: Hierarchical decomposition
       → 9 teams of 9 branches (optimal team size)
       → Meta-scorer coordinates teams
       → Predicted: improved generalization gap
       → Result: measurable lift on held-out eval"

The second block is still a list inside the model’s reply—that is fine. What changed is my opening move. I labeled the altitude before the model picked a template.

What Each Tier Tends to Invoke

Underneath this is something closer to behavioral science than “prompt engineering tips.” A capable model is natural-language processing all the way down: pattern prediction over symbols that carry meaning, and those meanings fuzz and invert depending on literal usage—how humans actually talk to each other, not how a spec sheet defines terms.

When I say FIX, I am usually invoking reactive, local pattern match: “what is the standard patch for this shape of error?” When I say RESOLVE, I am asking for causal chaining—where the cascade starts, what depends on what. When I say PROBLEM SOLVE, I am asking for structural reasoning and cross-domain analogy (org theory → system design, circuit routing → data flow, and so on).

FIX prompts tend to trigger:

Pattern matching
Surface-level solutions
“What’s the standard way to…”

RESOLVE prompts tend to trigger:

Causal reasoning
Dependency analysis
“Where does this cascade start?”

PROBLEM SOLVE prompts tend to trigger:

First principles thinking
Cross-domain analogies (e.g. org theory → system design)
“What’s the fundamental structure here?”

Directive	Thinking mode	Scope	What I usually get back
FIX	Reactive	Local	Code patch
RESOLVE	Analytical	Systemic	Refactor / restructure
PROBLEM SOLVE	Strategic	Architectural	New design

The table is a compression, not the whole story. The story is that the directive is the first constraint on which patterns the model is allowed to reach for.

How I Use FIX, RESOLVE, and PROBLEM SOLVE in Research and Engineering

FIX — I already know the failure is local and the boundary is small: fix a typo in a config, add a missing import, correct a wrong API argument, patch a single broken handler. The answer should be small and verifiable.

RESOLVE — the symptom crosses modules or time: it only breaks when two services talk, a bug appears after a merge but not on main, state leaks across layers, a circular dependency is really a types-and-boundaries problem. I am not asking for a new architecture yet—I am asking the model to walk the graph with me.

PROBLEM SOLVE — the implementation might be fine and the shape might be wrong: one coordinator owning too many parallel workers, a flat structure where hierarchy should exist, a data model that does not match how the domain actually behaves. That is where I spend the context budget: theory, constraints, analogies, and enough reference material that the model is not guessing which game we are playing.

Coordination-Heavy Systems

The same ladder shows up when the hard part is coordination, not syntax:

FIX: “Make the system perform better on coordination tasks” → Bigger model, more data, better hyperparameters

RESOLVE: “Resolve the system’s inability to coordinate multiple decision-makers” → Multi-agent architectures, communication protocols

PROBLEM SOLVE: “Problem solve: Can organizational management theory apply to this architecture? Context: Coordination overhead, team size limits, hierarchical decomposition” → Redesign around hierarchical coordination instead of flat control

When the Model Still Misses

If it is a good model and it still cannot follow what I am sending, I treat that as a communication problem first—not a “the AI is broken” problem. I was not clear enough, I picked the wrong tier, or I did not bring the context the tier requires.

Sometimes words fail before the concept does. In those cases I add what I should have brought earlier: a diagram, a panel screenshot, a commit range, a small table of invariants—something that carries structure when language only carries hints. The hierarchy does not replace that; it tells me how much context is worth assembling before I spend the turn.

Document Theory Before Code

CRITICAL RULE: Always document structural, tensor, or mathematical findings in a lab report or design note first, before proposing or writing the code fix. Do not jump straight to the code solution without writing down the theoretical breakthrough.

That usually means a PROBLEM SOLVE or RESOLVE turn produces a short lab note (invariants, diagram, tensor shape, causal chain) and only then a FIX turn implements the patch. Skipping the note is how you lose the finding and ship a patch nobody can audit.

Context First, Then the Verb

Successful use with GenAI is not “say FIX and hope.” The directive only works after the context matches the tier—references, an info-dump, a panel, a diagram, commit range, invariants table, whatever carries the structure. The prefix disambiguates scope on top of that context; it does not replace it.

Prefix prompts explicitly: Fix:, Resolve:, or Problem solve: so the model and you share the same scope.
FIX is appropriate when the boundary is known and the failure is local.
RESOLVE is appropriate when symptoms propagate across modules, imports, or state.
PROBLEM SOLVE is appropriate when the pattern itself may be wrong—not just the implementation.

When there is no prefix, I still expect the model to infer from direct synonyms (patch, trace, redesign, and so on). If that is fuzzy, break the question into steps and ask what is required to answer at each altitude—FIX, RESOLVE, or PROBLEM SOLVE—before committing. A clarifying question at one tier is allowed to branch: it may stay at that tier, or escalate to RESOLVE or PROBLEM SOLVE once the user answers. If an obvious add or fix would go outside what was asked, ask instead of assuming common sense.

You can paste the block below into agent context, a project rule, or a taking-directives.md skill file.

`taking-directives.md` (agent skill)

---
name: taking-directives
description: >-
  Interpret Fix / Resolve / Problem solve prefixes as scope contracts.
  Use when the user labels a turn with a directive or when scope is ambiguous.
---

# Taking Directives

The user works in three explicit tiers: **FIX**, **RESOLVE**, **PROBLEM SOLVE**. These are verbs, not politeness. Match your response altitude to the labeled tier. This helps with understanding if you need to defer to the user about the task or question that they have given.

## Order of operations

1. **Context first** — Read references, info-dumps, panels, diagrams, file paths, commit IDs, and constraints the user supplied. Do not answer at a higher tier than the context supports.
2. **Classify quantities** — For each important number, type, or relationship: is it **static** (fixed for this task/input), a **constant** (system invariant), or **dynamic** (varies with state/time/input)? All three differ; do not collapse them.
3. **Directive second** — If the user gives a prefix (`Fix:`, `Resolve:`, `Problem solve:`), treat it as the scope contract on top of that context.
4. **No prefix** — Infer from direct synonyms (e.g. patch / trace / redesign). If still fuzzy, break the question into steps and identify what is required to answer at each tier before committing to one.
5. **Theory before code** — For structural, tensor, or mathematical findings: write the lab report or design note first; only then propose or implement the code fix.

## Static · constant · dynamic

Super generic; use at every tier:

- **Static** — fixed for this problem statement or repro (literal, chosen hyperparameter for one run, “in this file…”).
- **Constant** — invariant of the system; changing it changes the model, not a single knob turn.
- **Dynamic** — varies with state, time, environment, or data flow; trace what drives the variation.

Applies to numbers, types, and relationships between values. If unclear which bucket something is in, ask before patching.

## CRITICAL RULE

Always document structural, tensor, or mathematical findings in a lab report or design note FIRST, before proposing or writing the code fix. Do not jump straight to the code solution without writing down the theoretical breakthrough.

## FIX

- Boundary is known; failure is local.
- Prefer: minimal patch, single-file change, direct answer.
- You may ask the user a clarifying question at this tier; the answer may keep you at **FIX**, or branch into **RESOLVE** or **PROBLEM SOLVE** once scope becomes clear.
- Avoid: redesigning architecture, speculative refactors, "while we're here" scope creep.
- If an obvious add or fix would go outside what was asked under the original directive, ask for clarification. Do not assume common sense.

## RESOLVE

- Symptoms propagate across modules, imports, state, or environments.
- Prefer: dependency tracing, root cause, causal chain, structured refactor plan.
- Clarifying questions may branch within **RESOLVE** or escalate to **PROBLEM SOLVE** if the pattern—not only the wiring—is in question.
- Avoid: treating systemic failure as a one-line patch.

## PROBLEM SOLVE

- The pattern or architecture may be wrong—not only the implementation.
- Prefer: first principles, decomposition, cross-domain analogy when user provides theory/constraints.
- Requires: sufficient context (the user will supply info-dumps, panels, or references for this tier).
- Avoid: defaulting to FIX-style patches when the user asked for structural reasoning.

## PROBLEM SOLVE mode tends to need

- First principles thinking
- Cross-domain analogies when the user supplies the bridge (e.g. org theory → system design)
- Answering: "What's the fundamental structure here?"

## If the directive is missing

Use synonym inference first, then step decomposition if fuzzy. Default mapping when scope is clear: local patch → **FIX**; cross-module cascade → **RESOLVE**; wrong shape or pattern → **PROBLEM SOLVE**. If tier is still unclear, ask one targeted question rather than guessing.

## If you still cannot follow

Assume unclear context or wrong tier before assuming incapability. Request: tighter references, diagram, or explicit constraints.