Host-owned mapping from manifest provider names to trusted builders.

A manifest can select a bounded provider name and JSON configuration; it cannot register a module, function, callback, command, or code URL. Builders receive a path-free application identity, requested workflow or mission destination, building owner, and installed limits. Acquisition returns a normalized provider build with one or more capabilities, an optional safe snapshot, and an optional idempotent close function. A close function must return exactly :ok; any other return, exception, or exit is a provider-cleanup failure. The Kernel still attempts every registered close function and may replace the run outcome with :provider_cleanup_error.

Trusted staged builders enforce a global preparation barrier. Every selected provider first performs pure selection checks, then every provider completes non-secret local preflight, and no provider is acquired before the union of declared credentials has been resolved exactly once.

When that resolution happens differs by caller, and the difference is the authority each one has. An active command resolves at phase-8 step 5 from its sealed declarations, before any provider callback runs, and supplies the map; resolve_credentials/2 is not called again below that point. Direct embedding has no sealed declarations to derive a union from before preparation, so it keeps resolving here, from what preparation reported, with the synchronous semantics its caller selected. Active command assembly bounds preparation, preflight, and acquisition by its shared run deadline; preflight releases share the provider-cleanup budget. Preparation also freezes the provider's data_class and accepts_data policy so run assembly can reject an incompatible information flow before preflight or credentials. A builder bound to the data policy declared by its sealed PtcRunner.Kernel.ProviderDescriptor cannot contradict it: preparation returning a different data_class or set of accepted classes than phase 5 admitted, and than sink authorization used, fails with :provider_declaration_mismatch before preflight, credentials, or acquisition. Explicit embedding builders registered without a declared policy have no such declaration, so their preparation remains authoritative for them. A staged provider may additionally require or provide a bounded, code-owned acquisition service. Services pass opaque values only between selected trusted providers after the barrier; they never enter Lisp environments, connector snapshots, traces, or result artifacts. There are no implicit built-ins. CLI applications receive exactly the aliases in their host installation, while trusted Elixir embedding can pass any explicit builder map. The registry also freezes the installed limit ceilings used when manifests are loaded, so every frontend applies the same host authority rather than reconstructing it in CLI-specific options. Builder exceptions are contained at their current lifecycle phase.

A staged acquisition context's owner is the private signal owner for that provider's resource scope. Any process or port root started by an acquisition must monitor that owner and synchronously call PtcRunner.Kernel.ResourceRegistrar.register_root/1 from the root's init callback before its start operation returns. The registrar's private controller forwards registration into the scope's authoritative cleanup owner. Ports must be owned by a registered process. Registration after start returns is unsupported. A root retaining an unsettled OAuth release or persistence fence may call PtcRunner.Kernel.ResourceRegistrar.handoff_root/2 only after it has stopped accepting work and the terminal operation has a bounded self-owner or adopter.

provides is not a general marker. It names an acquisition service, and normalize_build/2 requires the acquired build to export exactly the services declared here, so a provider that declares one without exporting it fails with :invalid_provider_build. Use a dedicated field for provider-kind facts, as workflow_llm? does.