Case study · located work
HA-Jev
A Home Assistant custom integration exposing Jev evaluations as sensors and automation actions.
ObservedAboveColin
- Problem
- A Home Assistant custom integration exposing Jev evaluations as sensors and automation actions.
- Jev’s role
- Repeated state classification and typed automation decisions.
- Architecture
- Home Assistant state → TypeSafe evaluation → sensor/action result with a local token-budget guard.
- Why it matters
- Decision models can act as a semantic layer inside an existing event-driven rules engine.
Code boundary
Jev answers the bounded questions described above. Thresholds, retries, side effects, and anything that must be reproducible stay in the surrounding application code. The research record does not capture this project’s exact question set or threshold values; read the linked source before copying the architecture.
Sources
Limitations
- A located repository or demonstration does not establish production reliability or independent validation.
Reusable pattern and related records
- Parallel decision matrix PlausibleOne state is evaluated against many named questions, replacing repeated prompt/parse cycles.
- Home Automation Intent Layer Authored HypothesisA Home Assistant layer turning state changes into typed comfort, safety, and automation decisions.
- Routing, classification, verification, and workflow control are the dominant early mental models. PlausibleThose categories recur in the collected launch discussion and align with the documented output primitives.
- Decision sidecar PlausibleA typed judgment service sits beside ordinary code; code owns effects and safety boundaries.