When the internet is down
Commissioned local control, local policy, core identity, and safety behavior are designed to continue while remote research, cloud notifications, and internet-only tasks pause or degrade.
SIA is a local-first automation platform in development. This is a concept preview, not a verified installed system.
Compare / architecture choices
The difference is not one feature. It is who remains in control.
SIA is designed around local household authority, deterministic policy, independent safety boundaries, canonical device capabilities, and bounded intelligent agents. That architecture changes how the system behaves when the internet, a vendor, a model, or a bridge is unavailable.
This comparison describes common architectural patterns, not every
product in a category. SIA entries represent design targets and
implemented platform principles, not external certification claims.
| Architecture question | SIA design target | Typical cloud-first smart home | Typical proprietary automation system |
|---|---|---|---|
| Where does normal home authority live? | Commissioned home edge | Often split between device clouds and mobile services | Usually local controller, often with vendor-specific boundaries |
| Does internet loss stop ordinary local control? | Designed not to | Can degrade or disable cloud-dependent features and devices | Core local control often remains, depending on subsystem |
| How are different protocols represented? | Canonical capabilities above replaceable adapters | Frequently exposed through separate apps, hubs, or cloud schemas | Integrated through vendor-certified drivers and controller abstractions |
| Can assistance models authorize consequential actions? | No. Model output is proposal; deterministic policy authorizes | Varies by assistant and vendor implementation | Assistant features vary; traditional automation is usually rules-driven |
| How is physical command success treated? | Desired, attempted, observed, and reconciled state are separate | Often presented as request success or device-reported state | Depends on driver feedback and integration quality |
| How are alarm / life-safety responsibilities handled? | Independent safety/security authority plane with bounded integration | Often separate products or cloud services | Usually separate alarm integrations or dedicated subsystems |
| How are users modeled? | Owner, admin, resident, guest, service provider, system principal, optional Agent seat | Usually account, family, guest, or shared-home roles | Often controller users, access levels, rooms, or dealer-defined permissions |
| How is remote access trusted? | Outbound-established session; request re-authorized locally | Usually cloud account and service-mediated | Vendor remote-access stack or integrator-defined path |
| How are cameras handled? | Local ingestion/detection by default; remote session signaling is bounded | Cloud recording and processing are common | Local NVR, third-party VMS, or vendor video subsystem |
| Can a vendor or model be replaced? | Architected behind stable contracts and conformance boundaries | Often tied to each device or ecosystem cloud | Possible within supported driver and controller ecosystems |
| How are consequential effects evidenced? | Structured authorization, command, result, denial, rollback, and release evidence | Activity logs vary by product and cloud provider | Event, controller, dealer, or subsystem logs vary by platform |
Why this matters
Convenience should degrade before authority does.
The architecture is intentionally arranged so higher-level intelligence can become richer without making basic home operation depend on the least predictable component.
When a model is unavailable
Natural-language planning and advanced perception may degrade, but ordinary controls, schedules, policy, and deterministic device execution do not need a model to remain authoritative.
When a driver is compromised
Signed manifests, sandboxing, declared permissions, and driver kill switches are designed to isolate an adapter without taking unrelated home operation down with it.
The SIA authority stack
Higher intelligence never outranks higher authority.
SIA separates physical safety, independent alarm authority, deterministic household policy, owner/admin policy, authorized manual control, and automation or Agent proposals.
Physical safety / reviewed interlocks
Cannot be overridden by assistance models, cloud services, ordinary UI, or automation
Independent safety / security plane
Alarm partitions, supervision, deadlines, approved output mappings
SIA Core deterministic policy
Household identity, grants, ordinary effects, reconciliation, evidence
Household owner / admin policy
Membership, zones, privacy choices, delegated roles
Manual control → automation → Personal Agent
Each lower layer remains bounded by the authority above it
A better buying question
Do not ask only, “What can it control?”
Ask what happens when a cloud service disappears, whether remote commands are re-authorized locally, how guest privacy is separated, whether the system can prove the physical result, how an unsafe adapter is contained, and who can override whom.
Architecture before feature count
A platform can have hundreds of integrations and still have weak authority boundaries. SIA is being built so capability growth does not silently expand privilege.
See it in context
Compare the architecture to your actual home.
Existing devices, wiring, network quality, security expectations, room layout, media, and household roles all affect the right path to a SIA deployment.