Overview

The Process Inference Framework (PIF) is the upstream companion to Process Formalization. Where PFF formalizes a known process into a runnable framework, PIF discovers the process when it is not known. The user has a current state and a desired end state but no clear transformation path between them. PIF infers the path — or determines that no viable path exists under current constraints, or that the territory is unmapped enough to require Terrain Mapping first. Once a viable path is discovered, PIF can hand off to PFF for formalization, or the user can run the path manually if formalization is premature.

The framework runs in five modes. P-Infer discovers a transformation path from current state to desired end state when neither the path nor any partial process is known. P-Debug identifies the hidden failure point in a process that fails somewhere unknown — given the expected behavior and the actual behavior, the framework infers where the breakdown happens and what the corrected path looks like. P-Decompose breaks a complex endpoint into solvable subproblems with dependency ordering — useful when the endpoint is too large to attack as a single transformation. P-Formalize prepares a discovered process for PFF handoff — produces the PFF-ready package describing the inputs, outputs, layers, and verification criteria. P-Feasibility is the lightweight verdict mode used by MOM under PEF supervision — given a candidate milestone, the framework returns Reachable / Reachable with conditions / Not reachable / Cannot assess without exploration without producing a full process. P-Feasibility runs Layers 1 and 2 plus a dedicated Feasibility Assessment, skipping the path-generation layers; it is the cheap version that supports M-Supervised milestone verification at scale.

The framework’s load-bearing intellectual content is the uncertainty map and the probe design discipline. The uncertainty map (Layer 2) catalogs what the user knows they do not know — missing substeps, hidden dependencies, unknown bottlenecks, ambiguous resources. It is the structural counterpart to the candidate path: every gap in the path corresponds to an entry in the uncertainty map; every entry in the map corresponds to either a knowable answer (the framework can resolve it through reasoning or research) or a probe (an explicit small experiment designed to surface the answer cheaply). The probe design discipline (Layer 5) says probes must be specifically scoped to the gap they are testing — a probe that tests three things at once cannot diagnose which thing failed. Each probe carries its question, its method, its predicted outcome under the working hypothesis, its predicted outcome under the alternative hypothesis, and its cost.

The framework’s verdict structure makes the answer inspectable. P-Feasibility’s four-way verdict — Reachable (a viable path exists; can be discovered with the available resources), Reachable with conditions (a viable path exists if specific apparatus is built first or specific resources are obtained), Not reachable (no viable path under current constraints; the constraints would need to change), Cannot assess without exploration (the territory is unmapped; PIF cannot determine feasibility from current state alone; hand off to TMF) — distinguishes the four cases that downstream supervision (PEF, MOM) needs to dispatch on. PEF’s MOM Invocation Protocol passes Active milestone candidates through P-Feasibility to determine the Active/Aspirational split; Reachable milestones become Active; Reachable-with-conditions milestones become Aspirational with the conditions captured as Contingency notes; Not reachable milestones surface to the user for revision; Cannot assess milestones trigger Terrain Mapping invocation.

The framework answers questions like: I have inputs and a desired output but I don’t know how to get from one to the other — can you figure out the process? My existing process fails somewhere and I can’t tell where — can you diagnose it? My endpoint is too big to attack as one piece — can you break it down? I just discovered a process that works but it’s all in my head — can you prepare it for proper formalization?

Systemic context

Process Inference is the path-discovery framework of the Information Lifecycle System (paired with Process Formalization as the formalization framework, and with Corpus Formalization, Output Formalization, Terrain Mapping, and Decision Clarity Analysis as the rest of the system; the system view is in [[Paper — Information Lifecycle System]]). PIF is invoked by [[Framework — Mission, Objectives, Milestones Clarification]] in M-Supervised mode for P-Feasibility verification of Active milestones — every Active milestone passes through P-Feasibility before being declared Active; the verdict drives the Active/Aspirational split. PIF hands off to [[Framework — Process Formalization]] via P-Formalize when a discovered process is ready for formalization. PIF hands off to [[Framework — Terrain Mapping]] when the verdict is Cannot assess without exploration — the territory needs mapping before feasibility can be determined. PIF is supervised by [[Framework — Problem Evolution]] when invoked under PEF (the Lock binds PIF’s outputs; the No-Punt Rule binds escalations).

Ora’s output

Example question: I have a folder of meeting transcripts (300 files, ~30 minutes each, plain text from Whisper). I want them organized so I can find the meeting where any specific topic was discussed. I have no idea how to do this. Can you figure out the process?

Ora’s response (running PIF in Mode P-Infer):

The current and desired end states are well-defined; the path is unknown. P-Infer is the right mode. I’ll work through the framework’s layers.

Layer 1 — Endpoint elicitation and problem classification. Current state: 300 plain-text meeting transcripts in a folder. Desired end state: ability to query “where was X discussed?” and get the relevant meeting(s) returned. Problem class: information retrieval over a corpus — well-studied territory; multiple known process families. Implication: P-Feasibility will likely return Reachable or Reachable-with-conditions; P-Infer can discover a viable path.

Layer 2 — Constraint modeling and uncertainty mapping. Constraints elicited: cost (you don’t want to pay for cloud services indefinitely); privacy (transcripts contain confidential discussions; can’t go to a third-party service that retains data); platform (you have a personal computer; mention of Mac Studio in your context); time-to-first-result (you want this working soon, not as a six-month project). Uncertainty map: (a) which retrieval method matches your query patterns — keyword search, semantic search, or hybrid? (b) how do you want to query — terminal, web UI, native app? (c) does the Whisper transcription have speaker labels or just text? (d) do you need the answer to point to a timestamp within the meeting or just to the meeting file?

Layer 3 — Gap decomposition. The path between current state and end state has four gaps: (1) ingest the 300 transcripts into a queryable form; (2) support the query method you’ll actually use; (3) return results that point you to the right meeting (and ideally the right moment within it); (4) make the system rerunnable as new transcripts arrive.

Layer 4 — Candidate path generation. Three candidate paths surface:

Path A — Local semantic search via embeddings + vector database. Run a local embedding model (Ollama with a small embedding model, or sentence-transformers) over chunks of each transcript; store embeddings in a local vector database (ChromaDB or LanceDB); build a simple query interface (terminal command or local web UI). Cost: zero (local); privacy: full (nothing leaves your machine); time-to-first-result: 1–2 days. Best for semantic queries (“the discussion about why we changed the pricing model”).

Path B — Local keyword search via grep / ripgrep. Index the transcripts with ripgrep or a small full-text-search tool (mlocate, recoll); query with terminal commands. Cost: zero; privacy: full; time-to-first-result: under one hour. Best for exact-term queries (“when did we mention Project Atlas?”). Worst for semantic queries.

Path C — Hybrid: keyword + semantic. Run both Path A and Path B; query interface returns hybrid results (keyword matches first, then semantic matches). Cost: zero; privacy: full; time-to-first-result: 2–3 days. Best for mixed query patterns.

Layer 5 — Probe design. The dominant uncertainty is your query pattern (semantic vs. exact-term). I’ll design a probe to surface it cheaply: pull 10 historical questions you’d want to ask of the corpus (from memory or from your notes); classify each as semantic, exact-term, or mixed. Cost: 15 minutes. Predicted outcomes: if 8+ are exact-term, Path B is sufficient; if 8+ are semantic, Path A; if mixed, Path C. (I’ll wait for your answer before running Layer 6.)

Layer 6 — Path evaluation and selection (after probe). Suppose the probe returns 6 semantic and 4 exact-term — mixed pattern. Path C (hybrid) is selected. The path is: install Ollama with a small embedding model; chunk each transcript by topic-shift (heuristic: 200-token sliding window with 50-token overlap is a known-good default); generate embeddings; store in ChromaDB; install ripgrep; build a small Python wrapper that runs both queries and merges results.

Layer 7 — Formalization handoff package. The discovered process is ready for PFF formalization if you want to make it a runnable framework you can apply to future transcript folders. The handoff package describes: Input Contract (folder path; query mode); Output Contract (ranked results with file references and timestamps); Layers (transcript chunking; embedding generation; index population; query parsing; hybrid retrieval; result ranking); Verification Criteria (latency under 2 seconds; precision/recall on a small held-out set). If you want to skip formalization and just run the discovered process manually for now, that’s also a valid choice — formalization is premature when the process is being used a few times rather than hundreds.

Verdict. P-Infer discovered a viable path. P-Feasibility on the candidate “transcript-search system live for the 300-transcript corpus” returns Reachable under current constraints. The path can be either run manually (one weekend’s work) or formalized into a framework via PFF (one additional half-day for the formalization).

That is what PIF produces from a defined-endpoints, unknown-path situation. The uncertainty map made the unknowns explicit; the candidate path generation surfaced three options with cost / privacy / time tradeoffs; the probe design produced a cheap experiment to settle the dominant uncertainty; the path evaluation selected the option matching the probe results; the formalization handoff package is ready if and when you want to make this a recurring capability.

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

For P-Infer (most common starting point):

[Paste the framework specification]

Run P-Infer.

Current state: [What exists now.]

Desired end state: [What success looks like in observable, testable terms.]

Constraints (optional): [Hard limits.]

Available resources (optional): [Tools, hardware, APIs you can use.]

The AI runs through Layer 1 (endpoint elicitation) → Layer 2 (uncertainty mapping) → Layer 3 (gap decomposition) → Layer 4 (candidate paths) → Layer 5 (probe design — surfaces the dominant uncertainty for cheap testing) → Layer 6 (path selection after probe results) → Layer 7 (formalization handoff package, if you want to run PFF next).

For P-Feasibility (the lightweight verdict mode):

[Paste the framework specification]

Run P-Feasibility.

Mode: Verify [or Suggest]

Current state: […]

Candidate milestone (Verify mode) OR Resolution Statement (Suggest mode): […]

The AI returns one of four verdicts (Reachable / Reachable with conditions / Not reachable / Cannot assess without exploration) with rationale. P-Feasibility is the cheap version — used by MOM under PEF supervision for the Active/Aspirational milestone split.

The framework is deliberately tool-agnostic. The uncertainty map, the probe design discipline, and the verdict structure are conceptual disciplines that survive the lift to any environment. The discovered process can be run manually or formalized via PFF; both options are valid.

One caution. PIF assumes the endpoints are well-defined enough to verify completion. If the desired end state is vague (“I want this to work better”), PIF cannot run cleanly — the lack of verifiable endpoint is the actual problem, and the right move is to invoke MOM first to produce a Resolution Statement, then return to PIF when the endpoint is concrete.

Other examples

  • P-Debug on a process that fails somewhere unknown. A user’s batch image-resizing pipeline produces correct output for most images but corrupted output for a small subset. P-Debug runs: expected behavior (correct resize for all images); actual behavior (correct for 90%, corrupted for 10%); known: the failure is reproducible on the same input set. The framework’s gap decomposition identifies four candidate failure points (input format detection, color space conversion, resize algorithm, output encoding); the probe design produces four small isolation tests; the user runs the tests; one isolates the failure to color space conversion on PNG images with non-standard color profiles. The corrected path adds a color-profile normalization step before resizing. Demonstrates P-Debug as an explicit isolation discipline against a process whose failure point is not surface-visible.

  • P-Decompose on a complex endpoint. A user wants to “build a personal knowledge management system that integrates with my reading practice.” The endpoint is too large to attack as one transformation. P-Decompose breaks it into solvable subproblems: (a) capture pipeline for highlights and notes from books and articles; (b) atomic-note production from captures; (c) organization scheme for the produced atomics; (d) retrieval interface for finding atomics by topic; (e) connection-surfacing mechanism for noticing patterns across atomics. Dependency ordering: (a) before (b); (b) before (c) and (d); (d) before (e). Each subproblem is small enough to run P-Infer on individually. Demonstrates the decomposition discipline against an endpoint that would otherwise be paralyzing.

  • P-Feasibility verdict cascade. MOM is producing the Active/Aspirational milestone split for a Project Matrix in M-Supervised mode. Five candidate milestones submitted. P-Feasibility runs against each: milestone 1 — Reachable (becomes Active); milestone 2 — Reachable with conditions (Aspirational; conditions captured as Contingency notes); milestone 3 — Reachable (Active); milestone 4 — Not reachable under current constraints (surfaces to user; the user revises the milestone or accepts the constraint change); milestone 5 — Cannot assess without exploration (triggers Terrain Mapping invocation). The Active/Aspirational split lands cleanly; supervision has the substrate it needs to drive iteration. Demonstrates P-Feasibility as the runtime mechanic for MOM’s milestone refinement.

Citations

The Process Inference Framework draws on traditions in problem-solving methodology and systems analysis. The uncertainty-map-first discipline draws on Polya’s How to Solve It (1945) — understanding the problem requires articulating both what is known and what is sought, and explicitly cataloging what is unknown is a step against the failure mode where unknowns surface only at solution-attempt time. The probe design discipline draws on minimum-viable-experiment thinking in scientific methodology and lean-startup practice (Eric Ries) — small cheap experiments designed to surface a specific answer beat larger experiments that test multiple things at once.

The four-verdict P-Feasibility structure (Reachable / Reachable with conditions / Not reachable / Cannot assess) draws on decision-analysis literature where the explicit “I don’t know” verdict (Cannot assess without exploration) is treated as a first-class output rather than a failure of the analysis. The hand-off pattern to TMF when the verdict is Cannot assess is internal to Ora and resolves the chronic problem where feasibility analysis is forced to produce a verdict even when the territory is genuinely unmapped.

The framework is single-author and originated 2026-04-08; the P-Feasibility mode was added when MOM v3.0 needed lightweight feasibility verification for the Active/Aspirational milestone split (2026-05-08). 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