A runtime API for building applications with the Productive Value–Productive Power (PV-PP) framework.
Current runtime: v0.70
Interface status: Runtime Interface Freeze 1
Documentation status: Public beta developer documentation
PV-PP Runtime v0.70 is the current frozen runtime interface.
Before the interface freeze:
The runtime is therefore being treated as a stable beta interface rather than an architecture under active redesign.
The freeze rule is simple: the runtime should not be changed merely because an alternative design appears cleaner or more convenient. Changes should be considered only when a reproducible application or benchmark failure demonstrates a genuine implementation or architectural defect that cannot reasonably be handled compatibly.
This repository provides the common runtime interface for developers building applications using the PV-PP framework.
The basic integration model is:
The runtime does not take ownership of the application’s world model or silently mutate authoritative application state.
New applications should normally begin with:
PVPPRegistryWorldAdapterPVPPRuntimeThe repository includes a small v0.70-native reference application intended to demonstrate this integration from beginning to end.
Developers should use the current runtime API and reference examples rather than older PV-PP sample programs. Earlier applications were often custom implementations created before the common runtime API existed and are not authoritative descriptions of the frozen interface.
PV-PP Runtime v0.70 requires Python 3.
From the repository root:
python3 -m pip install pytest
python3 -m pytest -q
The frozen v0.70 regression suite should report:
496 passed
The recommended starting example is:
examples/minimal_battery_service/
Run its tests:
python3 -m pytest -q examples/minimal_battery_service/test_minimal_battery_service.py
Expected result:
6 passed
Then run the application:
PYTHONPATH=. python3 examples/minimal_battery_service/minimal_battery_service.py
The example demonstrates a complete v0.70 integration through canonical selection, execution licensing, epsilon, explicit host-owned Layer-1 transition, transition validation, and provenance.
The runtime provides the common PV-PP decision architecture, including the canonical decision pipeline and associated governance, recovery, projection, selection, and execution interfaces.
At a high level, the canonical Layer-2 pipeline includes:
PPP → Φ → H → G → R → graph/seed substrate → Π → Π completeness → Constraints → Domain Framing → Restoration Adequacy → Σ → ε
Shared policy projection Q is used during candidate evaluation.
Developers normally invoke the integrated runtime interfaces rather than manually reproducing this operator sequence.
The host application remains responsible for application-specific semantics, including:
This separation is intentional.
Selection by the runtime does not itself mutate the actual world.
Applications describe stable PV-PP structure through PVPPRegistry.
Depending on the application, registered structure may include:
Runtime v0.70 requires every registry to contain an action whose identifier is exactly:
steady
steady represents the baseline or no-intervention continuation used by
the canonical runtime. Developers may give the action whatever
application-specific semantics are appropriate, but the registered
action ID must be steady.
WorldAdapter is the principal boundary between the generic runtime and
the application’s world semantics.
The adapter supplies information and projections the generic runtime cannot infer itself.
The adapter does not replace the PV-PP decision architecture. Applications should not reproduce Σ selection, Π construction, adequacy evaluation, regime classification, or other runtime-owned decision logic inside the adapter.
Runtime v0.70 also exposes typed service boundaries for capabilities such as:
Applications only need to implement optional services required by their particular integration.
The frozen runtime does not currently provide a universal:
These remain host-owned, application-specific, or outside the present runtime interface.
The first native v0.70 teaching application is intentionally small.
It demonstrates:
The example is designed to teach the common runtime API rather than reproduce an older custom PV-PP application architecture.
The repository contains additional historical example worlds and benchmark support modules because they are dependencies of the frozen v0.70 regression suite.
These files are retained to preserve regression reproducibility. They should not be treated as the recommended architecture for new PV-PP applications. Some originated during runtime development before the present common API was frozen.
For new development, begin with examples/minimal_battery_service/ and
the Volume Six Runtime API Reference.
The developer reference is:
PV-PP Volume Six — Runtime API Reference
Beta Developer Documentation for Runtime v0.70
The runtime implementation itself remains the ultimate authority for callable behavior. Where documentation and runtime behavior differ, v0.70 governs.
Runtime v0.70 is designated Runtime Interface Freeze 1.
Some callable surfaces remain in the package for compatibility with earlier integrations. Their presence does not necessarily make them recommended interfaces for new applications.
New beta applications should use the documented canonical integration path.
Productive Value–Productive Power (PV-PP) is an economic and decision framework centered on Productive Value, Productive Power, represented and perceived productive state, governing domains, recovery structure, and viability-aware action selection.
This repository is specifically concerned with the runtime API. It is not intended to contain the complete theoretical, mathematical, benchmark, or research record of the PV-PP framework.
See the repository license for terms of use.
Lance Amundsen
The PV-PP Runtime API is currently a public beta. If you are experimenting with the runtime and encounter an implementation problem, documentation ambiguity, unexpected behavior, or a potential defect, please get in touch.
Contact: Lance Amundsen — amundsenlance@gmail.com
Bug reports and reproducible examples are particularly useful.