DWELL — Closed-Loop Living Design

DWELL started as a personal project to find my own neighborhood and the right place to live, and it optimizes for what living somewhere is actually like — not the asking price. The bet behind it is simple: if working through a home this way helps me decide, it can probably help other people facing the same decision.

Two ideas shape how it looks at a home. First, distance is measured in time, not kilometres — how long the commute really takes by public transit or by car, which is what you actually live with day to day. Second, it doesn't try to replace the listing sites that already do search well: you find a neighborhood, browse the real listings on those better platforms, and bring a specific one back here to analyze in depth. And because buildings differ by construction year, and every agent advertises everything as "good" while you can't abstractly tell what actually matters, the method is a checklist of concrete, livable questions instead of vague impressions — can a dishwasher even be installed (my current place effectively can't, so the one I owned had to go), how well it resists inter-floor noise, what a south- or north-facing unit actually feels like given its construction and surroundings, whether sunlight really reaches it. The point is to weigh all of that together, deliberately — and I expect it to sharpen as I get closer to actually choosing a place.

Under the hood, DWELL is a closed-loop optimizer over housing. For a given dwelling it keeps a metacognitive state — it knows what is known, how well it is known, what is missing that should exist, and what single action best closes a gap next. That is the whole thesis, and it is the part that is actually built.

• One queue, one currency. Knowledge-acquisition actions (buy a photo, run a solver) and design-mutation actions (move a wall, move a sofa) compete in a single priority queue, scored by expected decision-improvement per cost. When the shell is uncertain, buying knowledge wins; once provenance is high, mutating the design wins.
• The loop is the product. Physics solvers, data adapters and the UI are plug-ins behind it. State is (K, I, S) — Knowledge, Interior, Shell — with three closure modes over it: EVAL (acquire until the decision is safe) works end to end; INTERIOR (placement) ships a v0 solver; DESIGN (the envelope) has its mode and invariant enforced but no mutation engine yet.
• Provenance is the spine. Every value carries a badge on a ladder — MEASURED > DECLARED > DERIVED > CODE_INFERRED > ARCHETYPE > UNKNOWN — and names its weakest link. UNKNOWN renders as unknown, never a defaulted number. Honest unknowns are a feature no competitor shows.

The argument in one move: on a guessed (ARCHETYPE) shell the fridge appears to "fit" — and the loop knows it does not know that, so it declines to trade on it and buys the floor plan instead. On the traced shell the same solver says it misses the kitchen door by 130 mm. The gap does not close; it changes type, from "I don't know" to "it doesn't fit" — a different sentence to say to a buyer.

What exists today (covered by 542 tests): the Phase-0 loop skeleton, five oracles (sun geometry via pvlib, clearance/fit, code-year envelope, cross-ventilation topology, a heating conductive-load lower bound), the flywheel both ways (evidence in → ledger delta out, and a browser plan-trace editor), the 건축물대장 registry adapter wired end to end, and a suite-SSO-gated web app. Not yet: V-World/기상청 live adapters, AI pre-trace, the national calibration harness (so every confidence is an engineering prior, not measured calibration), the SOUND/LIFE/cooling oracles, multi-object placement, and DESIGN-mode mutation. The README draws that line precisely, on purpose.

제가 살 동네와 이상적인 주거 공간을 직접 찾으려고 시작한 개인 프로젝트입니다. 부동산 가격이 아니라 실제로 살 때의 실용성을 목표로 만들었고, 이걸로 제가 도움을 받는다면 같은 고민을 하는 다른 사람에게도 도움이 될 수 있지 않을까 하는 마음에서 출발했습니다.

접근에는 두 가지 생각이 깔려 있습니다. 첫째, 거리를 물리적 거리가 아니라 대중교통·자차 이동에 걸리는 시간적 거리로 봅니다. 매일 실제로 감당하는 것은 그 시간이기 때문입니다. 둘째, 이미 검색이 잘 되어 있는 매물 플랫폼을 대체하려 하지 않습니다. 동네를 찾고, 더 잘 되어 있는 그 플랫폼에서 실제 매물을 탐색한 뒤, 특정 매물을 여기로 가져와 상세하게 다시 분석합니다. 연식마다 건축 형식과 내용이 다르고, 부동산은 모두 좋다고 광고하는데 정작 무엇이 왜 좋고 중요한지 추상적으로는 알기 어렵기 때문에 체크리스트 방식으로 접근합니다. 예를 들어 식기세척기를 설치할 수 있는지(지금 사는 곳은 설치가 거의 불가능해서 쓰던 식기세척기를 처분해야 했습니다), 층간소음에 강한지 약한지, 건축 방식과 주변 환경에 따라 남향·북향이 실제로 어떤 느낌인지, 주변 때문에 해가 실제로 드는지 같은 구체적이고 생활에 밀착된 질문들입니다. 이 모든 것을 종합적으로 함께 검토하고 싶어서 만들었고, 제가 구할 집에 가까워질수록 더 정교해질 프로젝트입니다.

그 아래에서, DWELL은 주거를 대상으로 하는 닫힌 루프 최적화기입니다. 한 집에 대해 무엇을 아는지, 얼마나 잘 아는지, 있어야 하는데 없는 것은 무엇인지, 다음에 어떤 단 하나의 행동이 그 간극을 가장 잘 메우는지를 늘 알고 있습니다. 지식을 얻는 행동(사진 한 장 구매, 솔버 실행)과 설계를 바꾸는 행동(벽 옮기기, 소파 옮기기)이 하나의 우선순위 큐에서 "비용당 기대 의사결정 개선"이라는 단일 통화로 경쟁합니다. 셸이 불확실하면 지식 구매가 이기고, 프로버넌스가 높아지면 설계 변경이 이깁니다. 루프가 곧 제품이고 솔버·데이터 어댑터·UI는 그 뒤의 플러그인입니다. 모든 값은 MEASURED > DECLARED > DERIVED > CODE_INFERRED > ARCHETYPE > UNKNOWN 사다리 위의 배지와 최약 링크를 달고 나오며, 모르는 값은 지어낸 숫자가 아니라 UNKNOWN으로 표시됩니다.

핵심 논증은 한 장면입니다. 추정(ARCHETYPE) 셸에서는 냉장고가 "들어가는" 것처럼 보이지만, 루프는 자신이 그것을 모른다는 사실을 알기에 그 값으로 거래하길 거부하고 평면도를 먼저 삽니다. 트레이스된 셸에서는 같은 솔버가 주방 문을 130mm 차이로 통과하지 못한다고 말합니다. 간극은 닫히지 않고 성격이 바뀝니다. "모른다"에서 "안 맞는다"로. 지금 있는 것은 Phase 0 루프 골격, 다섯 개의 오라클, 양방향 플라이휠, 건축물대장 어댑터, suite SSO로 보호된 웹 앱이며 542개 테스트가 이를 덮습니다. 아직 없는 것은 V-World·기상청 실시간 어댑터, AI 사전 트레이스, 전국 보정 하네스(그래서 모든 신뢰도는 측정된 보정이 아니라 공학적 사전값입니다), SOUND·LIFE·냉방 오라클, 다중 객체 배치, DESIGN 모드 변형 엔진입니다. README가 그 경계를 의도적으로 정확히 긋습니다.

Live / 바로가기: dwell.simplicity-is-art.com · Status / 상태: Beta (베타) · Principle / 원칙: the loop is the product · no naked numbers

Explore the project · 프로젝트 자세히 →