Reconcile physical results and recover without replay

ALYT records execution separately from approval so you can tell whether a request was prepared, sent, observed, confirmed, or left unresolved without replaying uncertain work. The workflow keeps the original proposal identity, request identity, and approved effect digest, then reconciles physical evidence from the actual owner or a correlated adapter readback. It does not turn ledger approval into physical confirmation, and it does not replace newer operator work with stale results.

Preserve the original action identity

An execution request carries the original proposalId, requestId, and expected digest. ALYT establishes the actor, home authority, transport identity, and outcome from the current authorized context rather than from the request alone. Approval remains separate from execution and physical completion, so the review-only receipt is not the source for actual effect state.

Before invoking an existing owner, ALYT durably records one attempt. If the same request is seen again, or the system restarts, it reads that recorded attempt instead of sending the effect again. This is important for local-first devices and connectors that keep working without cloud access when their local path is still available.

Dependent effects are only allowed when prerequisites are physically confirmed. If a prerequisite is failed or uncertain, or a newer operator command targets the same device, ALYT does not reuse that prerequisite for dependent work.

Interpret physical evidence

ALYT distinguishes several states that matter to developers:

• AUTHORIZED means the effect is prepared, but not physically complete.
• DISPATCHED means the durable send identity has been consumed; delivery and the physical result still need proof.
• OBSERVING means a transport acknowledgement arrived and observation continues.
• CONFIRMED means ALYT has a fresh correlated report or adapter readback from the actual owner.

A cached merged reading, replayed report, model inference, positive routine step, or transport acknowledgement does not count as physical confirmation. For hub-owned Zigbee effects, ALYT attaches a received radio delta to the unique existing dispatched job for that endpoint; the job’s original command tag travels with the observed fields, not a synthesized requested value. Unsent, retired, expired or ambiguous jobs supply no correlation. For light control, ALYT reuses the existing quantization and off semantics already in place. A brightness request at zero needs a correlated power-off report. Unsupported or unobservable results remain uncertain, and a radio acknowledgement cannot prove motion or speech.

Keep the commanded value separate from the observed device state. That separation matters when a device reports a related but not identical field.

Timing and limits

ALYT keeps the original owner lease for at most 45 seconds, shortened by current permission and evidence. Observation ends at the earlier of 60 seconds after the recorded dispatch and 120 seconds after preparation. Neither retries nor reconnection extend those windows. When the hub’s synchronized clock supplies subsecond observation time, ALYT preserves it so a same-second Zigbee report is not mistaken for an older observation.

Timeout is UNKNOWN unless the physical receiver definitively rejects the original command. A run can contain confirmed and unresolved terminal effects at the same time, in which case the overall run is PARTIAL.

Recover and cancel safely

Terminal physical outcomes are monotonic. A late acknowledgement cannot replace CONFIRMED with failure. Late correlated physical evidence can still resolve recovery, while the historical UNKNOWN deadline result remains recorded.

Cancellation before a send claim is CANCELLED. Cancellation after transmission is UNKNOWN until evidence resolves recovery. ALYT withdraws unsent authority and does not blindly resend uncertain effects or restore state over newer operator work.

Reconciliation page behavior

Reconciliation reads the durable ledger, existing command or routine identities, and a bounded cursor over the environment event journal. Each page scans at most sixteen effect identities, and each effect reads at most sixteen journal events. Storage and response limits stay bounded, so you need to persist the returned cursor and start a new pass from its beginning after completion.

Reconciliation remains available through its read cohort when new execution is withdrawn. Preserve the original request and effect IDs, timestamps, evidence strength, and recovery state in diagnostics. Do not log service keys or unrelated household data.

Limit	Value
Maximum effect identities per page	16
Maximum journal events per effect	16
Confirmation window	60 seconds
Maximum lifetime	120 seconds

Access boundaries

These private engine interfaces do not grant DEV or LIVE credentials household execution authority. Household permissions are narrower than staff permissions. DEV credentials act in the developer sandbox, and LIVE credentials only apply to the developer’s own installed connector.

Use the existing authorized device and routine workflows to inspect outcome meaning and recovery. This page does not add a private engine endpoint, credential setup, or a new public proposal API as a developer action. The existing resident execution queue is reused; no observation table or platform catalogue is loaded into the hub.