A permission-based residential intelligence architecture for bounded, auditable, human-governed AI integration in the home
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.
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.
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.
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.
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.
| Component | Example Product | Purpose | Est. Cost |
|---|---|---|---|
| Local hub | Raspberry Pi 5 (8GB) + case + cooling | Runs Home Assistant; local automation | $95 |
| Storage | 128GB microSD (A2) + 256GB USB SSD | OS + persistent storage | $35 |
| Matter controller | Built into HA on Pi via USB Zigbee dongle (SLZB-06) | Protocol bridge for devices | $30 |
| Lighting (3 bulbs) | Sengled Zigbee A19 | Scene automation; Class 6 demo | $36 |
| Thermostat | Ecobee SmartThermostat (Matter) | Climate control; Class 4 | $189 |
| Smoke + CO sensor | First Alert Onelink (Matter) | Safety monitoring; Class 5 | $60 |
| Motion sensor | Aqara P1 (Zigbee) | Presence awareness | $25 |
| Smart plug (2x) | SONOFF S31 (Zigbee) | Energy monitoring; Class 4 | $22 |
| Network | Existing router — HA isolated on dedicated SSID | Basic network separation | $0 |
| Entry Tier Total | ~$492 | ||
| Component | Example Product | Purpose | Est. Cost |
|---|---|---|---|
| Local hub | Intel NUC 13 Pro (16GB RAM, 512GB SSD) | Full local inference capability; HA + Ollama | $450 |
| Privacy router | GL.iNet Flint 2 (running OpenWrt) | VLAN isolation; ad/tracker blocking; local DNS | $90 |
| Matter/Zigbee | Home Assistant SkyConnect USB + SLZB-06 | Dual-protocol device support | $55 |
| Smart lock | Schlage Encode Plus (Matter) | Access control; Class 3 default | $229 |
| Doorbell camera | Reolink Video Doorbell (local RTSP, no cloud) | Presence; Class 1 observe only | $80 |
| Thermostat | Ecobee 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 Caseta | Scenes; Class 6 | $130 |
| NAS / backup | Synology DS223 + 2×2TB drives | Local backup; audit log storage | $330 |
| Mid Tier Total | ~$1,891 | ||
| Component | Example Product | Purpose | Est. Cost |
|---|---|---|---|
| Server | Mini server (Beelink SER8 or similar, 32GB, 1TB NVMe) | Full inference; redundant HA | $600 |
| AI accelerator | NVIDIA Jetson Orin NX (16GB) | Local vision AI for elder care / safety | $500 |
| Network infrastructure | Ubiquiti UniFi Dream Machine Pro + managed switches + VLAN segmentation | Enterprise network isolation per device class | $900 |
| Access control | 4× Schlage Encode Plus (Matter) + garage controller | Multi-entry Class 3; audit logged | $1,000 |
| Cameras (6×) | Reolink local RTSP cameras (no cloud) | Local-only recording; Class 1 | $480 |
| Elder care sensors | Vayyar Care radar sensors (2×) + Apple Watch SE for residents | Fall detection; Class 5 notify-only | $900 |
| Medical alert | Bay Alarm Medical + local integration | Emergency escalation; Class 5 | $300 |
| Climate (multi-zone) | 4× Ecobee Premium + 2× Sensibo Air for mini-splits | Room-level climate; Class 4 | $700 |
| Safety sensors | 8× smoke/CO + 6× water leak + 4× air quality | Full coverage; Class 5 | $480 |
| Energy monitoring | Emporia Vue 3 whole-home energy monitor | Circuit-level monitoring | $150 |
| Lighting | Lutron RadioRA 3 system (24 devices) | Scenes; reliable Class 6 | $1,200 |
| UPS / power backup | APC 1500VA UPS for hub + network | System availability during outage | $250 |
| Premium Tier Total | ~$7,460 | ||
| Risk Domain | Specific Risk | Severity | Likelihood | Mitigation Required |
|---|---|---|---|---|
| Privacy | Vendor cloud exfiltration of home sensor data via compromised or updated device firmware | High | Medium | Local-first architecture; network-level blocking of cloud endpoints; device VLAN isolation; no cloud requirement for core function |
| Privacy | Audit log data exposure revealing household occupancy patterns, health status, relationship dynamics | High | Medium | Encrypted local storage; Foundation audit access limited to aggregate compliance data; resident controls all raw log access |
| Cybersecurity | Local intelligence hub compromise — smart locks, cameras, safety systems all on one network | Critical | Medium | VLAN isolation per device class; hardware firewall between device VLANs; strong authentication for hub admin; automatic security updates; no default passwords |
| Cybersecurity | Supply-chain attack via OTA firmware update to Matter-compatible device | High | Low | Staged OTA rollout; firmware signature verification; rollback capability; Foundation certification requires update security documentation |
| Domestic Abuse | System weaponized for coercive control — monitoring partner movements, locking rooms, controlling environment | Critical | High | Single-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 Abuse | Abuser using remote access to monitor or control the home after relationship ends | Critical | High | Emergency 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 Safety | COPPA compliance failure — sensor and behavioral data collected about minors in the home | High | High | Child 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 Safety | Child safety sensors used to surveil rather than protect — location tracking, behavior monitoring | High | Medium | Child 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 |
| Eldercare | Fall detection false positive rate (60–85% for consumer sensors) triggering unnecessary emergency escalation | High | High | Emergency 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 |
| Eldercare | HIPAA exposure — medical alert device data transmitted through home system may constitute PHI | High | Medium | Legal analysis required before eldercare module certification; medical alert integration kept separate from general home data; BAA consideration for any third-party medical integrations |
| Emergency Automation | Fire response automatically unlocking doors creates security vulnerability; potential for social engineering exploit | Critical | Medium | Emergency 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. |
| Liability | False negative — system fails to detect emergency, person is harmed; Foundation certification implies reliability | Critical | Low | Certification 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 Capture | Foundation certification revenue from device manufacturers creates conflict of interest in standards setting | High | High | Anti-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 |
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 Type | Who It Applies To | Annual Fee | What It Covers |
|---|---|---|---|
| Device Certification | Hardware manufacturers seeking ARIA-Compatible device labeling | $2,500–$10,000 depending on company revenue | One-time technical review + annual compliance renewal; no editorial or standards authority |
| Installer Certification | Integrators and installers deploying ARIA Home systems | $500/year per installer | Training materials access; use of ARIA-Certified Installer mark; Foundation directory listing |
| Institutional License | Eldercare facilities, property developers, estate managers deploying at scale | $5,000–$25,000 depending on scale | Compliance 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.
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.
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.
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.
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.
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.
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.