Manual / Model providers, consumers, and adapters
Architecture

Model providers, consumers, and adapters

Inference, external-consumer integration, and effect adapters are replaceable boundaries. They are not authority sources.

ModelProvider boundary

The rc.12 local model-provider implementation targets pinned FreeToken through an explicit loopback HTTP endpoint. Model requests contain inference data such as messages, sampling controls, tools, and timeout—not principal, approval, lease, dispatcher, effect-adapter, service credential, password, bearer token, or API-key authority fields.

FreeToken-specific failures—unavailable endpoint, malformed responses, unsupported structured-output/seed requests, timeout, or cancellation—fail closed and do not change policy, approvals, leases, effects, or sandbox state.

External consumer model

An external consumer can submit strict typed request material, but goodLAC binds controller-owned principal, agent, application, and skill identity. Consumer-supplied authority, approvals, administrator operations, capability revision, credential references, or lease/executor identifiers are rejected.

Capability declarations are descriptive. Canonical capability registration remains owner/admin-only and grants zero authority. Unregistered capability use fails closed through the pending-permission path.

Effect adapters

Typed effect adapters receive work only after controller evaluation and lease creation. Credential-bearing integrations keep credentials outside the governed model context. The repository includes generic Gmail and Google Calendar adapters, but they are not part of the default four-tool Pi model surface and require separate credentials, configuration, permissions, and integration work.

Important rc.12 limitation

rc.12 does not implement a generic first-connect provider/adapter admission gate. An entirely new provider/adapter identity is not generically held in a controller-owned pending-admission state before it can establish controller-side communication. Do not treat capability registration or effect permission as that stronger admission property.

What rc.12 does enforce is narrower and current: unregistered capabilities fail closed; canonical capability registration is owner/admin-only; registration grants zero authority; and effect permission/approval remains separately required.