Natural Language Programming

How Ora turns natural-language intent into governed work through managed delegation, bounded judgment, explicit authority, durable process state, and verified completion.

Historical architecture (superseded 2026-08-05). This paper preserves the former Process Definition, Process Run, Artifact/event, lifecycle, trigger, and seven-directive model for provenance. It is not current Ora runtime or Programming guidance; current repository work follows Programming and Ora Technical Documentation.

Ora: Natural-Language Programming Through Managed Delegation

Ora lets people manage AI the way they manage capable professionals: define the result, clarify the important choices, approve the plan, delegate the work, and return for decisions or verified completion.

A model contributes bounded judgment. Ora supplies the durable process that establishes state, limits authority, verifies decisions, corrects errors, and preserves accountability.

Natural-language programming is often described as writing ordinary software by describing it to a model. That is one useful case, but it is too narrow. The larger change is that a person can describe what should happen, what must remain true, what evidence would count, and which decisions must return to them. A governed system can turn that description into durable work.

The programming language is not merely the sentence that asks for a result. It is the complete management contract around the result: purpose, scope, authority, artifacts, evidence, correction, stopping, and return. The model can help infer or formalize that contract, but the model does not own it. Ora does.

That distinction turns a prompt into something closer to delegation.

The missing layer between request and result

A chat request is transient. The model receives text, generates a response, and ends its call. Even an excellent response does not by itself establish a durable objective, preserve an approved plan, constrain later actions, remember which artifact was reviewed, or prove that an external effect occurred as claimed.

Delegated work needs those things. If a person asks a capable professional to build a financial review, change a repository, or create a recurring reporting process, the work is not governed by the opening sentence alone. The professional clarifies what result is intended, identifies the people and artifacts affected, proposes a plan, receives authority, does the work, checks it, corrects defects, and returns when a decision or acceptance is required.

Ora makes that management structure explicit. Natural language remains the interface, but durable process state sits behind it. The user manages the outcome, consequential choices, permission, and evidence. Models perform particular reasoning tasks inside that structure.

This is managed delegation: the user does not supervise every token or pretend that the system is a person. The user establishes the result and the boundaries, delegates work inside them, and remains the source of reserved authority.

Natural language is the management surface

Natural-language programming begins with a simple question: What should happen?

The answer does not need to name an implementation. A user can say, “Set up a repeatable monthly cash-flow review,” “Have Programming verify this repository,” or “Build a reusable process for checking applications.” Ora determines whether the request is ordinary generation, invocation of an existing capability, construction or modification of a capability, or a request to make a capability available.

When construction is required, Ora asks only about unresolved management dimensions: the intended result, affected parties, inputs and outputs, expected reuse, initiation, authority, exceptions, permissions, evidence, and stopping conditions. Vague statements remain unresolved. A nonanswer is not silently converted into consent. The result is one canonical plan with two projections:

The Principal view explains the outcome, scope, authority, risks, exceptions, proof, and activation decision.
The Technical view exposes artifacts, architecture, dependencies, implementation order, tests, identities, and recovery.

They are not competing plans. They are two views of the same approved object. A nontechnical user can approve the Principal view without reading code. A technical user can inspect the detailed view without forcing that interface on everyone.

Natural language therefore replaces neither precision nor conventional code. It moves the contribution and control surface closer to the people who understand the domain. The system can still create Python, spreadsheets, documents, or other artifacts where those are the right implementation. What changes is who can specify and govern the work.

A model is a bounded-judgment component

The AI industry often uses Agent to combine several different ideas: a model, a persona, a goal, memory, authority, tools, and an execution loop. That label makes the system sound more self-contained than it is. It also obscures where power and accountability actually live.

Ora does not use Agent as a canonical runtime object, authority source, lifecycle, or user-interface category. Planner, executor, judge, and overseer are names for functions at particular steps, not durable digital workers with general discretion.

Instead, a model contributes bounded judgment. A material judgment step declares:

the verified circumstances presented to the model;
the exact question it may answer;
the conclusions, routes, or actions it may propose;
the artifacts and authority available to it;
the evidence and evaluator required;
the conditions that stop or return the work; and
the record binding the judgment to the current process and artifact identity.

This is a more accurate description of what a model does well. A model can interpret circumstances, compare alternatives, draft a plan, diagnose a defect, or judge whether evidence supports a declared route. It cannot make an undeclared action legitimate merely by recommending it. It cannot turn missing evidence into proof. It cannot acquire reserved human authority through persistence or confidence.

The model supplies judgment. The surrounding process supplies state, limits, verification, correction, and accountability.

The four durable things

Ora builds governed work from four primary object families.

Object	What it means
Process Definition	A versioned description of how a kind of work proceeds: inputs, graph, decisions, authority, evidence, correction, continuation, and stopping.
Process Run	One governed execution of an exact definition for an exact objective, project, scope, and current state.
Artifact	An identity-bound object involved in the work: a plan, file, repository state, workbook, result, definition, evidence item, checkpoint, or receipt.
Event or transition record	The append-only history of what happened, why the state changed, which identity was involved, and what may happen next.

Other concepts attach as contracts. An approved plan, action grant, artifact selector, judgment boundary, evidence requirement, correction ceiling, recovery rule, or escalation condition matters because it is bound to one of these durable objects.

This separation is load-bearing. The Process Definition says what kind of work is authorized in principle. The Process Run says what is happening now. Artifacts say exactly what was acted on or produced. Records preserve the accountable sequence. A confident paragraph from a model cannot substitute for any of them.

Capabilities can create capabilities

Natural-language programming becomes more than task execution when a governed process can produce another reusable process.

Suppose a finance specialist describes a monthly cash-flow review. Ora may infer the procedure, test uncertain parts under controlled conditions, formalize the stable procedure as a versioned Process Definition, register the exact definition, and later invoke that definition to produce a workbook. The first governed process creates a capability artifact. A later governed process uses it to create a result artifact.

Ora does not need a separate “construction engine” to make this possible. Construction and operation are relationships inside the same generic runtime. One Run may invoke a capability, produce a result, create or modify another capability, test it, register it, or request authority to activate it. Each relationship is recorded explicitly.

This capability-producing-capability is the practical center of Natural Language Programming. A domain expert does not merely ask for an answer. The expert can help define a reusable way of producing future answers, with the same care they would use to train a competent colleague.

The least elaborate sufficient route

Not every request needs the same amount of machinery. Ora uses three related frameworks conditionally rather than forcing every problem through one ceremonial stack.

Circumstance	Route
An approved Process Definition already fits	Invoke that exact definition and version.
The procedure is known but not yet formalized	Use the Process Formalization Framework, or PFF, to create a durable definition.
A complete procedure can be responsibly inferred now	Use the Process Inference Framework, or PIF. It may operate directly inside the same governed Run when the Run already has sufficient plan, authority, evidence, correction, and stop contracts. Use PFF when durable reuse is required.
The next responsible direction depends on evidence that only interim progress can produce	Use the Problem Evolution Framework, or PEF, to preserve the evolving problem state and issue one bounded interim-goal contract at a time.

PEF is not universal supervision. A known procedure does not need to pretend it is an evolving problem. An inferable solution does not need an extra wrapper. Conversely, a genuinely contingent problem should not be forced into a plan whose later steps depend on evidence that does not exist yet.

The routing rule is simple: use the least elaborate path that can responsibly preserve intent, authority, and evidence.

Results, capabilities, evidence, and effects are different

“The AI made something” hides several important distinctions.

A result artifact is the thing the user wanted from this Run: a reviewed repository, a workbook, a report, a decision record, or another completed output.

A capability artifact is a reusable Process Definition or package that can produce results in later Runs.

An evidence artifact proves a claim about another artifact: a passing review bound to an exact digest, a test result bound to a repository state, or an inspection result produced through a controlled read-only boundary.

An external effect changes state beyond the Run’s internal records. Editing a repository, sending a message, publishing content, changing a remote system, or activating a standing capability are effects, not merely prose outputs. They require exact authority, a pre-action checkpoint where applicable, a valid receipt, and a post-action identity.

These categories prevent a common failure: accepting a description of work as proof that the work occurred. A test claim detached from the repository it tested cannot authorize repository completion. A review of one workbook cannot accept a later modified workbook. An inline string that says a mutation happened cannot replace an authenticated before-and-after identity and receipt.

Construction, registration, invocation, activation, and effect

Natural-language systems often collapse a chain of distinct decisions into “build and run it.” Ora keeps them separate.

Construction creates or changes a candidate capability.
Verification tests that candidate against its declared contract.
Registration records an exact version and content identity in the Process Library.
Invocation starts a governed Run using that exact registered identity.
Activation makes the capability available within a declared scope and authority boundary.
External effect changes something outside the Run and requires its own authorization and evidence.

Authority for one step does not imply authority for the next. Permission to construct a process does not permit registering it. Registration does not make it active. Activation does not invent a trigger. Invocation does not authorize every effect the definition could theoretically describe.

This is why capabilities can be safely inspected, tested, preserved, or promoted without quietly becoming autonomous services.

The Process Library and standing automation

The Process Library is the exact, registry-backed home for reusable Process Definitions. It exposes identity, version, digest, package membership, scope, and lifecycle status. Later invocation resolves the exact definition rather than searching for something with a similar name.

The interface distinguishes several kinds of process state:

Pending shows live Process Runs.
Unread shows returned results and decisions.
Automated Processes shows activated standing definitions and their declared trigger and authority bindings.
The Process Library shows what is available for exact discovery, inspection, invocation, promotion, preservation, archival, or discard.

Standing automation does not mean that a model has become an independent actor. It means a versioned definition has an explicit activation state, trigger contract, scope, and authority. The trigger begins a governed Run; it does not grant new power. The Run still applies the same artifact, evidence, correction, escalation, and effect rules.

Ora’s first governed-process release establishes the library, lifecycle, exact invocation, and Automated Processes projection. It does not claim a general trigger-management product or permission for arbitrary external-effect entry points. Broad activation and trigger management remain separate work. This distinction matters: durable process infrastructure exists, but “standing automation” must not be used as a euphemism for undeclared background autonomy.

Human authority stays explicit

The user does not need to approve every internal step. That would reduce delegation to remote micromanagement. The user does need to retain decisions the process cannot legitimately own.

Ora expresses progress through seven directives:

PROCEED accepts an intermediate boundary inside the existing definition, plan, and authority.
ACCEPT completes the final governed result.
REVISE corrects defective execution or artifacts while the plan remains sound.
REPLAN returns when evidence invalidates the plan.
REDEFINE returns when the reusable Process Definition itself is defective.
ESCALATE requests reserved human authority, permission, a lock change, or an exception.
BLOCKED records that no authorized, evidence-supported continuation currently exists.

These distinctions prevent a fixed retry loop from diagnosing every problem as “try again.” More attempts may be allowed when progress is real. Repeated defects or no progress can force a different route. A definition problem cannot be repaired by silently changing the approved plan; a missing permission cannot be repaired by model persistence.

When the process needs the user, it returns a focused decision: the requested authority, the evidence, the available options, and the route each choice permits. Healthy work remains quiet. Authority requests become conspicuous. Completion returns with evidence.

Leaving is not the same as granting autonomy

Managed delegation should let a user leave the interface and return later. Ora therefore persists the Dialogue binding, plan identity, Run state, artifacts, decisions, checkpoints, attempts, evidence, and receipts. Restart reconstructs the state from authoritative records. It does not invent missing lifecycle facts or replay an external effect that already occurred.

This durability is sometimes described loosely as background execution. The phrase can mislead. Ora does not introduce a cognition-bearing daemon that continues inventing work because the user closed the window. Leaving means the state survives absence, healthy work does not demand attention, and supported runtime events or later requests can resume the exact Run. It does not mean a model acquires an open-ended mission.

Triggers, where separately authorized, can begin a new governed Run. They do not turn a model into an Agent and do not bypass the definition’s authority.

A concrete example

Imagine a small organization asking: “Set up a repeatable monthly cash-flow review.”

Ora recognizes that the request establishes recurring work rather than merely asking what a cash-flow review is. Construction begins with project confirmation. The management interview clarifies which accounts feed the review, who receives the result, what counts as an exception, whether the process may edit a workbook, what evidence proves the totals, and when the work must stop and ask.

Ora produces one plan. The Principal view says what the review will deliver, who it affects, which actions are permitted, and which exceptions return to the user. The Technical view describes the workbook identity, formula checks, inputs, test evidence, and recovery path. The user approves the exact plan.

The governed Run may infer the transformation, formalize a reusable cash-flow Process Definition, create and test the workbook behavior, and register the exact capability. Registration alone does not activate it. If the user authorizes later invocation, a new Run resolves that exact definition and produces the monthly result.

Suppose the review discovers a tax settlement requiring a payment outside the granted authority. The process does not improvise. It returns an ESCALATE request with the evidence and the exact decision required. The user may approve, deny, or choose an alternative. The resulting path is recorded.

After completion, the user chooses what happens to the artifacts and capability: promote, preserve, archive, or discard. If standing activation and a monthly trigger are separately available and approved, future months begin new governed Runs under the same declared constraints. If they are not, the exact capability remains available for deliberate later invocation.

This is Natural Language Programming as managed delegation: ordinary language at the surface, precise authority and identity underneath.

What changes for domain experts

Historically, a person who knew what software should do usually had to translate that knowledge through a programmer. The legal-aid attorney, clinician, teacher, accountant, or operations specialist supplied domain knowledge; someone else converted it into executable notation. Important judgment often disappeared in the translation.

When a governed system can infer and formalize a careful natural-language procedure, the domain expert moves closer to the contribution surface. The expert can state what result matters, which distinctions are load-bearing, which evidence counts, which actions are forbidden, and where human authority must return. Those are the details that make a process competent.

This does not make every description executable. Ambiguous objectives remain ambiguous. Unsafe permissions remain unsafe. A procedure outside current model or tool capability remains unavailable. Durable reuse still requires exact formalization, verification, registration, and version binding. Conventional programming remains necessary wherever the implementation requires it.

The change is nevertheless substantial: technical syntax is no longer the only doorway into process construction. Domain expertise can become executable infrastructure without pretending that prose alone is proof.

Honest limits

Managed delegation reduces unbounded discretion; it does not eliminate model error. Evidence can still be incomplete. A definition can still encode a bad procedure. Human reviewers can still accept weak proof. External systems can fail after an effect begins. The architecture makes these failures visible and governable; it does not make them impossible.

The current system also has deliberate product limits:

Public Process Library invocation supports a bounded non-external action entry followed by verification; more complex effectful entry shapes use dedicated governed paths.
A produced result may still require independent final acceptance before the Run is complete.
Broad trigger management and general standing-automation controls are not part of the first release.
Natural-language entry classification uses deterministic boundaries and can ask or stop on ambiguity.
Governed effect paths have been validated on macOS; wider platform proof remains outstanding.
Leaving preserves and resumes state but does not create unscheduled autonomous cognition.

These limits are not footnotes to the idea. They demonstrate it. Natural Language Programming is credible only when the system states what it cannot currently authorize or prove.

The contribution

The central contribution is not an AI programmer and not a digital employee. It is a durable management architecture for cognitive work.

Natural language supplies intent and domain judgment. Process Definitions make reusable procedure explicit. Process Runs preserve current state. Artifacts bind work to exact identities. Evidence supports declared transitions. Correction distinguishes execution, plan, and definition defects. Escalation returns reserved authority to the human. The Process Library makes successful procedures available without detaching them from version, scope, or provenance.

The model remains powerful and replaceable. The accountable process survives model calls, restarts, corrections, and later reuse.

That is what Ora means by Natural Language Programming: people describe and govern what should happen; models contribute bounded judgment; the system turns the relationship into managed delegation.

Programming — the first rigorous specialization over the generic governed-process kernel.
Process Inference, Process Formalization, and Problem Evolution — the conditional discovery, formalization, and contingent-evolution routes.
Meta-Layer Architecture — the canonical architecture and source/runtime topology.
Ora Technical Documentation — the as-built implementation reference.
Guide — Using Ora — the Phase 3.3 procedural companion for starting, approving, supervising, inspecting, recovering, reusing, and closing governed work.

Changelog

2026-07-19 — Rewritten as the G1.1 Phase 3.2 conceptual/public guide, preserving the original domain-expert contribution thesis while grounding it in managed delegation, bounded judgment, Process Definitions and Runs, capability construction, exact artifacts, authority, evidence, correction, Process Library lifecycle, standing-automation boundaries, and the accepted as-built limitations.
2026-05-09 — Initial public-paper draft on natural language as the contribution surface.