Skip to content

Capability Compiler architecture

Apizr 0.2.0 discovers capabilities in existing Python software, describes what is statically known, and generates interfaces for eligible contracts.

Python repository → Scanner → Capability Catalog → Capability Graph
Scripts / notebooks ──────────────→ Capability IR + static readiness
Catalog + Graph ─────────────────→ Repository Readiness (policy evidence)
Capability IR + static readiness → Interface Contract → REST / MCP
                                                          ↓
                                      direct or governed execution
                                             local-process / OCI

Discover and describe

The scanner inventories Python files under bounded source roots. Capability IR records declarations and typed contracts; the graph adds statically established relationships. Individual inspection also accepts notebooks. No input is imported or executed during these operations.

Assess evidence

Static readiness assesses individual interface contracts. Repository Readiness combines catalog, graph and policy evidence, preserving declaration-level results and unknowns. It does not test runtime availability or grant access. READY never means safe. Imports are not calls, discovery is not trust, and unknown effects remain unknown.

Generate interfaces

REST and MCP consume shared interface semantics. Contracts precede transports. Deterministic artifacts and digests support review and comparison; they are attestable evidence, not signed attestations.

Execute explicitly

A direct server imports and invokes trusted source in its own process. Governed transports opt into an execution policy, separately from readiness policy.

  • Local-process: a fresh process with time, input/output and environment limits. No host filesystem or network isolation.
  • OCI-container: Linux container namespaces and resource controls with a trusted Docker daemon and explicit worker image. Not a VM boundary.
  • Unsupported: absolute subprocess prohibition, arbitrary untrusted-code hosting, automatic trust decisions and an enterprise control plane.

Execution remains experimental: the contracts and refusal paths are tested, but the supplied backends require trusted code and operational prerequisites. See OCI execution and governed OCI transports.

Compatibility and limits

Top-level Python functions are the capability unit. Classes/methods, dynamic binding and effects are not automatically resolved. Repository scanning is Python-only; notebook support belongs to individual inspection/generation. The legacy pipeline is independent and retained for compatibility, including its documented behavior and limitations.

Historical verification measurements live in the engineering archive. They describe their recorded revisions rather than promising current test counts.