Skip to content

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.

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.

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.

ALYT uses the existing owner for the target path:

PathPhysical owner used at execution time
Hub-routed device workThe current home hub
WiZExisting local UDP owner
TuyaExisting local TCP owner
CyncExisting provider relay owner
Installed routine executionThe 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.

Execution is bound to immutable identities from the approved work:

  • ALYT prepares at most 8 effects 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, 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.

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.

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.

These limits matter if you design around ALYT execution timing:

LimitValue
Prepared effects per execution8
Lease length45 seconds maximum
Request size8 KiB
Wire intent size4 KiB
Active authority operations8
Retained actor/session scopes per home64
Native receiver authority scopes16
Native receiver effect identities64
Native live contexts8

If capacity or persistence is refused, new agent-directed work stops without changing existing manual authority.

If you build on ALYT APIs:

  1. Treat approval and execution as separate states.
  2. Keep commands and routine runs idempotent on your side, but do not assume ALYT may replay physical work.
  3. Preserve returned command and routine identities for later reconciliation.
  4. Expect a protected execution path to fail if the current owner, current household authority, installed version, or preconditions changed.
  5. 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.

Last updated