Integrations and Extensibility Overview

APF separates stable integration contracts from the individual implementations that use them. A contract is a wire format, a schema, or a Rust trait that APF commits to. An implementation, such as the OpenShell adapters, plugs into a contract. This page lists both and the rules that keep them compatible.

Integration Contracts

Refer to Service APIs and Audit Event Schema.

Extension Points

Refer to Adapter Contracts for each interface.

Available Integrations

Compatibility Rules

The repository follows these conventions. Some are enforced in CI, and the exceptions that exist today are listed.

• Wire contracts evolve compatibly. A breaking change to a protobuf contract needs a new package, and a breaking change to a JSON Schema needs a new $id. CI runs buf breaking against the default branch. The JSON Schema rule has no automated check.
• Dependencies flow one way. Library crates do not depend on service or adapter crates, services do not depend on each other, and an adapter may depend only on a leaf adapter that has no adapter dependencies of its own. Services link the adapters they host. cargo xtask dag-guard checks these rules.
• Runtime types stay at the edges. OpenShell-specific logic lives in the apf-openshell-* adapter crates. The exceptions are apf-proto, which generates the OpenShell protobuf types, and the two service binaries, which wire in the OpenShell adapters.
• Signing stays behind one seam. Bundle verification goes through BundleVerifier, and only apf-bundle’s signing backend and the apf-compile tool import the yaml-sigil crates. apf-compile genfixture signs with yaml-sigil directly.
• Public binaries stay public. The service binaries compile without private organization dependencies. Organization-specific behavior belongs in a separate composition binary built on APF’s traits.
• Licenses are checked. New dependencies must pass the cargo-deny license allowlist, which admits MIT and Apache-2.0 and per-crate exceptions only.

Validating an Integration

For an integration in the repository, run the repository checks:

cargo build
cargo nextest run
cargo xtask dag-guard
cargo fmt --check
cargo clippy -- -D warnings
cargo deny check
buf lint contracts/

For a runtime integration, also run the runtime’s own extension protocol negotiation against the adapter. For OpenShell, a gateway that cannot negotiate the extension protocol refuses to start. Refer to Support and Compatibility.

A conformance suite for third-party runtimes and signing authorities is not yet in the repository.

Next Steps

• To integrate with OpenShell, refer to OpenShell.
• To connect another enforcement point, refer to APF Adapter.