whl-runtime is the proposal pipeline and execution adapter that turns the WHL governance doctrine — propose, evaluate, dispatch, log — into a Python package you install. 147 tests passing. Productizable as the whl-governance-runtime PyPI release. Two-day ship to private PyPI.
WHL Runtime accepts execution proposals from your model, agent, or service layer; runs them through the governance gates defined in the whl-governance SDK; dispatches the surviving proposals through an execution adapter; and emits a receipt for every decision. The doctrine — AI may propose, only the runtime may execute — is enforced at the package boundary.
Accepts ExecutionProposal objects from upstream callers — agents, model serving, cognition layers. Validates the proposal envelope, hashes the evidence bundle, and hands the package into the gate evaluator.
Runs the proposal through the configured gate stack supplied by the whl-governance SDK. Each gate may allow, deny, or escalate. Denials carry the controlling gate name and the structured reason payload.
Dispatches surviving proposals through a customer-supplied adapter — your existing service call, RPC, queue write, or model invocation. The runtime never executes against the world directly; it executes against your adapter.
Every allow, deny, and escalate decision emits a structured receipt — proposal hash, gate trace, adapter outcome, timestamp. Receipts can be persisted into customer-controlled storage or forwarded into the WHL receipt chain.
Unit and integration tests cover the proposal envelope, gate dispatch, adapter contract, receipt emission, and failure-path semantics. The test suite ships with the package and is part of the customer-verifiable surface.
whl-runtime supplies the engine; whl-governance supplies the gates. Customers compose them — picking gates by name, configuring policies, and binding the runtime into their existing Python service surface.
Package is structured for private PyPI distribution. Customer-side install is pip-only — no system services, no compiled extensions required for the core runtime. Onboarding measured in hours, not weeks.
No service rewrite. The runtime sits where you decide — in front of a model call, in front of an agent action, in front of a payment dispatch. Your existing code remains the executor of record; the runtime is the gate in front of it.
The propose-vs-execute split is not a convention — it is enforced by the package surface. Cognition code holds ExecutionProposal objects. Only the runtime holds the path to the ExecutionAdapter. This is what AI governance looks like in code.
whl-governance is the SDK — ProposalGate, gate library, policy primitives. whl-runtime is the engine that runs them. Customers install both; agent and model code only sees the SDK contract; the runtime carries the dispatch and the receipt chain.
ProposalGate evaluator, gate library, 90 tests. The contract your model and agent code is written against. Authoring custom gates is a documented extension point.
ProposalListener, gate dispatch, ExecutionAdapter, receipt emission, 147 tests. The runtime that turns evaluated proposals into governed dispatches with a forensic record.
SDK + Runtime + your ExecutionAdapter implementation. Three lines of wiring at the seam. The doctrine — propose, evaluate, dispatch, log — is now a feature of your service, not a roadmap item.
WHL Runtime is built for engineering teams shipping AI systems where the audit and the override path are first-class product requirements.
Runtime package test suite — proposal-listener, execution-adapter, receipt-ingestor, episodic-memory.
$ pytest -v
collected 147 items
tests/test_proposal_listener.py 22 passed
tests/test_execution_adapter.py 35 passed
tests/test_engine.py 41 passed
tests/test_receipt_ingestor.py 28 passed
tests/test_episodic_memory.py 21 passed
============================ 147 passed in 2.44s ============================Verified live: 147 pass in under 3 seconds. Ready for private-PyPI publish under whl-governance-runtime.
Approved customers receive private PyPI access, the paired whl-governance SDK, the 147-test suite, and engineer support through pilot integration. No service rewrite required.