What “methodology” means here
Methodology in the Ora context is not a set of opinions about how to think well. It is an operational architecture for executing cognitive work reliably at scale.
The intellectual scaffolding has four layers. Frameworks are the explicit cognitive process specifications that constitute the operational interface between users and capability. Modes are the analytical postures that determine how reasoning runs through any framework. Reliability engineering — the adversarial pipeline, the gear system, the persistent vault — is what converts probabilistic AI outputs into dependable process execution. The harness is the system inside which all of this operates, with the user in the loop directing the system’s cognitive work.
The methodology is general-purpose. It does not solve any single domain’s problems and is not specialized for any particular field. It addresses the underlying cognitive operations that all knowledge work requires — problem definition, process discovery, execution, output formatting, decision-making under uncertainty, dispute resolution among incommensurable values — and provides reliable execution architecture for each.
The result is not a productivity tool. It is a substrate for cognitive work that the user can direct toward whatever the user is working on, with reliability properties that make the substrate trustable at the level of consequential decisions and durability properties that make the substrate compound across years of use.
The framework system
A framework is a structured specification: input format, processing steps, decision points, output format. Frameworks are written in natural language because the source code of cognitive work is the cognitive specification itself, not the code that executes it. Domain expertise is the contribution barrier. A legal aid attorney can contribute a framework for benefits applications because she knows what the form requires; she does not need to write code. This inverts the conventional open-source contribution pattern in a way that opens contribution to populations conventional open source has not reached.
The framework library is a curated collection of these specifications, freely distributed, version-controlled, and open to contribution. The canonical library is hosted at stable URLs on the foundation site; contributors can fork it, modify frameworks, or develop entirely new collections.
The substantive contribution of Ora’s framework library is a small number of integrated frameworks that, taken together, constitute a complete theory of how cognitive work gets specified, executed, and rendered at any scale.
Problem Evolution Framework (PEF) v3.0 — supervises everything. Establishes a locked problem definition that evolves only as new information emerges. Most organizational pain comes from running solvable-problem methods on badly-defined or wicked problems; PEF is the discipline that prevents that failure mode. Mandatory at every project milestone. Only the human user can change the locked problem definition. Matrix-type aware in v3.0: reads the matrix’s project_type and dispatches type-specific drift signals across all four classifications (Project, Operation, Passion, Incubator).
Mission, Objectives, Milestones Clarification (MOM) v3.0 — produces strategic-layer content. Four-way classification dispatch (Project / Operation / Passion / Incubator), with the canonical endpoint-verification methods being the Resolution Statement Objectivity Protocol (Projects, Incubators) and the Service Statement Objectivity Protocol (Operations). Three-outcome branching at the strategic layer — strategic-layer populatable, terrain not yet mapped, classification mismatch — with the No-Punt Protocol for reclassification cases.
Process Inference Framework (PIF) — discovers transformation paths when the process is unknown. Handles the common kind of important work where the user knows what they have and what they want but not how to get from one to the other. PIF infers a viable transformation path, designs probes to validate assumptions, produces a discovered process ready for formalization.
Process Formalization Framework (PFF) v2.0 — formalizes processes that produce information. Generates bespoke process frameworks. The meta-framework that lets the system generate frameworks for new domains as needs arise. PFF is the framework creation framework — the framework whose output is other frameworks. When a user encounters a process that should exist as a framework but does not, PFF formalizes it into a framework that can then be invoked, refined, and contributed back to the library. This is what makes the framework library extensible by users: the user does not have to know how to author a framework from scratch; they invoke PFF, which produces the framework against the library’s specification standard.
Corpus Formalization Framework (CFF) v1.1 — formalizes corpora where information accumulates between processes. Operation-coordination aware: corpora may carry primary-operation markers; consumption-declaration semantics let multiple operations declare consumption rather than ownership; DCA escalation handles contested archival.
Output Formalization Framework (OFF) v1.1 — formalizes outputs that express information. Operation-coordination aware. Generates bespoke output frameworks for the rendering of information into deliverable form.
Decision Clarity Analysis (DCA) — handles wicked problems. When the problem is structurally unsolvable because it involves fundamental conflicts between human values, DCA does not pretend to solve what cannot be solved. It produces a Decision Clarity Document that makes tradeoffs explicit and transparent for whoever holds decision authority. This is the correct and honest endpoint for problems where every intervention is a tradeoff rather than a resolution. Auto-fires from Process Coherence on multi-owner conflict patterns.
Operations Manifest (OM) v1.0 — specifies recurring work. The fourth project_type classification alongside Project / Passion / Incubator. Specifies Service Statement, Cadence and Deliverables (scheduled and event-driven), Coordinated Corpora, Coordinated Outputs, Cycle Close Verification with the four cycle-shape near-miss patterns, Maturity Gate Specification, Devolution Gate (Sunset / Revert to Passion / Recast as Project), Spawned Activity Registry conventions.
Inception and Incubation (IIF) v1.0 — cross-pool idea cultivation. Three modes — Mode 1 generation cadence (plant), Mode 2 review cadence (water + retire), Mode 3 event-driven inspiration response (combine). The value-alignment math (MindSpec values × vault matrices) and the Recognition Lock (recognition cannot be silently substituted by automation) ground the framework in the empirical residue measurement that makes the creativity-as-recognition argument tractable.
Process Coherence (PC) v3.0 — chain-coordination supervision layer. Fires automatically at framework transitions, milestone-completion claims, Operation cycle-close and maturity-gate claims, and workflow events. Matrix-type aware. Loads type-appropriate locked-fields input from the matrix being supervised.
Oversight Configuration (OC) v1.1 — configures Process Coherence per matrix. Matrix-type aware with classification-specific oversight defaults. Operation oversight covers Service Statement, Cadence rule, Excluded Outcomes, and Constraint locks; Passion oversight is light per the Friction Principle.
Knowledge Artifact Coach (KAC) v6.0 — atomic note creation. The thirteen-type relationship taxonomy. Curates the substrate — the vault — that the rest of the system operates on.
MindSpec Interview Framework, MindSpec Library and Instrument — values substrate. Elicits agent / character / self specifications. The values layer that pairs with the vault’s knowledge layer to produce the search-and-filter loop the creativity argument depends on.
Terrain Mapping Framework (TMF) — maps unknown territory. Invoked when the problem is not yet definable; PEF Layer 5 invokes it when MOM Outcome 2 fires. Ensures the methodology has an answer for the case where the problem itself is not yet clear enough for any other framework to operate on.
The frameworks compose. They are not a list of separate tools. They are layers of a single system where each framework calls the others appropriately. PEF supervises everything; MOM produces strategic content; PIF discovers processes; the PFF/CFF/OFF trinity formalizes the information lifecycle; DCA handles wicked problems; OM specifies operations; IIF runs the cross-pool idea cultivation; PC and OC supervise coordination; KAC and MindSpec curate the substrate.
How the frameworks compose into a complete theory
Read together, the frameworks constitute a complete theory of how cognitive work gets specified, executed, and rendered at any scale.
The space of cognitive work has natural boundaries. At one boundary is the case where the problem is defined and the process is known: PFF formalizes the process directly and the work proceeds as scheduled execution. At another boundary is the case where the problem is defined but the process is unknown: PIF discovers a transformation path and hands off to PFF. At a third boundary is the case where the problem itself is not yet defined: PEF iterates the problem definition, invokes Terrain Mapping when the problem is not yet definable, and hands off only when the problem is concrete enough to act on. At a fourth boundary is the case where the problem is wicked: PEF detects this through its four-condition trigger and routes to DCA for Decision Clarity rather than false resolution.
Within each boundary, the supporting frameworks handle the lifecycle. CFF formalizes the corpus the work operates on; OFF formalizes the outputs the work produces; OM specifies the recurring patterns when the work is going-concern operations rather than terminating projects; IIF handles the upstream pool of ideas before they crystallize into specific work; PC and OC supervise coordination across all of this; KAC and MindSpec curate the substrate that everything operates against.
The architecture covers the full space of cognitive work that admits of specification. Within scope: any work that can be reduced to specifiable cognitive operations. Out of scope, by honest acknowledgment: chaos systems (the underlying phenomenon is non-deterministic), truly novel creative breakthroughs (the cognitive operations have not yet been specified), and problems whose unsolvability is a value conflict rather than a missing-information conflict (DCA produces clarity, not resolution).
This complete-theory claim is what distinguishes Ora’s framework system from a collection of useful tools. A collection of useful tools serves the user as the user encounters specific problems. A complete theory of cognitive-work execution serves the user across the full space of cognitive work the user might encounter. The user who internalizes the theory has a map of the territory; the user who has only the tools has a set of capabilities and no map.
The mode system
If frameworks are what the system does, modes are how the system reasons through the frameworks. Roughly twenty specialized modes — Steel Man, Competing Hypotheses, Decision Architecture, Causal Investigation, Stakeholder Analysis, Scenario Construction, Historical Comparison, Adversarial Audit, Devil’s Advocate, and others — ensure that the system applies the right kind of reasoning to each problem type rather than generic reasoning to everything.
Modes are not stylistic preferences. They are different cognitive postures, each appropriate to a different kind of question. A problem that requires holding multiple explanations simultaneously gets Competing Hypotheses. A problem that requires representing the strongest version of an opposing view gets Steel Man. A problem that requires laying out the structure of a decision so its tradeoffs are visible gets Decision Architecture. A problem that requires tracing the structure of a causal claim back to its supporting evidence gets Causal Investigation.
The user is the one who recognizes which posture is needed. The system exposes the choice rather than picking it silently. This is the AHI commitment applied at the methodology layer: the system serves the human’s directing intelligence rather than substituting its own judgment for the human’s.
Mode dispatch in operation
When a user submits a problem, the dispatch is explicit. The router classifies the problem against the territory taxonomy (the next section), suggests the framework and mode that fit, and shows the user the dispatch. The user can accept the suggestion, override it, or request a different combination.
The transparency of the dispatch is itself pedagogical. A user who has seen a hundred dispatches has learned the territory taxonomy by watching it operate. The user knows that questions about contested claims get Argument and Reasoning frameworks running Steel Man or Adversarial Audit modes; the user knows that questions about how things produce other things get Causation frameworks running Causal Investigation or Mechanism Understanding modes; the user knows that decisions get Decision and Future frameworks running Decision Architecture or Scenario Construction modes. The dispatch is teaching the user the structure of cognitive work in the act of using it.
The user can ignore the suggested dispatch. The user might pick a different mode for a problem because the user has noticed something the router cannot — that the problem looks like an Argument and Reasoning question but is actually a Position and Strategy question disguised, or that the problem looks straightforward but requires Steel Manning before Competing Hypotheses can profitably run on it. The system serves the user’s recognition; the suggestion is a starting point, not an authoritative pick.
Reliability engineering
Frameworks and modes are the cognitive content of the system. Reliability engineering is what makes their execution dependable at scale.
The adversarial pipeline. Outputs are challenged rather than accepted. Multiple models with different orientations examine each other’s work. Errors and biases that would survive a single-model pass get caught in cross-examination. This is not a quality-assurance afterthought; it is the structural mechanism that converts probabilistic model outputs into reliable process execution. A single model has no internal verifier checking its output against an external standard. The pipeline supplies the standard, by routing the same work through models with different training distributions and tasking the second pass with finding errors rather than refining output.
The gear system. The right cognitive resource is applied to each task automatically. Simple questions get fast efficient models; complex reasoning gets premium models. Gear 4 — the deep-reasoning gear — is used by most analytical work; lower gears handle high-throughput tasks where speed matters and depth does not. Pricing follows; capability follows; the user does not have to manage the model dispatch directly. The gear system makes the cost-capability tradeoff explicit and recoverable: a query that ran on a cheaper gear and produced unsatisfactory output can be re-run on a deeper gear without restarting the work.
The persistent vault state. Every input, intermediate result, and decision is retained on the user’s local filesystem, not in any model’s bounded context window. The agent does not forget because the system remembers. Long-running processes that exceed any single model’s context window operate against accumulated state that persists across sessions, across model swaps, across years. The vault is the user’s; the schema is open and human-readable; the data is portable.
The mode-and-framework dispatch. A user’s problem enters the system through a router that classifies the problem against the territory taxonomy and dispatches it to the framework that fits, with the modes that fit. The classification is not opaque: the dispatch is shown to the user, the user can override it, and the user learns the territory taxonomy through repeated use.
These four layers are integrated. They are not features added one at a time to a bare model interface. The reliability of all of them — adversarial pipeline, gear system, persistent state, framework-and-mode dispatch — operating together is what produces the order-of-magnitude difference from single-pass model use that makes the system worth running.
The conversation memory architecture
The conversation memory architecture is what gives the system continuity across sessions and across years. It is the operational form of the persistent-vault commitment, viewed from the angle of how conversations specifically get retained, retrieved, and reconnected.
Every conversation produces an artifact: a chat file in the user’s vault, with structured frontmatter (the YAML schema) and the conversation body. The chat file is dual-represented: the file itself is the canonical, human-readable record, and a ChromaDB metadata record (~22 fields after the schema’s recent revisions) is indexed alongside an embedding for retrieval-augmented generation. The two representations are kept in lockstep by the conversation pipeline; any change to the vault file’s chunk content triggers reindexing into ChromaDB with matching metadata.
The retrieval is what makes the memory operational. When the user starts a new conversation, the system retrieves relevant prior chunks against the new conversation’s topic, surfacing the user’s prior thinking on adjacent questions, the user’s prior conclusions on related decisions, the user’s accumulated context that bears on the current work. The retrieval is provenance-weighted: a kept engram (P1, weight 1.0) ranks above a curated resource (P2, 0.8), which ranks above conversation (P3, 0.6) and web content (P4, 0.1). Since schema rev 5.2 a kept engram weighs 1.0 whether the user or the AI first typed it — primacy follows review-status, not authorship — and the AHI commitment is preserved structurally: the user’s kept corpus is never silenced by a transient retrieval.
The retrieval is also tag-filtered. Content tagged archived is excluded from default retrieval (intentionally retired by the user). Content tagged private is excluded when the active conversation is not in private mode (one-way visibility into private content). Content tagged incubating is included with an explicit status flag (mid-curation, not yet vetted). The filtering operates on the user’s curation choices, not on the system’s autonomous judgment.
Cluster-recency decay handles the case where conversation chunks accumulate in clusters around evolving topics. A chat from 2024 about an inactive topic stays at full weight. A chat from yesterday about an actively-evolving topic begins to decay as fresher takes accumulate. Engrams (atomic notes the user has explicitly curated) and resources (curated source documents) do not decay; they retain their full weight regardless of age, because curation is the signal that the content remains current.
The result is a memory architecture that compounds across years without becoming unwieldy. The user’s accumulated work is retrievable, weighted by provenance, filtered by curation, and decayed where decay is appropriate. The user’s first conversation with the system is thin; the user’s thousandth conversation operates against accumulated context that no single conversation could have produced.
The territories taxonomy
Underneath frameworks and modes is a classification of cognitive work itself — twenty-one analytical territories, grouped for orientation into five super-clusters:
- Argument and Reasoning — examining a claim against evidence, building a case, evaluating contesting positions. Territories include Argumentative Artifact Examination, Conceptual Clarification, and Paradigm and Assumption Examination; modes include Steelman Construction and Argument Audit.
- Causation, Hypothesis, and Mechanism — tracing how things produce other things, weighing competing explanations, modeling how a system’s parts produce its behavior. Causal Investigation, Hypothesis Evaluation, Mechanism Understanding, Process and System Analysis.
- Decision, Future, and Risk — choosing among options whose consequences are uncertain, exploring forward, anticipating failure. Decision-Making Under Uncertainty, Future Exploration, Risk and Failure Analysis.
- Position, Stakeholder, and Strategy — locating parties within a contested landscape and reasoning about their interaction. Stakeholder Conflict, Interest and Power Analysis, Negotiation and Conflict Resolution, Strategic Interaction.
- Synthesis, Orientation, Structure, and Generation — producing new understanding from existing knowledge, orienting in unfamiliar terrain, mapping structure. Structural Relationship Mapping, Cross-Domain and Knowledge Synthesis, Orientation in Unfamiliar Territory.
Each mode lives in exactly one home territory; the super-clusters are for orientation, and routing operates per-territory. The taxonomy is generative — territories are added as the system meets problem-shapes the existing set does not cover.
The taxonomy is also pedagogical. A user who has worked across the territories knows that cognitive work falls into a recognizable set of regions, recognizes which territory a new problem belongs to, and applies the appropriate framework and mode without having to be prompted. The taxonomy is a map; using the system is reading the map; reading the map repeatedly is internalizing the structure of cognitive work.
The harness paradigm
Frameworks, modes, reliability layers, and territory dispatch all operate inside a harness — the system that routes queries to appropriate models, manages multi-step pipelines, maintains conversation state, and presents a coherent product identity to the user.
This is the architectural shift the AI industry is undergoing. Where the model used to be the product, the harness is becoming the product. Models become components inside the harness; users pay for the harness, identify with the harness, use the harness as their AI surface. Models inside the harness can be added, swapped, improved, deprecated — invisibly to the user, who sees only that the harness keeps getting better.
Ora’s harness is open. The user owns the harness’s components, the configuration, the data, the conversation history, the frameworks, the model relationships. The harness is forkable; the user can modify it. The harness is local; queries reach a model only when the user explicitly chooses the model relationship. The harness’s source is in the public domain; it cannot be enclosed.
The labs’ harnesses will be closed because their model business depends on it. Closed and open harnesses serve different markets — managed convenience versus sovereign practice — and both are durable. The methodology document does not need to take a position on which is right; the user is the one who chooses.
What the methodology paper does need to say is that the methodology requires the harness paradigm to operate. A methodology built around individual model calls — each call independent, no persistent state, no framework discipline, no mode dispatch — is not the same methodology. The frameworks would not compose because there would be nothing to compose them into. The modes would not be teachable because the dispatch would be invisible. The reliability layers would not exist because there would be no system around the model to host them. The methodology is the harness, in a meaningful sense; the model is the substrate the harness runs cognitive operations against. A different model behind the same harness produces the same methodology with different substrate quality. A different harness behind the same model produces different methodology entirely.
How the system teaches while it works
The methodology is pedagogical at the structural level, not the didactic level. It does not lecture. It encodes good cognitive practice in the frameworks and the modes; repeated use of good cognitive practice builds cognitive capacity in the user.
A user who has worked extensively with the Problem Evolution Framework is a better thinker about problem definition than they were before, independently of whether they are using the framework in the moment. A user who has run hundreds of analyses through Steel Man mode is better at representing opposing views than they were before. A user who has worked across the territories taxonomy understands the structure of cognitive work in a way the user did not understand before.
The training is concrete and observable.
A user who has run Causal Investigation modes dozens of times notices, reading a news story, where the story is asserting a causal claim without tracing the mechanism. The user has internalized the question “what is the mechanism?” — not as a slogan but as a structural pattern that the framework drilled in through repetition. The user is not consciously thinking “I should ask the mechanism question”; the question is part of how the user reads the story.
A user who has run Decision Architecture multiple times finds themselves, in a meeting where a decision is being made, asking the questions the framework would ask: what are the options, what is the optionality structure, what is reversible and what is not, who has authority. The user is not consulting the framework in the meeting; the framework’s structure has become the user’s default cognitive posture for decisions.
A user who has run Steel Man mode on opinion columns over months finds that they cannot read an opinion column the same way again. Where the columnist refuses to represent the strongest version of the position they are dismissing, the user notices. The user’s reading has been trained.
This is the key distinction between Ora and a cognitive prosthetic. A prosthetic substitutes for thinking the user cannot do; a training environment expands the user’s cognitive capacity while also automating the processes the user has mastered. The goal is human capability, not human dependency.
The training is durable. A user who stops using Ora — who returns to commercial AI, or to no AI at all, or to a different stack entirely — does not lose the cognitive disciplines they have built. The frameworks have become habits. The modes have become postures the user can adopt independently. The territories have become a map the user reads other situations against. The substrate of the user’s expanded capacity is the user’s own cognition, not the system’s continued availability.
What the methodology does not do
It does not produce paradigm-shifting creative breakthroughs. The frameworks support, scaffold, analyze, extend, and formalize creative work. They cannot generate the original breakthrough that has not yet been articulated even by the human who will eventually have it.
It does not handle chaos systems. Phenomena that are genuinely non-deterministic at the relevant time scale — weather past two weeks, individual price moves, certain biological systems — resist process automation because the underlying phenomenon is itself irreducible.
It does not bypass wicked problems. When a problem is wicked — when its unsolvability comes from fundamental value conflicts rather than from missing information — the methodology produces clarity about the conflicts rather than a false resolution. DCA is the framework for that case, and it is the honest endpoint.
It does not eliminate the need for domain expertise. The methodology amplifies a competent user’s reach, but the user has to be competent in the domain. Frameworks make domain experts more productive; they do not make non-experts into experts. The system’s pedagogical effect builds cognitive discipline, not domain knowledge.
It does not promise certainty. It promises bounded error rates and visible audit trails. The error rate is lower than single-pass model use by enough margin to make the system worth running; the audit trail is what makes the lower error rate verifiable rather than just claimed.
The summary
Methodology in the Ora context is the operational architecture for executing cognitive work reliably at scale. Frameworks specify what the system does; modes specify how it reasons; reliability engineering converts probabilistic outputs into dependable execution; the harness is the system inside which all of this composes; the territory taxonomy organizes the cognitive work itself; the conversation memory architecture gives the system continuity across sessions and years.
The methodology is general-purpose, public-domain, and pedagogical at the structural level. It is what changes when a thinking machine teaches users to think better while automating their processes. The fragments do not require a unified theory of intelligence to operate; they require a directing intelligence — the user — and an architecture that amplifies what that intelligence can accomplish.