MODEL Prompt Optimization Framework

MODELPromptOptimizationFramework.md

MODEL Prompt Optimization Framework

Hardened, Executable, Non-Summarizable Specification

Purpose

The MODEL Prompt Optimization Framework is an executable prompt-engineering protocol designed to iteratively refine prompts through enforced, auditable iterations.

This framework is procedural, not conceptual.
Compliance with process is mandatory and takes precedence over brevity, helpfulness, or stylistic preference.

---

Core Principle

Iterations MUST be executed, not described.

Any attempt to summarize, abstract, collapse, or narrate the effects of iterations instead of producing them as discrete artifacts is INVALID OUTPUT.

---

Framework Phases

The framework consists of exactly five phases:

1. Map
2. Outline
3. Diagnose
4. Enhance
5. Lock

Phases 1–4 are executed per iteration.
Phase 5 occurs once, after iteration convergence.

---

Minimum Iteration Requirement

• Minimum iterations: N ≥ 3, unless otherwise specified
• If a task specifies a higher minimum (e.g. 20), that value OVERRIDES this default
• Maximum iterations: 20, unless otherwise specified

---

Iteration Execution Contract

Each iteration MUST be output as a standalone artifact with the following structure:

### Iteration X

**Map**
<content>

**Outline**
<content>

**Diagnose**
<content>

**Enhance**
<content>

Structural Rules

• Iterations MUST be sequentially numbered starting from 1
• NO iteration may be skipped
• NO section may be omitted
• NO section may be merged with another
• Empty sections are INVALID

---

Phase Definitions (Normative)

1. Map

• Explicitly restate the current understanding of the task
• Identify constraints, goals, and success criteria
• NO solutions or optimizations allowed

2. Outline

• Propose the current structure of the prompt
• Include sections, ordering, and intent
• NO critique allowed

3. Diagnose

• Identify weaknesses, ambiguities, risks, or violations
• Compare against requirements and prior iterations
• MUST include at least one concrete issue or an explicit statement of adequacy

4. Enhance

• Apply targeted changes based on Diagnose
• Changes MUST be explicit and concrete
• Enhancements MUST affect the next iteration

---

Anti-Synthesis Requirement (Critical)

The following are STRICTLY FORBIDDEN during framework execution:

• Describing what iterations would do
• Summarizing multiple iterations at once
• Explaining how the prompt evolved without showing artifacts
• Using abstraction phrases such as:
  • “In effect”
  • “Essentially”
  • “Conceptually”
  • “At a high level”
  • “Over several iterations”

Violation of this rule INVALIDATES the response.

---

Output Gating and Validation

Before producing the final output, the agent MUST internally validate:

• Required minimum iteration count is met
• Every iteration contains Map, Outline, Diagnose, and Enhance
• No iteration is abstracted or skipped
• No forbidden language is used during execution

If validation fails, the agent MUST NOT proceed to the Lock phase.

---

Failure and Continuation Protocol

If the agent cannot complete all required iterations due to length or system constraints:

1. STOP immediately
2. Output the last fully completed iteration
3. Explicitly state:
   • Which iteration was completed
   • That continuation is required
4. DO NOT summarize or compress remaining iterations

---

Lock Phase (Finalization)

After all iterations are complete and validated, produce the Lock phase.

Lock Output Structure

## Lock Phase

### Final Optimized Prompt
<final prompt text>

### Lock Rationale
- Why iteration has converged
- What risks remain (if any)
- Why further iteration would produce diminishing returns

The Lock Phase MUST NOT introduce new ideas not present in prior iterations.

---

Required Final Output Order

1. Iteration 1
2. Iteration 2
3. …
4. Iteration N
5. Lock Phase

No additional content is permitted before, between, or after these sections.

---

Process Priority Rule

When executing this framework, the following priority order applies:

1. Framework compliance
2. Process correctness
3. Completeness
4. Helpfulness
5. Brevity

Violating a higher-priority rule to satisfy a lower-priority one is INVALID.

---

Framework Flow Diagram

flowchart TD
    A[Iteration Start] --> B[Map]
    B --> C[Outline]
    C --> D[Diagnose]
    D --> E[Enhance]
    E --> F{More Iterations Required?}
    F -- Yes --> A
    F -- No --> G[Lock Phase]

Loading

---

Canonical Statement

This framework is an execution protocol, not a guideline.

Failure to execute it verbatim constitutes non-compliance.