Authorize execution at the physical owner
ALYT is local-first: AI can suggest bounded intent, but ALYT keeps approval, physical authority, execution, and evidence separate. For public apps, you continue to use existing device command, routine, and connector operations. A model response, API key, or parsed ticket does not create household authority. An APPROVED record still carries physicalEffects=0 and executionAuthority=false until ALYT binds that work to the current physical owner at execution time.
What this means for public developers
Section titled “What this means for public developers”This page describes the execution boundary you rely on indirectly when you call normal command and routine operations. The preparation and lease flow behind that boundary is private to approved ALYT runtimes and not public SDK routes. DEV and LIVE credentials cannot call those private interfaces.
For public integrations and apps:
- Use existing authorized device command operations.
- Use existing routine run operations.
- Use existing connector operations.
- Do not treat approval receipts as physical execution grants.
An APPROVED receipt proves consent for the reviewed intent, but it does not by itself authorize a receiver to mutate the home.
Separation of approval and execution
Section titled “Separation of approval and execution”ALYT keeps approval and execution distinct:
- Approval records consent for the reviewed intent.
- Execution is checked again against the current owner, current household authority, and fresh preconditions.
- Readiness checks never choose a replacement executor and never write to a device.
If a saved routine is used, ALYT rechecks the complete installed routine graph, the installed version, and the sole owner before execution. If that routine is no longer eligible for this protected path, it keeps its separate ordinary supported path instead of being silently rerouted.
Existing physical owners
Section titled “Existing physical owners”ALYT uses the existing owner for the target path:
| Path | Physical owner used at execution time |
|---|---|
| Hub-routed device work | The current home hub |
| WiZ | Existing local UDP owner |
| Tuya | Existing local TCP owner |
| Cync | Existing provider relay owner |
| Installed routine execution | The sole installed routine hub owner |
WiZ and Tuya remain local routes at this boundary. Cloud-dependent connectors still require their provider and network; if that cloud path is unavailable, that connector path is unavailable.
Every installed integration has a version, and qualified connector routes use the matching ALYT built-in definition. ALYT does not substitute another owner if the expected one is unavailable. WAN loss never elects a second owner.
Lease and identity rules
Section titled “Lease and identity rules”Execution is bound to immutable identities from the approved work:
- ALYT prepares at most
8effects for one immutable approved manifest. - Leases last at most45seconds.
- Repeated preparation keeps the original identities and original expiry.
- Retry or reconnect does not renew consent.
- Generations are positive decimal strings.
The lease binds the proposal, effect, approval, expiry, authority revision, owner epoch, and the exact normalized light or routine intent. For routines, it also pins installed routine digests.
If the same prepared effect is queued, ALYT atomically binds it to CommandHistory before publication. Hub publication rechecks current authority and the exact body before the command goes out.
Preconditions checked immediately before mutation
Section titled “Preconditions checked immediately before mutation”Before a deferred send, the native receiver rechecks exact physical preconditions against current readings.
Important rules:
- Missing, stale, or changed readings refuse new model-directed work.
- An unrelated partial report does not refresh a stale field.
- Unsupported conditions are refused rather than guessed.
- The recorded observation owner must still match.
- The installed version used for that reading must still match.
Ordinary manual control keeps its existing supported path even when model-directed work is refused.
Cancellation and connectivity
Section titled “Cancellation and connectivity”Cancellation, changed ownership, or withdrawal of the original session or access permanently fence earlier leases. restoring a permission does not restore an old effect.
During a hub link outage, the hub only knows:
- its finite original lease
- the last delivered watermark
That means an undelivered cancellation is not immediate local knowledge. Even so, eligibility still ends within the at most45seconds grant, and restart, clock rollback, expiry, or installed-version change denies old work.
A normal household session rotation to its current successor keeps the session family intact.
No replay on uncertainty
Section titled “No replay on uncertainty”ALYT treats physical sends conservatively:
- Uncertain sends do not authorize another send.
- Missing results are not permission to send again.
- Current domain stop rules still apply.
- A malformed reserved marker never becomes a normal command.
For protected physical execution, work is not replayable. If a send identity is consumed, the next step is reconciliation, not retry.
Evidence and outcomes
Section titled “Evidence and outcomes”Transport and queue facts are not physical proof:
- ALYT cannot unsend a radio or socket frame.
- Transport acknowledgements do not prove physical success.
- Consumed identities do not prove physical success.
Preserve the original command, routine, and evidence identities. Use device readback and capability-specific outcomes for reconciliation.
This is why approval receipts and permits always avoid claiming physical confirmation. A permit authorizes an attempt within the bounded lease; it does not certify that the device changed state.
Operational limits
Section titled “Operational limits”These limits matter if you design around ALYT execution timing:
| Limit | Value |
|---|---|
| Prepared effects per execution | 8 |
| Lease length | 45 seconds maximum |
| Request size | 8 KiB |
| Wire intent size | 4 KiB |
| Active authority operations | 8 |
| Retained actor/session scopes per home | 64 |
| Native receiver authority scopes | 16 |
| Native receiver effect identities | 64 |
| Native live contexts | 8 |
If capacity or persistence is refused, new agent-directed work stops without changing existing manual authority.
Developer guidance
Section titled “Developer guidance”If you build on ALYT APIs:
- Treat approval and execution as separate states.
- Keep commands and routine runs idempotent on your side, but do not assume ALYT may replay physical work.
- Preserve returned command and routine identities for later reconciliation.
- Expect a protected execution path to fail if the current owner, current household authority, installed version, or preconditions changed.
- Do not infer physical success from publication, queue claim, or transport ACK alone.
Household access remains narrower than staff access. If your connector uses public credentials, DEV credentials act only in the developer sandbox, and LIVE credentials operate only for that developer’s own installed connector.