AI agents that make decisions need a framework for evaluating options, selecting actions, and licensing execution. The PV-PP Runtime API, now at version 0.70, provides that framework as a common application interface that separates the decision architecture from the application-specific world it operates in.

What the runtime actually owns

The runtime handles the generic decision machinery. It manages the registry of actions, governance and recovery structures, candidate evaluation through shared projection interfaces, selection through a mechanism called sigma, and execution licensing through epsilon. The runtime evaluates the represented decision state and determines which action is selected, but it does not mutate the actual world. That separation is deliberate.

The host application owns everything else. It provides the authoritative actual state, the application-specific world semantics, external persistence and side effects, world projections supplied through runtime boundaries, and the authoritative Layer-1 state transition. When the runtime selects an action, the host is responsible for executing it and updating the world state.

This boundary matters because it means the runtime can be tested, validated, and reasoned about independently of the application it serves. The decision architecture does not depend on what the world is. It depends only on how the world is represented to it.

What v0.70 provides and what it does not

The frozen interface provides the common decision architecture, registered governance and recovery structures, candidate evaluation and shared projection interfaces, sigma selection and execution licensing, bounded execution through epsilon, and explicit Layer-1 transition with provenance. The regression suite contains 496 tests that pass against the frozen interface.

What it does not provide is equally explicit. The runtime does not claim to offer a universal persistent database or runtime store, an autonomous scheduler, a language model semantic adapter, a learning rule, a memory storage algorithm, an unrestricted graph search mechanism, or a universal arbitration rule for jointly impossible recovery obligations. Those concerns remain host-owned, application-specific, or outside the present runtime interface.

This explicit scope is worth noting because many frameworks try to be everything at once. PV-PP draws a clear line: the runtime solves the decision problem. The host solves the world problem. Each is responsible for its own domain.

The registry and the steady action

Every registry must contain an action whose identifier is exactly steady. This action represents the baseline or no-intervention continuation used by the canonical runtime. Applications may assign application-specific semantics to the action, but the registered ID must remain steady. The requirement ensures that the runtime always has a default action available, even when no other action is selected.

The registry also contains domain registrations, action registrations, and recovery registrations. Domains represent the areas of the world that the runtime can reason about. Actions represent what the agent can do. Recovery structures represent what happens when an action fails or produces unexpected results. The registry is the source of truth for what the runtime knows and what it can do.

How the decision cycle works

The canonical decision cycle takes the current world state, evaluates it against the registered governance structure, identifies candidate actions, projects outcomes through shared projections, selects the best candidate through sigma, licenses execution through epsilon, and produces an action for the host to execute. The host then performs the action, updates the world state, and feeds the new state back into the next decision cycle.

The example application, a minimal battery service, demonstrates the full cycle. It constructs a registry, registers domains and actions, builds the decision graph, projects outcomes, evaluates the cycle, selects an action, licenses execution, and hands the action to the host for Layer-1 transition. The example is intentionally small so that every step is visible.

Why this matters for agent developers

Building a decision-making agent requires solving two problems: deciding what to do and executing the decision. Most frameworks conflate these, which makes testing, validation, and reuse difficult. PV-PP separates them cleanly, which means you can test the decision logic without running the application, validate the governance structure without side effects, and reuse the same runtime across different applications.

The frozen v0.70 interface is a validation point. The regression suite confirms that the decision architecture works correctly across 496 test cases. New integrations should begin with this interface, not older custom PV-PP applications. The interface is stable, documented, and ready for use.

For developers building agents that need structured decision-making with governance, recovery, and execution licensing, the PV-PP Runtime API provides a tested framework with a clear boundary between decision logic and world interaction. The host application remains authoritative. The runtime remains focused. The separation is the architecture.