Overview

The Terrain Mapping Framework (TMF) handles the case the rest of the Ora apparatus cannot handle on its own — when a problem has been named but the territory is not yet known well enough to formulate a Mission, a Resolution Statement, a process, or a milestone. Without TMF, MOM and PEF would be forced to produce strategic content over unmapped territory, which is the failure mode where projects commit to plans that turn out to be impossible because the planner did not know enough about the domain to see the constraints. With TMF, the territory gets mapped first; the calling framework then has the substrate it needs to do its job.

The framework runs in three modes. TM-Initiate runs structured research loops against named knowledge gaps to produce a Terrain Map Artifact — a separate vault document that becomes the durable knowledge substrate for downstream work. TM-Continue resumes a prior Terrain Map that did not fully converge, picking up from the residual gaps with any new information accumulated since. TM-Escalate-Redefine is the framework’s bounded-iteration safety valve — three research loops without convergence triggers an escalation package that returns control to the calling framework (typically PEF) for problem-level redefinition rather than further looping. The framework is iterative by design but bounded: convergence is the only acceptable endpoint, and the loop count is capped to prevent indefinite research that never produces actionable terrain.

The framework’s load-bearing intellectual content is the bounded research loop, the Terrain Map Artifact, and the adjacency classification discipline. The bounded research loop runs through five stages — Layer 1 (gap identification with question-bank expansion against PEF Appendix A’s Define and Analyze questions); Layer 2 (research prompt generation — narrow, targeted prompts per gap, ranked by Specificity Rubric); Layer 3 (research execution via the Deep Research Protocol); Layer 4 (analysis, synthesis, boundary refinement against Excluded Outcomes, and adjacent exploration); Layer 5 (Terrain Map Artifact production or loop continuation). The loop continues until convergence (residual gaps fall below threshold) or until the iteration cap fires. The Terrain Map Artifact is a separate vault document keyed to the calling project’s nexus — it contains the mapped territory, the boundary refinements, the in-scope adjacencies, the out-of-scope adjacencies, the explicit gaps that remain, and the user-readable navigation structure that lets the calling framework orient. The adjacency classification discipline says every adjacent topic surfaced during research gets explicitly classified — in-scope (folded into the project), out-of-scope (recorded for context but not pursued), or uncertain (flagged for the user to decide). The classification prevents the failure mode where research expands the project’s effective scope through silent annexation of adjacent topics.

The framework’s bounded-iteration discipline is the safety valve against unbounded research. Three loops without convergence is the trigger for TM-Escalate-Redefine. The escalation package identifies which aspects of the problem definition the evidence suggests are wrong or unformulable under current constraints and returns control to PEF for problem-level redefinition. No Terrain Map Artifact is produced in escalation mode — the output is the diagnosis. This discipline matters because terrain mapping can become a recursive trap: every research loop surfaces new questions; without a cap, the loop can run indefinitely without ever closing the original gaps. The bounded structure forces the framework to either converge on actionable terrain or escalate honestly when convergence is impossible.

The framework answers questions like: I have a problem I’m trying to investigate but I don’t even know enough to define it well — can you map the territory? My prior research left me with more questions than I started with — can you continue the mapping? I want to start a project but I keep getting stuck because I don’t know enough about the domain to commit to a plan — can you produce the terrain map first?

Systemic context

Terrain Mapping is the unknown-territory handler of the Information Lifecycle System (paired with PFF, PIF, CFF, OFF, and DCA; the system view is in [[Paper — Information Lifecycle System]]). TMF is invoked by [[Framework — Mission, Objectives, Milestones Clarification]] when MOM Outcome 2 fires (terrain not yet mapped); by [[Framework — Problem Evolution]] via PE Layer 5 Gap-to-Action Routing when the supervision drift check or the Constructive Escalation Rule produces an Explore advice; by [[Framework — Process Inference]] when P-Feasibility returns the Cannot-assess-without-exploration verdict. TMF hands off back to the calling framework when convergence is reached (the Terrain Map Artifact gives MOM, PEF, or PIF the substrate they need to proceed); to PEF for problem redefinition when TM-Escalate-Redefine fires. The framework consumes the Deep Research Protocol (a separate framework) for Layer 3 research execution. TMF does not produce Operation cycles, Project milestones, or process specifications — it produces the substrate those frameworks need before they can produce their own outputs.

Ora’s output

Example question: I want to investigate why some open-source projects sustain themselves over decades while others die in a year, but I don’t know enough about open-source economics to even define what to research. Can you map the territory?

Ora’s response (running TMF in Mode TM-Initiate):

The problem is named (“open-source project longevity differential”) but the territory is genuinely unmapped — you do not yet know enough about open-source economics, contributor dynamics, governance models, or sustainability patterns to define a research question that closes anywhere. TMF runs a bounded research loop until either the territory is mapped enough for you to formulate a concrete next step, or three loops fail to converge.

Loop 1 / Layer 1 — Gap identification. Starting from your description, I’ll expand against PEF Appendix A’s Define and Analyze questions. The expanded gap inventory:

Gap 1. What are the historically successful open-source projects across decades, and what do they share? Gap 2. What are the failure modes for projects that died within their first one to three years? Gap 3. What economic models sustain successful projects (foundations, corporate sponsorship, paid contributors, dual licensing, services revenue)? Gap 4. What governance models distinguish sustained projects from ones that fragmented or got captured? Gap 5. What contributor dynamics differentiate sustained projects (BDFL transitions, contributor onboarding, maintainer burnout)? Gap 6. What technical-architecture patterns correlate with sustainability (modularity, interface stability, plug-in architectures)?

Closure criteria per gap: each gap closes when I can answer it with at least three concrete examples and a synthesized pattern.

Loop 1 / Layer 2 — Research prompt generation. Six prompts, one per gap, narrow and targeted. Sample for Gap 3: “What economic models sustain open-source projects across multiple decades? Cite specific projects with each model (foundation-based, corporate-sponsored, paid-contributor, dual-licensed, services-revenue), naming the project, the model details, and how the model has evolved. Include both software libraries and infrastructure projects.”

Loop 1 / Layer 3 — Research execution. Deep Research Protocol runs against each prompt; six research reports return. (Detail elided for the demo; in practice the reports come back as structured material the framework analyzes in Layer 4.)

Loop 1 / Layer 4 — Analysis and adjacency classification. Synthesis surfaces several patterns: foundation-based and corporate-sponsored models dominate the long-lived projects; BDFL transitions are a distinct failure mode worth its own gap; technical modularity correlates with longevity but is not sufficient; community governance maturity (formal contribution paths; decision-making transparency) emerges as a distinct factor not in the original gap list. Boundary refinement: the original framing “why some sustain themselves while others die” was too binary; the actual pattern is a spectrum from “alive at all” through “growing” to “self-sustaining institution.” Adjacencies surfaced: the relationship between corporate open-source and corporate strategy (in-scope — central to economic model question); the regulatory environment for open-source (uncertain — flag for user decision); the developer-economics literature on burnout and motivation (out-of-scope for this terrain map — interesting but not load-bearing for longevity question).

Convergence check. Six gaps named; five answered with three+ concrete examples each plus a synthesized pattern; one (Gap 5 contributor dynamics) requires a second loop to fully close. New gap surfaced (community governance maturity) — added to the residual gap list for loop 2.

Loop 2. Runs against the residual gaps (Gap 5 + community governance maturity). Returns synthesized patterns; both gaps close. Convergence reached.

Layer 5 — Terrain Map Artifact production. I’ll produce the artifact. Outline:

Terrain Map: Open-Source Project Longevity Differential

Boundary statement. The terrain mapped here is the spectrum from “alive at all” through “growing” to “self-sustaining institution” for open-source projects across decades, focusing on the economic models, governance models, contributor dynamics, and technical architecture patterns that correlate with longevity.

Mapped territory.

  • Economic models. Foundation-based (Apache, Linux, Python); corporate-sponsored (Kubernetes, Postgres); paid-contributor (Sourcegraph’s open-source commits); dual-licensing (early MySQL, later Mongo). Patterns: foundations + corporate-sponsorship dominate the long-lived projects; pure community-volunteer models hit ceiling at moderate complexity.
  • Governance models. BDFL transitions are a distinct failure mode (Python’s PEP 8000 transition succeeded; some smaller projects fractured at BDFL exit); formal contribution paths and decision-making transparency emerge as load-bearing.
  • Contributor dynamics. Maintainer burnout is universal; sustained projects have explicit onboarding pipelines and second-tier maintainer benches.
  • Technical patterns. Modularity and interface stability correlate with longevity; plug-in architectures extend life; monolithic architectures shorten it.

In-scope adjacencies.

  • Corporate open-source strategy (the economic-model question depends on it).
  • Community governance maturity (a distinct dimension that emerged from research).

Out-of-scope adjacencies (recorded but not pursued).

  • Developer economics on burnout (interesting; not load-bearing for longevity).

Uncertain adjacencies (flagged for user decision).

  • Regulatory environment for open-source (could become load-bearing if project is investigating policy implications).

Excluded outcomes. “Open-source longevity is purely a function of technical merit” is excluded (research consistently shows economic and governance factors dominate). “All long-lived projects share the same model” is excluded (the four economic models all produce long-lived projects).

Residual gaps closed. All six original gaps + one surfaced gap closed within two loops.

Implications for the calling framework (PEF/MOM). The territory now supports a concrete next step. Candidate Resolution Statement framings: “A comparative case-study analysis of three foundations, three corporate-sponsored, and three paid-contributor projects with longevity > 15 years, identifying the cross-model patterns in governance and contributor dynamics, is published as a 60-page report.” Or alternatively a Passion-shape framing: “Ongoing investigation of open-source longevity patterns through case-study reading and synthesis essays, no terminal endpoint.” MOM’s classification can now run cleanly.

That is what TMF produces. Two research loops; the territory mapped from genuinely unknown to navigable; the Terrain Map Artifact attached to the calling matrix; the calling framework (PEF or MOM) now has the substrate to formulate a concrete next step. The artifact is durable — it stays in the vault as the project’s knowledge substrate even as the project evolves; later iterations can extend the map via TM-Continue if new gaps surface.

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 Terrain Mapping pattern with any AI of your choice. The composition is single-pass for any of the three modes.

For TM-Initiate (most common starting point):

[Paste the framework specification]

Run TM-Initiate.

Current problem space: [Plain prose description of the problem as you currently understand it.]

Known knowledge gaps: [Numbered list of what you know is missing, phrased as questions you cannot currently answer. Partial is fine — Stage 1 will expand the list.]

Closure criteria per gap (optional): [Observable conditions that would mark each gap closed.]

Constraints (optional): [Time, cost, scope boundaries.]

The AI runs the bounded research loop — Layer 1 expands the gap list against the question bank; Layer 2 generates research prompts per gap; Layer 3 executes research (this is the heaviest layer in tokens — the framework calls into the Deep Research Protocol to produce the underlying research reports); Layer 4 synthesizes, refines boundaries, and classifies adjacencies; Layer 5 either produces the Terrain Map Artifact (if convergence is reached) or restarts the loop with the residual gaps.

For best results:

  1. Provide concrete gaps even if you’re unsure. The framework expands incomplete gap lists in Layer 1; partial input is exactly what TMF expects. Empty gap lists slow down the framework but don’t break it.
  2. Trust the bounded-iteration discipline. If the framework escalates after three loops without convergence, that is a real signal — the territory may be unmappable under the current problem framing, and the right move is to invoke PEF for problem redefinition rather than push for more research.
  3. Let the adjacency classification surface uncertain items for your decision. The framework explicitly flags adjacencies it can’t classify on its own. The flagging is the framework’s discipline against silent scope expansion.

The framework is deliberately tool-agnostic. The bounded research loop, the Terrain Map Artifact structure, and the adjacency classification discipline survive the lift to any environment. The Deep Research Protocol invocation can be replaced with whatever research mechanism the calling environment has available (web search; document corpus retrieval; manual research notes).

Other examples

  • TM-Continue extending a prior Terrain Map. Six months after a TM-Initiate run produced a Terrain Map for “competitive landscape of personal CRM tools,” the user has new context (two competitors launched; one dominant tool was acquired; pricing changes are visible across the market). They invoke TM-Continue with the prior artifact and the new information. The framework runs additional research loops focused on the gaps the new context surfaces; the Terrain Map gets extended with the new territory; the user’s project (a competing-tool design) now has the updated substrate. Demonstrates TM-Continue as the durable-substrate maintenance mechanism — the Terrain Map is an asset that compounds over time rather than a one-shot artifact.

  • TM-Escalate-Redefine on an unmappable problem. A user wants to “figure out the right way to teach my child about money.” Three TMF loops run without convergence — each loop surfaces new dimensions (developmental psychology by age range; cultural variation; explicit-vs-implicit teaching modes; the relationship between money and values; class-context-dependent considerations) that expand rather than close the territory. The framework escalates: the problem as framed is genuinely unmappable; the right move is PEF problem redefinition. Candidate redefinitions surfaced: “What approach to financial education matches my values and my child’s current developmental stage?” (narrower; mappable). “How do I produce a single starter conversation about money tailored to my child this year?” (Project-shape; mappable). The user picks one; PEF re-instantiates the matrix with the redefined problem; TMF runs against the redefined gaps and converges. Demonstrates the bounded-iteration discipline as a real safety valve — the framework refused to produce an artifact it knew would mislead.

  • TMF feeding into PIF. A user has a research project goal but P-Feasibility returns “Cannot assess without exploration” — the territory is unmapped. TMF is invoked; runs to convergence; produces the Terrain Map Artifact. P-Feasibility re-runs against the now-mapped terrain; returns Reachable. The Active milestone can be declared; PEF supervises from there. Demonstrates the standard handoff pattern — TMF maps the terrain; PIF then has the substrate to assess feasibility; MOM has the substrate to produce the strategic-layer content.

Citations

The Terrain Mapping Framework draws on traditions in exploratory research methodology, scoping reviews, and bounded-rationality decision-making. The structured research loop draws on systematic-review methodology in evidence-based medicine (Cochrane Reviews) and on scoping-review methodology (Arksey and O’Malley) — explicit gap identification, narrow targeted prompts, structured analysis, convergence criteria. The bounded-iteration discipline draws on Herbert Simon’s bounded-rationality framework — search continues until satisficing criteria are met or until the search budget is exhausted.

The Terrain Map Artifact’s structure (boundary statement; mapped territory; in-scope / out-of-scope / uncertain adjacencies; excluded outcomes; residual gaps; implications for calling framework) is internal to Ora and was designed to make the artifact directly consumable by MOM, PEF, and PIF without requiring the calling framework to re-parse the research. The adjacency classification discipline is a deliberate counter to the failure mode where research surfaces interesting adjacencies that silently get pulled into project scope; the explicit classification forces the user to decide rather than letting scope creep.

The framework is single-author and originated 2026-04-23 alongside the PEF v2.0 changes that wired Outcome-2 (terrain not yet mapped) handoff. The framework is currently at v1.0 with PFF-conforming structure throughout.

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