HELIOS translates human language into a bounded request.
Trust architecture
Intelligence that remains bounded and accountable.
HELIX is being built around a simple principle: AI may help interpret the request, but household policy and deterministic services must remain responsible for execution.
The execution boundary
AI proposes. HELIX validates and executes. You remain in control.
A language model is useful for translating intent, explaining context, and helping author structured changes. It should not become an invisible, unconstrained control path.
Use known devices, capabilities, current state, policy, and available tools.
Check structure, permissions, supported actions, and safety boundaries.
Require review where the action or change warrants it.
Deterministic platform services dispatch the authorized action.
Retain the event, action, result, and uncertainty needed for later explanation.
Privacy posture
Local‑first does not mean pretending the cloud never exists.
HELIX prefers local device control and local household context. Some devices, integrations, remote access paths, and optional AI providers may still require external services. Those dependencies should be explicit and controllable.
Local wherever practical
Run the home model, platform services, dashboards, policy, and sensitive context on hardware controlled by the household.
Cloud only where chosen or required
Identify which integrations depend on vendor clouds and which AI tasks leave the appliance rather than hiding those facts.
No sale of household data
The business model should not depend on selling personal information or behavioral profiles to advertisers.
System safeguards
Trust requires visible operational boundaries.
Roles and permissions
Powerful administration, integrations, household context, and remote support require explicit access boundaries.
Preview before material change
Migration, generated configuration, dashboards, connectors, and automations should be reviewable before they become active.
Evidence and event history
Connector health, model failover, system actions, and relevant outcomes should remain visible for explanation and diagnosis.
Integration isolation
Vendor-specific code runs outside the core process and communicates through a defined protocol.
Recovery and rollback
Important changes should have a recovery path, and uncertainty should be surfaced before the system claims success.
Clean-room development
HELIX connectors are built from vendor documentation and APIs rather than copied from Home Assistant or other community platforms.
Honest limitations
What HELIX should say when it does not know.
Trust degrades when a home platform treats dispatch, vendor acknowledgement, reported state, and physical outcome as the same thing.
“The command was sent.”
This is not the same as confirming that the device changed.
“The connector reports success.”
A vendor API may accept a request while the real device behaves differently.
“The device reports this state.”
Cloud and device state can be stale, incomplete, or inconsistent with physical reality.
“HELIX cannot verify the outcome.”
This is sometimes the most truthful and useful answer—and should be treated as a first-class system state.
Review the product evidence
Trust claims should remain connected to what the platform actually implements.
The public build page separates implemented foundations from partial capabilities and future direction.