Skip to content

0.3.0

Published 22 September 2026. Latest stable: 0.3.0.

Apizr is an open-source capability compiler for Python codebases. This release completes the repository workflow: discover, understand, assess, explicitly select, expose through REST/MCP, then execute directly or in fresh governed workers.

New since 0.2.1

  • Exposure Plans: explicit capability publication decisions bound to Catalog, Graph, Repository Readiness and Exposure Policy. READY does not mean exposed.
  • Repository bundles: one REST or MCP server for multiple selected capabilities across modules. Qualified names distinguish identical bare function names.
  • Verified imports: exact Python source bytes, package initializers, relative imports and namespace parents. Dependencies/helpers are support, not automatically public. Python source packaging is not proof of complete dependency closure.
  • Governed repository execution: a fresh local process or OCI container per call, with integrity revalidation before invocation and sanitized failures. The transport never imports project modules. Direct state persists; governed state resets.
  • Deterministic evidence: digest-bound contracts and reproducible artifacts from discovery through execution planning, independent of repository location.
  • Minimal installation: static workflows require only Pydantic; notebook, HTTP, MCP and historical pipeline dependencies are explicit extras (#63).
  • Configured notebooks: code-cell tags, explicit dependencies and bundled data, with a relocated multi-cell example (#16).
  • Legacy delivery: resource packaging and explicit Docker image builds (#1), separately installed plugins/options (#15), class/method lexical inventory (#5) and early ambiguity/duplicate-route refusal (#28).
  • Strict OCI profile: kernel-enforced process/thread prohibition, selected only by a deny execution policy and an image with the new worker protocol (#49).

Start with a small repository, then see policy composition and examples.

Execution boundaries

Local workers provide wall timeout, input/output bounds, environment control, a fresh working directory and process-group cleanup. They do not isolate host filesystem or network access. OCI uses reviewed Linux container isolation and resource controls, not a VM or an arbitrary untrusted-code guarantee. The opt-in strict OCI profile installs a seccomp filter before project imports and prohibits both process and thread creation. Local mode continues to refuse deny; PID limits alone do not provide this restriction.

Repository OCI requires an immutable sha256:<64hex> image ID, explicit platform and org.apizr.repository.worker.protocol=apizr.repository-runtime/v1, in addition to the existing worker compatibility label. Old single-source-only images are insufficient. Generation never probes/pulls the image; startup/invocation validate availability. Application dependencies must exist in the execution environment/image. Apizr does not install/infer them or silently package non-Python resources.

Migrating from 0.2.1

Most compiler workflows are additive. Two compatibility changes need attention:

  1. Base installation is now minimal. Install outerspace-apizr[legacy]==0.3.0 to retain the full 0.2.1 dependency stack. Choose [notebook], [http] or [mcp] for narrower needs.

  2. The legacy pipeline now refuses selected duplicate definitions/overloads and duplicate routes before generation. Provide a single unambiguous wrapper or exclude the conflicting definitions. Modern refusal contracts are unchanged.

  3. Existing inspect, single-source generate rest/mcp, execute and governed single-source workflows remain supported with unchanged contracts/goldens.

  4. The historical --script / --notebook pipeline remains supported. Existing projects do not automatically migrate to repository exposure.
  5. Repository exposure is opt-in: create readiness/exposure policies and select exact capability IDs. Building a bundle does not publish a service or deploy anything.
  6. Readiness contracts remain unchanged, including conservative import eligibility and unknown effects. Exposure does not broaden eligibility.
  7. Execution remains trusted-code oriented. Direct/local/OCI policy contracts have separate responsibilities; there is no implicit fallback between modes.

See compatibility notes for historical 0.2 changes, which are not new migration requirements for 0.3.

Backlog completion and remaining limits

The 0.3 cycles implement #1, #5, #15, #16, #28, #49 and #63. Final candidate verification was completed in #93.

Class/method inventory does not expose methods as capabilities. Notebook conversion never executes cells or reconstructs hidden interactive state. Plugins and generated servers execute explicitly trusted code. Strict OCI requires its current worker image, forbids threads, and does not change the conservative v1 static readiness control vocabulary. Repository non-Python data/dependencies remain explicit deployment concerns. No general untrusted-code hosting or enterprise control plane is supplied.

Verified delivery

  • Source/tag: v0.3.0, commit 43f5626fe9e26b018aa323abd83b9611f7b2aba9.
  • Exact distributions: master CI 35735875051, reused without rebuilding. All required jobs, Security, Documentation and CodeQL passed.
  • Publication 35748077135: verify, managed receipt, Trusted Publishing and evidence archive all passed.
  • Receipt: expected Apizr identity, signature, RFC 3161 timestamp, schema, consistency and artifact recomputation passed with no warnings. Timestamp: 2026-09-22 15:33:56 UTC.
  • PyPI 0.3.0 files downloaded after publication match the CI distributions byte-for-byte; public Trusted Publishing attestations are available for both files.
File SHA-256
outerspace_apizr-0.3.0-py3-none-any.whl b806a406e0fb886a39cd900c4116f13ed836af9a38fd3a3baf45b941c5f1b187
outerspace_apizr-0.3.0.tar.gz 83e21ecbe1eed3d30f7b8315b3b331afe00bd4e98ca6a836b28bb4f11c45d9d5

Public installation checks used fresh environments outside the checkout: minimal base and each of the four extras on Python 3.11 and 3.14; scan, graph, readiness and exposure; real multi-module REST, MCP stdio and Streamable HTTP; private helper exclusion; fresh local worker PIDs/state, bounded timeout, sanitized errors and no project import in the transport. OCI generation and invocation used the explicit immutable worker image built from the exact CI wheel. The release assets retain provenance, SBOM, validation evidence and the signed delivery receipt.

These are checks of this delivery, not a general untrusted-code sandbox guarantee. The website follows master; later documentation updates do not replace the release files.