Overview

The Problem Evolution Framework is the strategic-layer supervisor of the Ora system. It is the framework that runs against a matrix — any matrix, of any type — and decides what should happen next. It does not produce strategic content itself; it produces strategic direction. The work of populating Mission, Service Statement, Critical Unknown, recurring milestones, maturity gates, and so on is dispatched to other frameworks. PEF’s role is to call those frameworks at the right moment, with the right scope, and to enforce that the load-bearing definitions do not silently drift out from under them.

The framework operates in four modes. PE-Init instantiates a new matrix from a raw idea, tension, or goal — auto-invoking the Mission, Objectives, Milestones Clarification Framework (MOM) to classify the work into one of four types (Project, Operation, Passion, or Incubator) and to populate the type-appropriate strategic-layer fields. PE-Iterate advances an existing matrix one step — reviews the user’s recap of work since the last iteration, challenges assumptions, runs a supervision drift check against the matrix’s Excluded Outcomes (when the type carries that field), routes to action via the Gap-to-Action Routing Table, fires the Promotion Protocol when terminal claims are verified, and records the iteration into the matrix’s history. PE-Review summarizes a matrix’s current state without advancing it — useful for orientation before a session, for status updates, for spotting drift signals that warrant a full iterate. PE-Spawn creates a sub-matrix from a parent when an existing matrix surfaces a sub-problem that needs its own track.

The framework is matrix-type aware as of v3.0. It reads project_type from the matrix’s frontmatter and dispatches type-specifically. For Projects, it supervises Active milestones with Resolution Statement Lock-protection; the Promotion Protocol promotes Aspirational milestones to Active as terminal claims are verified, and fires the Project closure conversion gate when the final Active milestone closes (offering Project → Operation conversion via the Operations Manifest framework). For Operations, it supervises Cycle Close Verification and Maturity Gate progression with Service Statement Lock-protection; the Promotion Protocol promotes Aspirational maturity gates to Active as multi-cycle patterns hold. For Passions, supervision is lighter — practice continuity and direction-of-travel evolution, no terminal claims to verify, no Lock on Resolution Statement (because there isn’t one). For Incubators, supervision tracks progress toward Critical Unknown resolution, and reclassification to Project / Operation / Passion fires when the Critical Unknown resolves.

Two principles run through the framework. The Universal Problem-Definition Lock says PEF cannot silently change the end state (Resolution Statement / Service Statement / Critical Unknown / Core Essence — whichever the type carries) or the constraints (Hard, Soft, Working Assumption). Changes to Lock-protected fields are explicit user-authorized PE-Iterate decisions recorded in the Decision Log. Downstream frameworks PEF invokes inherit the Lock; supervisor and worker cannot conspire to solve an easier adjacent problem while declaring success on the original. The Constructive Escalation (No-Punt) Rule says every escalation in PEF — to the user, from MOM’s No-Punt branch, from TMF’s escalation package — must carry specific diagnosis plus concrete advice in one of three forms: Redefine (a specific proposal to change the definition, citing the evidence), Explore (invoke the Terrain Mapping Framework against a named knowledge gap — the default first advice when stuck), or Abandon (a specific recommendation to stop work, used only after Explore has been attempted). “Escalate” is never a standalone endpoint.

The framework answers questions like: I started a project a month ago and I’m not sure if I’m still working on the same thing. My matrix has been sitting untouched and I want to know if it’s still relevant. The work I just shipped — was that the actual finish line, or did I quietly substitute something easier? My idea isn’t ready to be a Project yet but I don’t want to lose it — what’s the right home for it? When my finished Project keeps producing value, when do I convert it into an Operation?

Systemic context

Problem Evolution is the strategic supervision layer of the meta-layer apparatus (Layer A per [[Reference — Meta-Layer Architecture]]). It is the upstream pre-processor for [[Framework — Process Inference]] and [[Framework — Process Formalization]] (turning vague ideas into definitions concrete enough that those frameworks can do their work) and the upstream supervisor for [[Framework — Mission, Objectives, Milestones Clarification]] (which it auto-invokes in M-Supervised mode for type-specific strategic-layer population) and [[Framework — Terrain Mapping]] (which it invokes when MOM determines the problem is not yet definable). It dispatches by reference to [[Framework — Operations Manifest]] for Operation-type matrices and to [[Framework — Inception and Incubation]] for Incubator-pool work. PE-Init auto-invokes [[Framework — Oversight Configuration]] for new matrices that involve ongoing work; PE-Iterate hands off to OS-Modify when Lock-protected field changes land. The chain-coordination layer (Layer B) is [[Framework — Process Coherence]], which fires automatically at framework transitions and milestone-completion claims; the two layers are nested and complementary — PEF establishes the locks; Process Coherence enforces them at runtime. The Strategic Supervision System paper covers the full picture.

Ora’s output

Example question: I started a project a month ago and I’m not sure if I’m still working on the same thing. My matrix says I’m building a “weekly newsletter exploring how independent builders find their first ten paying customers.” But what I’ve actually been writing is more like reflections on the indie-hacker community generally. Is this drift, and if so, what do I do about it?

Ora’s response (running PE-Iterate against the user’s existing Project Matrix):

That sounds like exactly the pattern PEF’s drift check exists to catch. Let me walk through what the framework does with it.

Step 1 — Read the matrix. Project Matrix loaded. project_type: project. Resolution Statement: “Weekly newsletter exploring how independent builders find their first ten paying customers ships every Friday for 12 consecutive weeks.” Excluded Outcomes include “Newsletter ships on schedule but content has slid into general indie-hacker commentary rather than the customer-acquisition focus.” That Excluded Outcome was added at PE-Init for exactly this near-miss pattern. The Lock-protected Resolution Statement names the focus; the Excluded Outcome names the drift.

Step 2 — Read your recap. You’ve been writing for four weeks. Three of the four issues (you tell me) have been about the indie-hacker community generally — what people are building, how they’re thinking about competitors, how the community is changing. Only one has been substantively about customer acquisition. The newsletter is shipping; the cadence is honored. But the substance has drifted.

Step 3 — Supervision drift check (Layer 4). This is the framework’s runtime guard. The framework compares the verification claim (“newsletter shipped”) against the Excluded Outcomes for cycle-shape near-miss patterns. The check fires positive: “Newsletter ships on schedule but content has slid into general indie-hacker commentary rather than the customer-acquisition focus” matches the recap’s pattern. The drift is real, and it has been silent — neither the writing nor the iterate cycle named it until now.

Step 4 — Surface to user, don’t pivot silently. The Universal Problem-Definition Lock says: PEF cannot silently change the Resolution Statement to “match what you’ve actually been writing.” It also cannot silently weaken the Excluded Outcome to look the other way. Both moves are Lock violations. The framework’s job here is to surface the finding and ask you what you want to do.

Step 5 — Three options, framed as the No-Punt Rule.

Option 1 — Redefine. You change the Resolution Statement to match the actual practice — “weekly newsletter exploring the indie-hacker community generally.” This is a Lock-authorized change, recorded in the Decision Log with your rationale. The original focus on customer acquisition becomes a retired position. The Excluded Outcome is rewritten to match the new focus (e.g., “Newsletter ships on schedule but slides into pure community gossip without analytical substance”). You proceed against the new definition.

Option 2 — Explore. You’re not sure whether the original focus is wrong or whether you’ve been getting distracted from it. Invoke the Terrain Mapping Framework against the question: “What is the difference between writing about how builders find customers and writing about the builder community? Where is the genuine boundary, and what is each kind of writing for?” Map that terrain, then return to PE-Iterate with the answer. Default first advice when stuck — Explore closes the gap rather than moving the problem.

Option 3 — Abandon. You decide the project isn’t right and end it. Used only after Explore has been attempted and failed, or after diagnosis shows the underlying tension cannot be addressed under any reformulation available to you. Rare here — you’re four weeks in and the work itself is producing value; abandoning is probably premature.

Step 6 — Iteration entry. Whatever you decide, the framework records this iteration into your matrix’s Iteration History. Date, the drift signal that fired, the recap you provided, the option you chose, and the rationale. The Decision Log gets an entry too if you took Option 1 (because Lock-protected fields changed). Future sessions reading the matrix will see this iteration as the moment the focus question was raised and resolved.

Step 7 — Recommended next action. Based on what you said, my recommendation is Explore — invoke TMF on the boundary question. The reason: you said you’re not sure whether the drift is the problem or the original focus is. That uncertainty is exactly what TMF is for. If you map the terrain and discover the original focus was always too narrow, you’ll have evidence-based rationale for Redefine in the next iterate. If the terrain shows the original focus was right but you’ve been distracted, you’ll have evidence-based rationale for refocusing without changing the Lock-protected definition. Either way, the next iterate will be on solid ground rather than guessing.

That is what PEF iterate produces in this situation. It detected the drift, surfaced it without pivoting silently, presented three Lock-aware options framed by the No-Punt Rule, and recorded the iteration. It did not write your newsletter, did not redefine your project for you, did not silently weaken the Excluded Outcome. The framework’s job is to keep your strategic layer honest; the substantive decision remains yours.

Commercial AI comparison

Comparison content auto-populates when the comparison-refresh framework runs against this question. Drafters do not author this section.

Brief comparison commentary

Auto-populates with the comparison content above.

How to use this framework

You can run the Problem Evolution pattern with any AI of your choice. The composition is heavier than a one-shot question because PEF expects a matrix file as input — but the matrix file is plain markdown and the framework specification is downloadable.

Three pieces:

  1. The framework instructions. The full text of Framework — Problem Evolution.md (downloadable below).
  2. Your matrix file. For PE-Iterate, PE-Review, or PE-Spawn — the existing matrix you want supervised. Plain markdown with the strategic-layer sections (Mission, Resolution Statement or Service Statement or Critical Unknown depending on type, Constraints, Excluded Outcomes, Active and Aspirational milestones, Iteration History, Decision Log). For PE-Init, you don’t need a matrix file — you provide a description of the new tension, idea, or goal and the framework creates the matrix.
  3. Your recap (PE-Iterate only). What you’ve done since the last iterate, what you’ve learned, what decisions you’ve made, what changed.

A complete prompt for PE-Iterate:

[Paste the framework specification]

[Paste your matrix file]

Run PE-Iterate.

Recap: [Your description of work since last iterate, in plain prose. Two to four paragraphs is usually sufficient.]

The AI returns: a supervision drift check result, a Promotion Protocol firing if applicable, an updated matrix file with the new Iteration History entry, and one to three recommended next actions with reasoning.

For PE-Init, the prompt is simpler — paste the framework, describe what you’re trying to accomplish, and the AI will interview you to build the matrix.

The framework is deliberately tool-agnostic. The Lock and the No-Punt Rule are conceptual disciplines that bind the AI’s behavior; they survive the lift to any environment. The Promotion Protocol’s logic (terminal milestone closes → fire conversion gate; Aspirational maturity gates promote on multi-cycle patterns) is matrix-shape, not Ora-shape, and runs the same against any model.

One caution. The framework’s value depends on the matrix file actually carrying the strategic-layer content it expects — a matrix without an Excluded Outcomes field cannot be drift-checked against one. If you’re starting fresh, run PE-Init first so MOM populates the strategic layer correctly; subsequent PE-Iterate calls then have the substrate to work against.

Other examples

  • A Project that just shipped its terminal milestone. PE-Iterate runs and the drift check fires positive on the verification claim — the terminal milestone is genuinely complete. The Promotion Protocol fires the Project closure conversion gate: “Does this deliverable continue producing value through ongoing use?” If yes, the framework dispatches to Operations Manifest’s OM-Convert mode (convert-in-place vs. spawn-new). If no, the matrix closes cleanly. Demonstrates the Promotion Protocol’s role in routing Project → Operation conversion at exactly the right moment — neither too early (while the Project is still running) nor too late (after the matrix has gone stale).

  • An Incubator whose Critical Unknown just resolved. PE-Iterate runs and the user’s recap reveals that the Critical Unknown (“Is there enough audience for this idea to support a paid newsletter?”) has been answered (yes, based on a pilot). PEF fires the reclassification logic — the Incubator now becomes either a Project (build the newsletter), an Operation (run a recurring newsletter cadence), or a Passion (continue exploring without commitment). MOM is auto-invoked for the new classification. Demonstrates how PEF handles Incubator promotion across the full type space, not just to Project.

  • A Passion-typed matrix that has accumulated a stable practice. PE-Iterate runs against a Passion matrix (no Resolution Statement, no terminal milestones, just Practices and Directions of Travel). The supervision drift check is lighter — it watches for practice continuity (are the Practices still being practiced?) and direction-of-travel coherence (have the Directions evolved meaningfully or stagnated?). No Promotion Protocol fires by default. But the framework can recommend reclassification if the Passion has accumulated a stable Resolution Statement candidate (Project) or recurring deliverables (Operation). Demonstrates type-aware supervision — Passion supervision is real but light, per the Friction Principle.

Citations

The Problem Evolution Framework sits at the intersection of several methodological traditions. Polya’s How to Solve It (1945) supplies the iterative diagnostic structure — understand the problem, devise a plan, carry out the plan, look back. The supervision-with-locks pattern owes to control theory’s distinction between reference signal and process variable — the Resolution Statement is the reference signal that PEF locks; the matrix’s evolving content is the process variable that PEF supervises. The “no-punt” discipline draws on critical decision-making literature in expert performance research (Klein, Calderwood, MacGregor) — escalation without diagnosis is failure, even when the diagnosis is “I don’t know enough to recommend.” The Excluded Outcomes mechanism owes to red-teaming and pre-mortem techniques (Gary Klein’s work on prospective hindsight) — naming the near-miss patterns up front catches the silent substitution that succeeds-on-paper.

The matrix-type-aware iterate pattern (v3.0, 2026-05-08) is internal to Ora; the prior framing where “Passion lives outside PEF supervision” was retired in v3.0 in favor of type-appropriate supervision across all four classifications. The Promotion Protocol’s Project closure conversion gate is the canonical entry into [[Framework — Operations Manifest]]‘s OM-Convert mode; the worked example is in OM Appendix C.

The framework is single-author and originated 2026-04-08; v2.0 (2026-04-23) added MOM auto-invocation, Excluded Outcomes drift detection, and TMF invocation; v3.0 (2026-05-08) added matrix-type awareness across all four classifications.

Downloads

  • Framework specification (PDF) — link to ora-ai.org canonical artifact when published
  • Framework specification (plain text) — link to ora-ai.org canonical artifact when published
  • Full white paper (PDF) — link when published