Fabrizio Ferri Benedetti published Living House on October 23, 2026, describing an experimental interface that adapts its wording, appearance and documentation as someone uses it. The announcement’s default model is Qwen2.5 Instruct 0.5B, quantized to 4 bits and running locally through WebLLM and WebGPU.
The demonstration uses a simulated home-automation service. Clicking controls, navigating between pages, hovering and selecting text give the model signals from which to propose changes. A confusing label might get renamed; a frequently used control might become easier to reach.
The useful contribution is the machinery surrounding those suggestions. Living House gives interface elements permanent identities, restricts what the model can change, validates proposed edits and keeps documentation references connected to the interface.
This is analysis of the author’s description and project documentation, not an independent test. The published evidence provides a concrete implementation to examine, but no usability study showing that its adaptations improve task completion or satisfaction.
Seven Signals, With Explicit Thresholds
Living House collects seven kinds of activity. Two concern hesitation, which is why the list contains seven signals even though several share a broader category.
The announcement documents their default thresholds and intended interpretations:
| Observable activity | Logged as | Default threshold | Interpretation supplied to the model |
|---|---|---|---|
| Clicking or changing a switch, slider or stepper | click, set | Every action | Use; repeated use suggests a habit |
| Changing pages | nav | Every change | Navigation; three consecutive changes without acting suggest searching |
| Hovering over a control | hover | 0.3 seconds | Interest |
| Hesitating on a control | hesitate, with an element ID | 1.5 seconds without clicking | Possible confusion about its label |
| Hesitating on a page | hesitate, without an element ID | 3 seconds without doing anything | Possible difficulty finding what is needed |
| Selecting text | select | A selection of at least two characters | An indication of what the person wants |
| Pointing at text | read | 0.6 seconds | An indication of what the person wants |
A round is one model call that turns recent activity into at most two proposed changes. An intensity setting controls how often the model runs following interaction, so logging an event and invoking the model are separate steps.
The distinction between observation and interpretation matters. A pointer staying over a button is observable. Confusion about that button is an inference. Someone could also be reading carefully, distracted or simply resting the pointer there. Similarly, an event named read cannot establish that someone understood the text.
I’d treat those interpretations as hypotheses when borrowing this design. The thresholds make the experiment reproducible as a configuration, but they are not evidence that 1.5 seconds reliably identifies an unclear label. Living House’s confirmation step is especially important because its inputs remain ambiguous.
Permanent IDs Keep Help Connected to the Interface
Living House renders its interface from a registry. Every entry has a permanent ID and a fixed description of what the element actually does. The registry prevents the model from creating or deleting elements, while permitting supported changes to existing entries.
That separates an element’s identity and function from its displayed wording. A navigation item can receive a new name without becoming a different destination.
Documentation references those stable IDs. The announcement illustrates the mechanism with help text structured like this:
On {{nav_overview}}, choose {{sc_movie}}. It switches off {{lr_ceiling}}, …
The placeholders identify registry entries instead of hard-coding their current labels. When an interface label changes, the corresponding help reference can follow it. The author also describes documentation quoting former labels after a change.
The repository documents a related consistency rule: a page name is shared by its heading, navigation label and help references. Renaming the heading or navigation updates all three, and undo restores them together.
This is the project’s most reusable documentation idea. Keeping names in a shared registry removes a common failure path: an interface changes while instructions continue telling people to click an obsolete label.
It also exposes two different meanings of documentation drift:
- Reference drift: Help text points to a label that no longer appears.
- Terminology drift: Labels remain synchronized, but their changing language becomes confusing or inconsistent.
Permanent IDs address the first problem directly. They cannot, by themselves, prevent the second. A technically valid rename could still make a concept harder to recognize or explain to a colleague.
For a production design, my priority would be preserving a recognizable vocabulary alongside stable references. Living House demonstrates the reference mechanism; the supplied evidence does not establish that unrestricted renaming would remain understandable across longer sessions or multiple users.
Validation Limits What the Model Can Apply
Every model proposal is checked before entering the queue and again immediately before application. That second check matters because the interface may have changed while a suggestion was waiting for approval.
The announcement lists five supported change types and their rejection rules:
| Change | Applies to | Rejected when |
|---|---|---|
| Text replacement | Elements containing text | Empty, unchanged, over 24 characters on a control, or over 120 elsewhere |
| Style change | Any element | Not valid property-value pairs, rejected by CSS.supports, or containing blocked loading or execution syntax |
| Hint | Controls | Empty, unchanged or over 48 characters |
| Move first | Controls | The control is already first |
| Pin | Actions and switches | Already pinned, or four items are already pinned |
Style validation blocks constructs including url, image-set, @import, expression and javascript:. The model therefore cannot freely turn a styling suggestion into an external-resource request through those mechanisms.
These rules constrain different failure modes. Character limits bound text growth. Duplicate checks avoid pointless edits. The pin limit prevents a shortcut area from accumulating everything. Fixed registry membership stops the model from inventing interface elements.
None of those checks proves that a proposal is good design. Valid CSS can still create an awkward visual hierarchy, and a short label can still be misleading. The documented validation is a useful structural gate, not a substitute for accessibility or usability evaluation.
The larger lesson is concrete: the model proposes an edit; application code decides whether that edit is admissible. That division makes the implementation more inspectable than allowing generated output to rewrite the page without a constrained change format.
Approval and Direct Requests Follow Different Paths
Living House asks permission before automatic changes by default. According to the repository, a proposal appears beside the affected element with the model’s explanation. The person can apply it or decline it.
Frequently Asked Questions
3 questions
1Does Living House Send Interaction Data to a Cloud Model?
The repository says inference, prompts, interaction data and performance measurements stay in the browser. Initial runtime and model downloads still require network access.
