Bind trusted Reasoning placement and household consent

ALYT separates application hosting, physical execution ownership, state authority, Simone inference, optional frontier inference, and five speech-processing stages. For developers, the key point is that a SELF deployment, a LAN address, or a model claim does not prove where reasoning runs. If ALYT cannot determine placement, the result is UNKNOWN. Ownership of physical state and authority stays with ALYT regardless of inference placement.

Binding trusted reasoning placement

Use the operator-owned PHYSICAL_AI_RUNNER_BINDINGS registry to bind a runner to a tenant or property, a provisioned Device, and the specific interface, model, tokenizer, and binding revisions in use. Each binding also records geography, reviewed origin and addresses, and a private credential environment name.

The registry is constrained: it holds up to 32KiB and 64 entries, and one current enabled binding is required. A caller or model input cannot supply runner URLs, placement, credentials, or native owner identity. That means placement comes only from the reviewed binding record, not from request content.

What a valid binding represents

A binding is the current trusted reference for where a reasoning request may be sent. It does not certify model quality, and it does not turn a transport address into a device identity. Reviewed IPs are transport destinations, not identity assertions.

Before dispatch, resolve the current property and provisioning state and the hub owner from existing database owners. Recheck the binding, credential state, provisioning state, and consent again after output and around validation. If any of those checks fail, stop the request.

Consent for off-property inference

Off-property OPERATOR_HOSTED or EXTERNAL inference requires the current cloudInferenceOptIn, and that consent is separate from application hosting. If consent is withdrawn, the system fails closed. There is no implicit provider fallback.

Off-property transport uses HTTPS. Configured RPC dials the reviewed address while retaining Host and TLS identity, rejects redirects, and bounds request size, reply size, and time. For a developer, the practical rule is that the reviewed destination is fixed by the binding, and the request must stay within those limits.

Cloud-dependent connectors require the provider and network. If that path is unavailable, do not assume the request can complete. Local functions can keep working during a cloud outage, but off-property inference cannot be treated as local.

Shadow property IDs and validation

PHYSICAL_AI_REASONING_SHADOW_PROPERTY_IDS defaults to empty. It marks shadow properties for reasoning-related behavior, but it does not establish model location or quality. The fake adapter is explicitly FAKE and has UNKNOWN inference geography. It is useful for prepared invocation and zero-effect validation, but it establishes no model location claim.

The draft ALYT interface belongs to the platform, and model adapters conform to it without authority to freeze a public v1. Existing chat and voice routing remain independent of this reasoning flow.

Access boundaries

Household permissions are narrower than staff permissions. That matters when a workflow crosses property boundaries or asks for consent-related state. DEV credentials act in the developer sandbox, and LIVE credentials only apply to the developer’s own installed connector.

For this feature, that means you can inspect and test binding behavior in DEV, but you cannot use a broader permission boundary to infer off-property reasoning access. The trusted path still depends on the current binding and current consent.

Developer workflow

1. Read the current binding from PHYSICAL_AI_RUNNER_BINDINGS.
2. Resolve property, provisioning, hub ownership, and consent state from the current records.
3. Confirm whether the intended inference is on-property or off-property.
4. If it is off-property, require cloudInferenceOptIn and use the reviewed HTTPS destination.
5. Recheck binding, credentials, provisioning, and consent before dispatch, after output, and around validation.
6. Stop on withdrawal or any mismatch, with no fallback to another provider.

This workflow preserves placement trust without treating network presence, application hosting, or a model claim as evidence of local execution.