Open Source Proposal — EM Foundation — May 2026

ARIA Home

A permission-based residential intelligence architecture for bounded, auditable, human-governed AI integration in the home

EM Foundation  ·  May 2026  ·  emfoundation.net
Connects to: Bounded Autonomy (RN 009), ARIA Framework, Behavioral Architecture (RN 008).
Status: Open Source Proposal — prototype, certification, and licensing framework.
Proposal Status — Architecture Design and Certification Framework

ARIA Home is a proposed governance and architecture standard, not a manufactured product. The Foundation does not build or sell hardware. Phase One describes a reference prototype the Foundation intends to build for demonstration purposes. The certification framework described in Phase Three is a proposed nonprofit licensing model, not a regulatory standard. All cost estimates are approximate and subject to hardware market conditions.

Executive Summary

Public acceptance of AI in daily life will not be won through safety assurances alone. It will be won — or lost — through lived experience: does the AI in my home behave predictably, explain itself, respect my authority over it, and remain under my control? ARIA Home proposes an answer to that question as a governance architecture rather than a product.

The proposal defines a permission-based residential intelligence standard that allows any AI assistant — current or future — to interact with home systems through bounded, auditable, revocable modules. No single vendor controls the stack. No cloud subscription is required for core operation. Every significant AI action is logged with an explanation. Every permission can be revoked instantly. The human is always the authority.

This architecture is buildable today using open-source software and widely available hardware. Its novelty is not the components — Home Assistant, Matter-compatible devices, and edge inference hardware all exist. Its novelty is the ethical governance layer: a structured permission taxonomy, an audit trail standard, an identity and role framework for multi-user households, and a Foundation-governed certification mark that signals compliance with these principles to consumers, installers, and regulators.

The proposal also names the risks the architecture must be designed to resist from the outset: domestic abuse misuse, cybersecurity vulnerabilities in high-value home systems, false-positive emergency automation, COPPA and HIPAA exposure in homes with children or eldercare needs, and the capture risk inherent in any certification body that receives revenue from the manufacturers it certifies. Each of these is treated as a design constraint, not a footnote.

I. The Problem This Addresses

The smart-home market is large, growing, and structurally broken. Consumers own devices but not their data architectures. Smart locks, cameras, voice assistants, thermostats, and sensors operate in separate commercial ecosystems with incompatible APIs, cloud dependencies, and data-harvesting business models. The fragmentation is not accidental — it reflects the commercial incentives of platform vendors who benefit from lock-in.

At the same time, public anxiety about AI is real and well-documented. Pew Research Center's June 2025 survey found that half of U.S. adults felt more concerned than excited about increased AI use in daily life, with only 10% more excited than concerned.1 This anxiety is not primarily technical — it is relational. People do not know what AI systems are doing, why, or on whose behalf. The abstraction that makes AI powerful is the same abstraction that makes it threatening.

ARIA Home addresses both problems through the same mechanism: making AI's domestic presence explicit, bounded, logged, and revocable. A home intelligence system whose actions are visible and whose authority is clearly limited by the resident's deliberate choices is categorically different from a home intelligence system that operates as a black box serving vendor interests.

What This Proposal Is Not ARIA Home is not a claim that AI is safe, conscious, or ready for unrestricted domestic deployment. It is a claim that if AI is going to be present in homes — and it already is — the architecture governing that presence should be designed around human sovereignty rather than vendor convenience.

II. Core Architecture — System Diagram

Figure 1: ARIA Home System Architecture — Five Layer Stack Figure 1 — ARIA Home System Architecture LAYER 1 — HUMAN GOVERNANCE Resident authority · role-based permissions · audit review · override · revocation · emergency control LAYER 2 — PERMISSION + AUDIT ENGINE Permission registry Action log + explanation Role + identity management LAYER 3 — LOCAL INTELLIGENCE CORE Home Assistant automation engine Edge AI Inference local LLM / NLU Matter Controller device protocol bridge Network Security Layer VLAN · firewall · cert mgmt LAYER 4 — DEVICE MODULES (permission-gated) Safety smoke · CO · leak Access locks · garage Climate HVAC · thermostat Energy solar · EV · plugs Presence motion · cameras Care elder · medical alert Lighting scenes · schedules LAYER 5 — OPTIONAL CLOUD SERVICES (explicit opt-in only) Remote access · backup · AI assistant APIs · emergency dispatch · Foundation audit

Figure 1 — ARIA Home five-layer architecture. Layer 1 (Human Governance) is the authority layer — all permissions originate here and all overrides operate here. Layer 2 (Permission + Audit Engine) is the enforcement layer — no device action executes without passing through it. Layer 3 (Local Intelligence Core) provides automation, inference, and protocol translation. Layer 4 (Device Modules) contains all physical devices, each accessed only through permission gates. Layer 5 (Optional Cloud) is dashed — explicit opt-in only, never required for core operation.

III. Permission Layer Architecture

Figure 2: ARIA Home Permission Layer — Access Class Taxonomy Figure 2 — Permission Layer: Access Class Taxonomy ← LESS AUTHORITY MORE AUTHORITY → CLASS 0 DISABLED No access CLASS 1 OBSERVE Read-only · no action CLASS 2 RECOMMEND Suggest · no act CLASS 3 ASK FIRST Propose · await approval CLASS 4 BOUNDED ACT Act within policy · log all CLASS 5 EMERGENCY Defined crisis triggers only CLASS 6 AUTO-POLICY Preapproved routines only Example Permission Assignments by Device Category Device Default / Recommended Rationale Smoke / CO sensors Class 5 — Emergency Only Alert + notify; never auto-unlock doors Smart locks Class 3 — Ask First Access control; always requires approval Thermostat Class 4 — Bounded (±2°F) Comfort automation within narrow range Security cameras Class 1 — Observe Only Never AI-controlled recording triggers Energy / smart plugs Class 4 — Bounded (policy) Efficiency routines; no critical loads Medical alert / elder care Class 5 — Emergency Only Notify contacts only; no autonomous action Lighting Class 6 — Auto-Policy Scenes and schedules; low-risk

Figure 2 — Permission access class taxonomy. Seven classes from Disabled (0) to Auto-Policy (6). Every device module is assigned a class by the resident; the default assignments shown reflect the principle that authority should increase conservatively — access control, health, and safety devices default to restrictive classes. Every action in Class 3 and above is logged with explanation. Class 5 (Emergency) triggers are strictly defined and cannot be expanded without resident re-authorization.

Emergency Automation — Critical Design Constraint The original proposal notes fire response as an example of emergency automation. This requires explicit design discipline: a smoke alarm triggering an AI system to automatically unlock all doors is a security vulnerability, not a safety feature. ARIA Home emergency behaviors must be strictly defined: alert residents, notify designated contacts, and log the event. Physical access control actions during emergencies must require explicit pre-authorization of specific scenarios, not general emergency authority. The fail-safe versus fail-secure question — whether doors unlock or stay locked during a fire — is a life-safety design decision that must be made by the resident in advance, not resolved automatically by the system.

IV. Hardware Bill of Materials

Entry Tier — Approximately $350–550

Entry Tier — Renter / Apartment / First Deployment — ~$350–550
ComponentExample ProductPurposeEst. Cost
Local hubRaspberry Pi 5 (8GB) + case + coolingRuns Home Assistant; local automation$95
Storage128GB microSD (A2) + 256GB USB SSDOS + persistent storage$35
Matter controllerBuilt into HA on Pi via USB Zigbee dongle (SLZB-06)Protocol bridge for devices$30
Lighting (3 bulbs)Sengled Zigbee A19Scene automation; Class 6 demo$36
ThermostatEcobee SmartThermostat (Matter)Climate control; Class 4$189
Smoke + CO sensorFirst Alert Onelink (Matter)Safety monitoring; Class 5$60
Motion sensorAqara P1 (Zigbee)Presence awareness$25
Smart plug (2x)SONOFF S31 (Zigbee)Energy monitoring; Class 4$22
NetworkExisting router — HA isolated on dedicated SSIDBasic network separation$0
Entry Tier Total~$492

Mid Tier — Approximately $1,200–1,800

Mid Tier — Homeowner / Small Family — ~$1,200–1,800
ComponentExample ProductPurposeEst. Cost
Local hubIntel NUC 13 Pro (16GB RAM, 512GB SSD)Full local inference capability; HA + Ollama$450
Privacy routerGL.iNet Flint 2 (running OpenWrt)VLAN isolation; ad/tracker blocking; local DNS$90
Matter/ZigbeeHome Assistant SkyConnect USB + SLZB-06Dual-protocol device support$55
Smart lockSchlage Encode Plus (Matter)Access control; Class 3 default$229
Doorbell cameraReolink Video Doorbell (local RTSP, no cloud)Presence; Class 1 observe only$80
ThermostatEcobee Premium (Matter)Climate; Class 4 bounded ±2°F$249
Smoke/CO (3x)First Alert Onelink (Matter)Multi-room safety monitoring$180
Water leak sensors (3x)Aqara Water Sensor (Zigbee)Leak detection; Class 5 notify$54
Smart plugs (4x)SONOFF S31 (Zigbee)Energy + appliance monitoring$44
Lighting (8 bulbs + 2 switches)Sengled / Lutron CasetaScenes; Class 6$130
NAS / backupSynology DS223 + 2×2TB drivesLocal backup; audit log storage$330
Mid Tier Total~$1,891

Premium Tier — Approximately $5,000–8,000

Premium Tier — Estate / Eldercare Facility / Institutional — ~$5,000–8,000
ComponentExample ProductPurposeEst. Cost
ServerMini server (Beelink SER8 or similar, 32GB, 1TB NVMe)Full inference; redundant HA$600
AI acceleratorNVIDIA Jetson Orin NX (16GB)Local vision AI for elder care / safety$500
Network infrastructureUbiquiti UniFi Dream Machine Pro + managed switches + VLAN segmentationEnterprise network isolation per device class$900
Access control4× Schlage Encode Plus (Matter) + garage controllerMulti-entry Class 3; audit logged$1,000
Cameras (6×)Reolink local RTSP cameras (no cloud)Local-only recording; Class 1$480
Elder care sensorsVayyar Care radar sensors (2×) + Apple Watch SE for residentsFall detection; Class 5 notify-only$900
Medical alertBay Alarm Medical + local integrationEmergency escalation; Class 5$300
Climate (multi-zone)4× Ecobee Premium + 2× Sensibo Air for mini-splitsRoom-level climate; Class 4$700
Safety sensors8× smoke/CO + 6× water leak + 4× air qualityFull coverage; Class 5$480
Energy monitoringEmporia Vue 3 whole-home energy monitorCircuit-level monitoring$150
LightingLutron RadioRA 3 system (24 devices)Scenes; reliable Class 6$1,200
UPS / power backupAPC 1500VA UPS for hub + networkSystem availability during outage$250
Premium Tier Total~$7,460
Important Caveat on Local LLM Inference The original proposal suggests running a local LLM on a Raspberry Pi for real-time home automation. This is not currently practical for responsive use. A Pi 5 running an 8B-parameter model generates 2–5 tokens per second — adequate for asynchronous tasks (daily summaries, log analysis, overnight automation planning) but not for real-time voice response or sub-second automation decisions. The Mid Tier and Premium Tier include hardware capable of meaningful local inference. The Entry Tier uses Home Assistant's rule-based automation engine for real-time decisions and reserves AI inference for non-time-critical analysis.

V. Risk Matrix

Risk DomainSpecific RiskSeverityLikelihoodMitigation Required
PrivacyVendor cloud exfiltration of home sensor data via compromised or updated device firmwareHighMediumLocal-first architecture; network-level blocking of cloud endpoints; device VLAN isolation; no cloud requirement for core function
PrivacyAudit log data exposure revealing household occupancy patterns, health status, relationship dynamicsHighMediumEncrypted local storage; Foundation audit access limited to aggregate compliance data; resident controls all raw log access
CybersecurityLocal intelligence hub compromise — smart locks, cameras, safety systems all on one networkCriticalMediumVLAN isolation per device class; hardware firewall between device VLANs; strong authentication for hub admin; automatic security updates; no default passwords
CybersecuritySupply-chain attack via OTA firmware update to Matter-compatible deviceHighLowStaged OTA rollout; firmware signature verification; rollback capability; Foundation certification requires update security documentation
Domestic AbuseSystem weaponized for coercive control — monitoring partner movements, locking rooms, controlling environmentCriticalHighSingle-admin architecture prohibited — all occupants above a minimum age must receive independent account access. Audit logs accessible to all registered residents, not only the account holder. Foundation certification requires documented coercive control prevention architecture. Partnership with domestic violence advocacy organizations required before certification launch.
Domestic AbuseAbuser using remote access to monitor or control the home after relationship endsCriticalHighEmergency account migration procedure — any registered resident can initiate full account transfer removing all other access. Offline-capable so remote abuser cannot block the transfer.
Child SafetyCOPPA compliance failure — sensor and behavioral data collected about minors in the homeHighHighChild accounts flagged at setup; data minimization by default for child-tagged accounts; no cloud transmission of child-associated data without explicit COPPA-compliant consent; legal review before certification launch in US market
Child SafetyChild safety sensors used to surveil rather than protect — location tracking, behavior monitoringHighMediumChild safety module limited to Class 5 emergency only by default; no behavioral pattern logging for child accounts; age-based restrictions on what data is retained
EldercareFall detection false positive rate (60–85% for consumer sensors) triggering unnecessary emergency escalationHighHighEmergency escalation requires multi-sensor confirmation (fall sensor + no movement for N minutes + no manual dismissal); resident and emergency contacts alerted before any 911 dispatch; ARIA Home does not dispatch emergency services autonomously without explicit pre-authorization
EldercareHIPAA exposure — medical alert device data transmitted through home system may constitute PHIHighMediumLegal analysis required before eldercare module certification; medical alert integration kept separate from general home data; BAA consideration for any third-party medical integrations
Emergency AutomationFire response automatically unlocking doors creates security vulnerability; potential for social engineering exploitCriticalMediumEmergency automation never includes door unlocking as a default. Specific emergency scenario behaviors are pre-authorized by residents explicitly, documented in the permission registry, and reviewed annually. Fire response default: alarm, notify, log. Door behavior during fire: resident's pre-authorized choice only.
LiabilityFalse negative — system fails to detect emergency, person is harmed; Foundation certification implies reliabilityCriticalLowCertification explicitly disclaims any warranty of reliability for life-safety applications; ARIA-Ready mark certifies governance architecture, not sensor performance; all safety sensors should be supplementary to, not replacements for, certified life-safety devices
Certification CaptureFoundation certification revenue from device manufacturers creates conflict of interest in standards settingHighHighAnti-capture governance architecture (see Section VI) — same 15% revenue concentration limit applied to certification revenue; standards committee independent of certification revenue; public disclosure of all manufacturer relationships

VI. Nonprofit Licensing Model

ARIA Home Certification — Nonprofit Licensing Framework v1.0

Purpose. The Foundation licenses the ARIA-Ready mark to manufacturers, installers, and system integrators who demonstrate compliance with the ARIA Home governance architecture standard. The mark signals to consumers that a product or installation meets the Foundation's published ethical and technical requirements. The mark does not warrant device reliability, sensor accuracy, or safety performance.

Revenue structure. Three fee tiers apply:

License TypeWho It Applies ToAnnual FeeWhat It Covers
Device CertificationHardware manufacturers seeking ARIA-Compatible device labeling$2,500–$10,000 depending on company revenueOne-time technical review + annual compliance renewal; no editorial or standards authority
Installer CertificationIntegrators and installers deploying ARIA Home systems$500/year per installerTraining materials access; use of ARIA-Certified Installer mark; Foundation directory listing
Institutional LicenseEldercare facilities, property developers, estate managers deploying at scale$5,000–$25,000 depending on scaleCompliance templates, audit support, Foundation review for non-standard deployments

Anti-capture governance. Consistent with the Foundation's transparency policy: no single manufacturer or affiliated group may constitute more than 15% of annual certification revenue. Device manufacturers receive no authority over standards committees, certification criteria, or Foundation governance. All manufacturer relationships are publicly disclosed in the annual report. The standards committee that defines ARIA-Ready criteria is composed of independent technical and ethics reviewers, not certification fee payers.

Open-source baseline. The core ARIA Home architecture specification — permission taxonomy, audit log format, role and identity framework, network security baseline — is published without restriction. Anyone may implement it. The certification mark is what is licensed, not the specification itself. This prevents the Foundation from creating a proprietary standard that enriches it while constraining the ecosystem.

Revenue allocation. Certification revenue is allocated as follows: 40% to ongoing standards development and maintenance; 30% to Foundation general operations; 20% to a domestic abuse and elder safety advisory program; 10% to a reserved fund for independent security audits of certified systems.

Revenue projection (Year 3). At 50 device certifications averaging $5,000 each ($250K), 200 installer certifications at $500 ($100K), and 10 institutional licenses averaging $10,000 ($100K), total annual certification revenue would be approximately $450,000 — meaningful for a nonprofit research organization while remaining well below the scale that would create governance risk.

VII. Known Limitations and Open Questions

What This Proposal Does Not Resolve The claim that ARIA Home will measurably improve public acceptance of AGI is large and unsupported. The mechanism by which a home automation certification program changes broad public attitudes toward advanced AI has not been established. The more defensible claim — that a home where AI behaves transparently and under human control is a better lived experience than one where it does not — does not require AGI framing and is stronger without it. The Foundation recommends removing AGI from the product positioning entirely and letting the governance architecture speak for itself.

The domestic abuse risk is the most serious unresolved design question in this proposal. The Foundation will not launch a certification program for home systems that can be weaponized for coercive control without first consulting with domestic violence researchers and advocacy organizations. This is not optional due diligence — it is a precondition for any certification launch.

The technical barrier for non-expert users remains substantial. Home Assistant requires ongoing configuration that most non-technical households will find prohibitive. Phase One should honestly target technically capable early adopters, not general consumers. The path to broader adoption runs through installer certification and pre-configured kits, not self-deployment documentation.

Known Limitations

The Foundation has no regulatory authority. ARIA-Ready certification is a voluntary market signal, not a regulatory compliance designation. It cannot be represented to consumers as a government-endorsed safety standard.

Matter interoperability is incomplete. Matter 1.x addresses many device categories but significant gaps remain, particularly in medical alert, elder care, HVAC systems, and EV charging. The proposal's interoperability claims require qualification by category.

The eldercare module requires independent medical device regulatory review. In some deployment contexts, fall detection and health monitoring integration may trigger FDA oversight or HIPAA obligations. The Foundation will engage legal counsel before certifying eldercare deployments.

Non-Adoption Scenario

Without a governance architecture standard for residential AI, the default trajectory is continued consolidation around vendor-controlled ecosystems with opaque data practices, no audit trails, and no human sovereignty architecture. The domestic abuse risk compounds without any industry norm requiring independent resident access. Eldercare AI deployments will proceed without coercive control or false-positive emergency automation standards. The Foundation's contribution is not preventing AI in the home — it is ensuring that when AI is in the home, the home remains the resident's.

Governance Implications

The Foundation should not launch Phase Three certification before completing: domestic abuse architecture review with advocacy organization partners; COPPA/HIPAA legal analysis for child and eldercare modules; independent security audit of the reference prototype; and publication of the open-source ARIA Home specification for community review. Each of these is a governance gate, not a timeline milestone.

References

1. Pew Research Center. "Americans' Views of Artificial Intelligence in Daily Life." June 2025. pewresearch.org. · 2. Reuters/Ipsos. "AI and the American Worker Poll." 2025. · 3. Matter Connectivity Standards Alliance. "Matter 1.3 Specification." 2024. csa-iot.org. · 4. Tanczer, L.M. et al. "Gender and IoT Research Report: The Rise of Tech-Facilitated Abuse." University College London, 2018. — foundational research on smart-home abuse. · 5. EM Foundation. Bounded Autonomy in Recursive Continuity Architectures. Research Note 009. · 6. Home Assistant. "Architecture Overview." home-assistant.io/docs. · 7. Grand View Research. "Smart Home Market Size Report." 2024. — source for market size estimates; specific figures should be verified against current data at time of publication. · 8. NIST. "Cybersecurity for IoT Program: Consumer IoT Cybersecurity." NISTIR 8425, 2022.

Falsifiability

If residents with ARIA-Ready certified systems demonstrate no measurable difference in perceived AI transparency, trust, or control compared to residents with conventional smart-home systems — measured through longitudinal survey at 12 and 24 months post-deployment — the governance architecture would not be delivering its claimed experiential benefit and the certification program's value proposition would require fundamental reconsideration.

If the domestic abuse risk cannot be adequately mitigated through architecture design — if consultation with domestic violence researchers concludes that no technically feasible architecture can prevent coercive control misuse of a residential AI permission system — the Foundation should not launch the certification program regardless of its other merits.

Final Clarification

ARIA Home does not propose a new technology. It proposes a new relationship between people and the technology already entering their homes. The hardware is available. The software is open-source. What does not yet exist is a governance standard that puts residents in structural authority over the systems sharing their domestic space.

The home is not a data center. It is a governed space. The architecture should reflect that.