Program Operating System

This architecture exists because of one failure mode: the representation of a program can become more operationally real than the work. Reading Baudrillard gave me the original language for that problem. AI makes it more urgent because the representation can now be generated continuously and can begin to act on itself.

A Program Operating System is my working name for an environment that represents, observes, governs, and increasingly executes complex work across people, agents, software, suppliers, and the physical world. Programs already have such an environment; it is scattered across ticket systems, repositories, email, meetings, approval paths, portals, unwritten norms, and people’s heads. The proposal is to make enough of it explicit to inspect and correct without mistaking the model for the program.

The stack

The Commitment Network is what the program fundamentally is: dynamic commitments among actors about what will become true, by when, under what conditions, for whom, with what evidence, and with what uncertainty.

Program Observability is how the system knows what is happening. Evidence supports claims. Reconciliation compares those claims and preserves conflict. Derived state is the output. Provenance, freshness, authority, and uncertainty travel with it.

Program as Code is the implementation philosophy spanning the architecture. It makes requirements, commitments, dependencies, interfaces, decisions, policies, evidence references, authority boundaries, and program state explicit enough to version and inspect.

Program Runtime is where execution occurs. Deterministic systems, agents, accountable humans, and external actors operate against program state and produce new events.

Program Control Plane is how execution is governed. It carries policy, authority, prioritization, escalation, autonomy limits, sequencing, overrides, intervention, and risk acceptance.

The Program Operating System connects the layers, actors, evidence, and feedback loops. It should not erase the boundaries between them. An observability system that quietly makes decisions has smuggled governance into sensing. An agent with permission to edit state has acquired authority, whether or not anyone called it that.

Program Runtime

The Program Runtime is the persistent execution environment. Its core loop is:

Sense → Reconcile → Reason → Decide → Act → Observe

The corresponding state progression is:

Evidence → Claim → State → Policy → Decision → Action → Event

These are separation points, not a claim that programs behave cleanly. A decision should trace to policy and state; state to claims; claims to evidence. An event can become new evidence without silently rewriting the decision that caused it.

3 execution domains

Deterministic systems handle exact rules, arithmetic, freshness checks, gate conditions, policy enforcement, threshold detection, and authorization checks. If the logic must produce the same answer from the same inputs, an agent is probably the wrong tool.

Agentic systems handle semantic interpretation, conflict analysis, dependency discovery, recommendations, synthesis, bounded communication, and bounded actions. They are useful where the inputs are messy and the output can be checked or constrained.

Accountable humans handle authority-bearing decisions, strategic tradeoffs, risk acceptance, major commitments, conflict resolution, overrides, and decisions where the consequence cannot legitimately be delegated.

External actors complicate the split. A supplier may make a binding commitment with no machine interface. A regulator may create a condition through a PDF. A technician may see a defect no telemetry catches. Partial observability is normal.

Program Control Plane

The control-plane metaphor is especially useful for cloud and infrastructure readers.

The execution plane is where the work occurs. Engineers build. Suppliers manufacture. CI runs. Technicians install. Agents take bounded actions. Hardware moves through loading docks regardless of how elegant the model looks.

The Program Control Plane is where the organization evaluates policy, decides when to intervene, manages authority, prioritizes, escalates, and governs autonomy. In this model, the TPM increasingly engineers that organizational control plane: the interfaces, boundaries, escalation paths, and feedback loops through which the program moves.

The analogy has a hard limit. A TPM does not possess centralized control over an organization in the way a network control plane controls a data plane. Teams negotiate. Executives conflict. Suppliers have their own incentives. Authority overlaps and shifts. The control plane can represent and route those realities; it cannot command them into simplicity.

Authority before autonomy

Autonomy should increase in steps, and each step should be earned through evidence.

1. Observe. Read available evidence and preserve uncertainty. No action.
2. Recommend. Propose an interpretation or response with supporting evidence.
3. Prepare. Draft the message, change, decision record, or escalation for review.
4. Execute bounded actions. Act within explicit policy, scope, reversibility, and authority.
5. Closed-loop coordination. Sense the result, adjust within bounds, and escalate when limits are reached.

Bounded actions might include following up on an unanswered request, asking for missing evidence, refreshing a stale commitment, updating derived state, or initiating a predefined escalation path. They should have visible authorization, logs, stop conditions, and an owner for the consequence.

Higher autonomy needs a track record: low unsupported assertion rate, reliable unknown preservation, traceable actions, successful reversals, and evidence that humans notice when the system is wrong. Model capability alone does not confer organizational authority.

Epistemic state is program state

A Program Operating System fails if it turns uncertainty into clean fiction. These states need to be first-class:

• UNKNOWN: the system lacks an answer.
• UNVERIFIED: a claim exists without sufficient supporting evidence.
• CONTRADICTED: credible claims disagree.
• STALE: the supporting evidence has aged beyond its declared usefulness.
• SUPPORTED: current evidence meets the support rule for the claim.
• AUTHORIZED: an accountable authority has formally accepted or changed the state.
• OVERRIDDEN: an authorized actor has replaced the derived or policy-selected result.

They should not collapse into a single confidence score. AUTHORIZED says something about authority, not truth. SUPPORTED says something about evidence, not permission. A stale authorized schedule and a supported prediction that it will slip can coexist.

One supplier date, 4 realities

All 4 can be true at once. Preserving the distinctions is one defense against simulation bias, where the representation becomes more convincing than the reality it claims to describe.

Existing tools are drivers, not the program

Jira, GitHub, Slack, email, supplier portals, lab systems, and ERP systems each expose a fragment of organizational reality. None contains the whole program. Treating the ticket database as the program causes whatever cannot fit in a ticket to disappear.

The operating-system analogy suggests drivers or adapters:

jira_driver
github_driver
email_driver
supplier_portal_driver
lab_driver
erp_driver

Each would expose evidence, permitted actions, timestamps, identities, and limits in a common form. The names are conceptual. I am not implying these adapters currently exist.

This also locates agent harnesses correctly. An agent harness executes an individual agent reliably. A Program Operating System supplies the larger environment in which many harnesses, deterministic systems, humans, and external actors execute against shared program state.

Where the OS analogy helps

Some mappings clarify design questions. Others will break under real organizational behavior. Permissions are the obvious danger: organizational authority is contextual, negotiated, and political. A role-based access model can enforce a tool permission while completely missing who is legitimately able to make the commitment.

Organizations are not computers. Humans are not processes. Politics is not packet loss. Judgment is not an algorithm that has not yet been implemented. The analogy is useful when it exposes missing execution infrastructure and harmful when it encourages reduction.

The Orion test

Orion is the planned first attempt to make this architecture earn its name. The experiment will test whether a structured runtime can outperform unstructured LLM reasoning across a program scenario containing:

• contradictory supplier commitments,
• stale Jira state,
• ambiguous engineering language,
• incomplete dependencies,
• missing evidence,
• schedule pressure,
• and evidence that changes over time.

The evaluation will look at unsupported assertion rate, contradiction detection, unknown preservation, provenance, dependency-model improvement, action quality, temporal reasoning, and traceability.

The comparison matters. A fluent model may produce a plausible plan from the same inputs. The structured runtime has to show that explicit claims, state, policy, and authority improve the answer enough to justify the machinery. If it produces the same errors with more boxes, the architecture has failed an important test.

Orion is planned. It has not been completed, and there are no results to report.

Research posture

The method for this work is build → break → measure → revise → reproduce → publish.

Right now, Commitment Networks are a theory under development. Program Operating System is working terminology for a proposed architecture. Program Observability has small component tests planned and underway, and Orion is still planned. No agent experiment validates the architecture. There are no validated conclusions about the Program Operating System as a whole.

The deeper thesis is that organizational execution can become increasingly engineered without confusing the engineered representation for reality. The last clause is the constraint on all the others.