Abstract
A home assistant can pass every test in its repository and still fail the people who live with it. Conventional tests certify code against a specification an engineer wrote down. They cannot report that a resident was cold this morning, or that a stated preference was forgotten by the afternoon. Elysium closes this measurement gap with a second system that lives outside the product: a language-model-driven household simulator that conducts simulated daily life against the real, running product, judges each day against a fixed constitution, and files self-contained, replayable tickets where the home failed a genuine human need. The tickets drive a development loop in which an AI developer proposes fixes, independent checks and a human review gate them, and the same simulator grades the result again.
The load-bearing property of the design is not the simulator's realism but an administrative boundary: the grader lives in its own repository, a CI guard blocks any import of it into the product, and the developer's credentials cannot reach it. The system being graded cannot edit the thing that grades it. We describe the method, the verdict rule, the boundary, and the capabilities the loop has shipped to date, and we report its known limitations. We believe the pattern generalizes: it is a small organization of specialized AI systems arranged so that they hold one another accountable, with a human at the final gate.
1. The measurement gap
Software testing answers the question "does the system do what we specified?" For a home assistant, the question that matters is different: "did the home serve the people in it?" The two come apart constantly. A thermostat API can return 200 on every call while the household's stated preference is silently forgotten between conversations. A lighting system can pass its unit suite while a resident walks into a dark room the house knew was occupied. Nothing in a conventional pipeline is positioned to notice either failure, because nothing in a conventional pipeline experiences the product the way a resident does: continuously, across days, with needs rather than test cases.
The standard industrial answer is user research and telemetry. Both are valuable and both arrive late, after real residents have been failed, and telemetry in particular sits awkwardly with a privacy-first product that deliberately collects little. We wanted a source of resident-shaped failure signal that runs before and between real deployments, at simulation speed, without surveilling anyone.
2. Method: a simulated household against the shipped product
The simulator maintains a household of language-model personas with persistent traits, routines, moods, and needs across a simulated day: waking, leaving, returning, cooking, hosting a guest, falling ill, going to sleep. The personas interact with the real product exactly as residents would, through its public interfaces. The simulator holds no privileged access; from the product's point of view, a simulated day is indistinguishable from a household using the system.
Two design choices matter more than the personas' sophistication.
First, the simulator runs against the shipped product build, not a mock. A digital twin supplies the physical side (devices, rooms, sensor events, weather), but every decision the assistant makes is made by the shipped code path. Whatever the simulator discovers is therefore a property of the product, not of a test double.
Second, the simulator is a discovery engine rather than a regression suite. Its purpose is not to confirm that yesterday's features still work; it is to notice needs the product cannot serve yet. In practice the grader runs ahead of the product, which is the intended posture: it files tickets for capabilities that do not exist, and those tickets become the roadmap. Section 5 lists what this has produced.
3. The verdict rule
Free-running language models make poor referees on their own, so judgment is structured in layers.
The first layer is deterministic: assertions about world and product state that either hold or do not. Did the room the resident entered light up within the window? Does the thermostat setpoint match the standing preference? These checks are cheap, objective, and immune to persuasion.
Above them sits a judge panel: multiple language models, deliberately drawn from two independent vendors so that a single model family's blind spots do not become the system's blind spots. Each judge scores the day against a fixed, versioned constitution that defines what a home owes its residents in terms of comfort, convenience, information, security, and routine. The constitution is explicit about misbehavior it will not reward: an intervention that placates the simulated resident without serving the underlying need scores low. Goodhart's law is treated as a design constraint rather than a proverb.
A day produces a ticket only under a conservative rule: a deterministic assertion failed, or at least two judges independently flagged the same failure. Single-judge complaints are recorded but do not create work. The rule trades sensitivity for precision, deliberately: a discovery engine that files noisy tickets trains everyone to ignore it.
One verdict from the corpus illustrates the constitution's character. A fully local home, configured with egress disabled, declined a request that required internet access. An appeasement-oriented rubric would score the refusal as a failure to satisfy the resident. The constitution scores it as the product keeping its privacy promise, which is to say as the system working. Judging needs rather than sentiment is the difference between measuring service and measuring flattery.
4. The boundary
Any self-evaluation scheme invites one question: what stops the system from optimizing the evaluator instead of the home? The answer here is administrative rather than behavioral. The grader is not part of the product. It lives in a separate repository under separate access control. A CI guard fails the product build if product code imports from the grader, and the AI developer's credentials are scoped to the product repository alone. There is no code path, and no permission path, by which the thing being graded can modify the thing grading it.
The loop then runs as follows. The simulator lives its days and files tickets. An AI developer, operating in the product repository, picks up a ticket, reproduces the failure, and proposes a fix as an ordinary reviewed change. Independent gates check it: the conventional suite, contract checks, and a re-run of the failing scenario. A human reviews and merges. The deployed result is graded again by the same simulator, on the same scenario and on scenarios the developer never saw. Every merge in this loop passes a human gate; the system proposes, and people decide.
The boundary also disciplines the humans. Because the grader's verdicts are produced outside the product organization's control, an inconvenient verdict cannot be quietly edited away; it can only be argued with in the open, by changing the versioned constitution.
5. What the loop has produced
The clearest evidence for the method is the list of capabilities that exist because the simulator demanded them. Each entry below began as a filed ticket describing a resident need the product could not serve, and ended as a shipped capability re-graded by the same scenarios. Some are table stakes the loop simply ranked by severity; the first two are the kind of failure no written specification would have listed, and they carry most of the argument.
| Discovered need | Shipped capability |
|---|---|
| A stated preference had to be repeated every day | Standing preferences, remembered and enforced across days |
| A resident entered a dark, occupied room | Presence-driven lighting, on by default |
| Empty rooms stayed lit for hours | Vacancy switch-off, on by default |
| "Will it rain on the school run?" went unanswered | Live weather and forecasts from a public meteorological service |
| The home did not know the family's day | Read-only calendar integration over the standard subscription format |
| Residents asked for warmth; nothing changed | Thermostat and climate setpoint control |
The standing-preference case is worth narrating because it shows the loop end to end. The simulator's household included a resident who told the home, once, to keep the bedroom at 21 degrees. The next simulated evening the bedroom was cold, the resident asked again, and the judges flagged the day: the product had treated a standing preference as a one-shot command. The ticket reproduced the failure deterministically. The fix introduced durable preferences that the assistant consults and enforces without being re-asked, the change passed the gates and a human review, and the re-graded scenario went green, along with adjacent scenarios that check the preference survives across days and conversations. No human noticed this gap. A simulated household did, and the mechanism that noticed it could not be talked out of it.
6. Replayability
Every ticket is a self-contained artifact: the scenario, the household state, the recorded persona behavior, and the observed failure. Replays are deterministic down to the byte, because every source of variation in a recording run, including persona dynamics, is captured at record time and pinned. This has two consequences. A developer, human or AI, can re-experience the exact failure rather than an approximation of it. And a skeptic can re-run the evidence: a verdict is not a claim about what a model felt, it is a reproducible execution anyone with the artifact can repeat.
Determinism is also what makes the re-grade meaningful. When a fixed scenario goes green, it is green against the same day, the same household, and the same judges that failed it, so the delta measures the fix and nothing else.
7. An organization of accountable AIs
Stepping back, the system is best described as an organization, and four roles divide the power between them. The grader has product sense but writes no code. The developer writes code but cannot grade its own work. The judge panel is drawn from competing vendors and scored against a constitution that is versioned like law. A human owns every merge. Each role is strong in one dimension and deliberately powerless in another, and it is the arrangement, not any single component, that produces trustworthy behavior.
We find this framing more durable than "AI-assisted development." Assistance concentrates capability in one agent and hopes it behaves. An organization distributes capability across agents with opposed incentives and verifiable interfaces, which is the same trick institutions have always used with people. Nothing in the arrangement is specific to smart homes. Any product whose success is defined by lived outcomes rather than specifications could, in principle, be paired with a simulator of its users, a constitution for judging service, and a boundary that keeps the optimizer's hands off the measure.
8. Status and limitations
The loop described here is operational and has shipped the capabilities in Section 5 under human-gated merges. Several qualifications belong on the record.
Simulated residents are not people. The personas exercise the product across realistic routines, but they inherit the biases and blind spots of the models that animate them; the simulator finds many failures a specification misses, and it will still miss failures a real household would surface. The method complements contact with real residents; it does not replace it.
The judge panel is only as independent as its vendors' training pipelines. Two vendors is a floor, not a ceiling.
The evaluation set includes scenario classes withheld from the developer, so that fixes are graded partly on situations they were not written against. This held-out discipline is the youngest part of the pipeline and is still being hardened; we report it as a mechanism under construction rather than a settled guarantee.
Finally, the boundary is administrative. It prevents the product and its developer from editing the grader; it cannot prevent the humans who own both repositories from doing so. What it changes is the nature of that act: weakening the grader requires a deliberate, visible decision in a system designed to make such decisions loud.
References
- Park, J. S., O'Brien, J., Cai, C. J., Morris, M. R., Liang, P., and Bernstein, M. S. (2023). Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023.
- Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023.
- Amodei, D., Olah, C., Steinhardt, J., Christiano, P., Schulman, J., and Mané, D. (2016). Concrete Problems in AI Safety. arXiv:1606.06565.
- Strathern, M. (1997). "'Improving ratings': audit in the British University system." European Review, 5(3). Origin of the common phrasing of Goodhart's law: when a measure becomes a target, it ceases to be a good measure.