Integrate bounded semantic events

Bounded semantic events let ALYT evaluate current environmental changes against active goals without blocking local control, routines, or security. This path is separate from interactive chat and always runs in SHADOW: it can produce a context-pinned suggestion or NO_ACTION, but it never grants execution authority and never proves a physical result. The runtime compares authorized current observations, filters out irrelevant or unchanged data, applies strict scheduling and expiry limits, and withholds reasoning whenever the original context, evidence, access, or storage state is no longer trustworthy.

How bounded semantic event reasoning works

ALYT reasons over three inputs:

• the current authorized environmental state
• the original physical evidence behind that state
• explicit active goals owned by the current actor

Reasoning starts only after deterministic checks run first. Existing local routines, device control, and security behavior do not wait for a model result.

The event request schema is alyt.event-reasoning/draft-0.1.0. It carries:

• SHADOW mode
• a stable workId
• goalId
• deadlineMs
• a bounded model-only context

The result schema is alyt.event-reasoning-result/draft-0.1.0. Results are SHADOW, SYNTAX_ONLY, and always have physicalEffects=0.

A parsed intent is still not authorization. A suggestion can be syntactically valid and still have zero effect. The model-independent adapter returns NO_ACTION; this is the default fake adapter output, not the only syntactically permitted intent.

What counts as a relevant change

ALYT triggers reasoning only for relevant semantic changes.

The first snapshot, changed inventory, changed actor scope, restart recovery, or a replay gap establishes a baseline. That baseline does not reinterpret prior history as a new action.

These cases do not create calls:

• unchanged reports
• retained samples
• replay-only initialization

Change detection depends on value type:

Value type	Trigger rule
Boolean	Value must differ
Option	Value must differ
Numeric	Change must reach a threshold

For numeric observations, ALYT uses a deadband of one unit or a larger descriptor step. The threshold is max(1, control.step or 1). The previous qualifying baseline is kept so smaller increments accumulate until they cross the threshold. This prevents noise from triggering reasoning while still allowing smaller increments to add up.

Goal scope and permissions

Only active goals declared by the current actor qualify. When the event path explicitly negotiates the graph 1.1 profile, it may correlate non-authoritative findings to the exact selected declared goal and its supplied record revision, but it still refuses missing, stale, duplicate, or foreign metadata and never turns progress into execution authority or a physical result.

ALYT resolves each goal’s room and entity scope from current memory into engine-only metadata used for filtering. That metadata stays out of model context. Older snapshots that do not have this scope metadata schedule no goals.

Goal text and policy summaries do not create permission, standing rules, or execution authority. Missing or stale evidence is not treated as a physical result, and incomplete history stays explicit.

Where access matters, household permissions are narrower than staff. Current authorization is rechecked before admission and again after completion. Revoked access, enrollment changes, expired goals, changed evidence, and replay gaps all withdraw pending work.

Runtime boundary

This event adapter is an internal runtime integration, not an end-user command surface.

The gateway accepts a protected POST to /internal/environment/events/shadow, but this and related diagnostics are internal and not public SDK routes. Publication of this guide does not make them available to API keys or connector code.

Important boundaries:

• Model input cannot supply tenant, enrollment, provider choice, native bindings, leases, or command callbacks.
• Parsing a result never creates dispatch authority.
• An internal key is not physical authority.
• Local Home dispatch can use a zero-effect fake runner and does not silently route household context to the gateway.

Scheduling, limits, and recovery

Per configured Home, ALYT stores at most:

Limit	Value
Queued or running jobs	8
Terminal receipts	64
Semantic comparison fields	64
Durable work metadata	32 KiB

Job execution limits:

Limit	Value
Job lifetime	30seconds
Runner deadline	2second
Invocation rate	6calls per minute
Minimum interval	10second
Request size	49,152 bytes
Concurrent runners	1

The 30seconds lifetime is clipped further by the original expiry of the goal, evidence, and context.

If the queue is full, noncritical reasoning is dropped and canonical state is preserved. If multiple pending jobs target the same goal and comparison field, ALYT applies coalescing and keeps the newest work.

The durable cursor and work identity are committed before runner invocation. Because of that, identical replay cannot create another intent.

Cancellation and restart behavior

Reasoning is withdrawn when its assumptions no longer hold.

ALYT performs cancellation when:

• a goal is cancelled or expires
• evidence changes
• access is revoked
• enrollment changes
• a replay gap is detected
• the original context expires

Late output is discarded.

On restart, queued and attempted work is abandoned rather than retried, because original monotonic timing cannot be restored safely. Processing resumes from the cursor and requires authenticated current context again. On first installation, a missing work record initializes a baseline. By contrast, corrupt or unreadable work records, or storage I/O failures, withhold reasoning.

If wall-clock time moves backward, ALYT withholds reasoning. It does not extend jobs, refresh budgets, or recover expired work.

A trusted enrollment replacement also preserves the occupied runner slot. If the earlier invocation ignores cancellation, the replacement does not overlap it. The next authenticated poll establishes a new baseline.

Output semantics

The result path is suggestion-only.

A strict result can carry a context-pinned suggestion with physicalEffects set to 0. The subscriber does not execute it, authorize it, or treat it as proof of a physical effect.

NO_ACTION is valid and common. It means the bounded semantic pass found nothing to propose under current evidence and constraints.

Diagnostics

The protected local GET /environment/events/metrics reports aggregate diagnostics for a configured home, including:

• queue depth
• lag
• drops
• coalescing
• gaps
• cancellations
• timeouts
• incomplete or abandoned work
• original receipt-to-view age

These diagnostics exclude tenant IDs, native IDs, readings, goal text, and free-text labels. Do not expose them to an unauthenticated LAN.

Disable and rollback

This feature is off by default.

Disabling it cancels or withholds reasoning while preserving canonical state, ordinary configuration, local control, routines, and voice behavior. A corrupt or full work file also withholds reasoning. Recovery should preserve device and configuration data and should not replay commands.

As with all local-first behavior, local functions can continue during a cloud outage. Any cloud-dependent connector still requires its provider and network path, and this semantic event path should not be treated as a fallback execution channel.