OpenHOUSE: Multi-Domain Systems Framework

• OpenHOUSE is a polysemous term that spans residential 3D generation, hierarchical video understanding, and lakehouse control, each relying on structured representation and staged processing.
• In residential AI, OpenHOUSE pipelines decompose language into room graphs and 2D spatial primitives, achieving superior IoU and FID scores compared to alternative methods.
• In streaming and data systems, OpenHOUSE employs hierarchical detection and fleet-scale governance to enhance real-time event segmentation and optimize file compaction.

Searching arXiv for the provided OpenHOUSE-related papers and nearby context. OpenHOUSE is a polysemous term in recent technical literature. In spatial AI and generative design, it denotes an open, extensible stack for automatic 3D house generation, floor-plan ingestion, simulation, and benchmarking, described through integrations and OpenHOUSE-style pipelines around HPGM, ResPlan, AnyHome, and CHOrD (Chen et al., 2020, Abouagour et al., 19 Aug 2025, Fu et al., 2023, Su et al., 15 Mar 2025). In streaming video understanding, “OpenHOUSE” specifically abbreviates “Open-ended Hierarchical Online Understanding System for Events” and names a hierarchy-aware online localization-and-description framework (Kang et al., 15 Sep 2025). In data infrastructure, “OpenHouse” designates a control plane for catalog management, schema governance, metadata maintenance, and data services that hosts AutoComp in a multi-tenant lakehouse (Gruenheid et al., 5 Apr 2025). This suggests that the term functions less as a single standardized artifact than as a recurrent label for open, system-level orchestration in distinct research domains.

1. Terminological range and research uses

The literature uses the name in several technically separate ways.

Usage	Domain	Defining characteristics
OpenHOUSE-style residential platform	Spatial AI and 3D home generation	Text-to-layout, floor-plan parsing, 2D-to-3D conversion, simulation export
OpenHOUSE (Open-ended Hierarchical Online Understanding System for Events)	Streaming video understanding	Strict online localization with free-form hierarchical descriptions
OpenHouse control plane	Data lakes and lakehouse operations	Declarative catalog, schema governance, metadata maintenance, compaction services

In the residential literature, OpenHOUSE is often described indirectly: ResPlan is presented as aligning well with an OpenHOUSE-style platform, AnyHome is described as designed for OpenHOUSE, and CHOrD is framed as an overview targeted to an OpenHOUSE-style system. By contrast, the HSVU paper introduces OpenHOUSE as a named method with a fixed acronym, while the AutoComp paper refers to OpenHouse as an already deployed operational control plane (Abouagour et al., 19 Aug 2025, Fu et al., 2023, Su et al., 15 Mar 2025, Kang et al., 15 Sep 2025, Gruenheid et al., 5 Apr 2025).

A common misconception is to treat all occurrences as references to one unified software stack. The published record does not support that reading. Instead, the same label is attached to at least three different classes of artifact: a residential scene-generation ecosystem, a streaming perception model, and a lakehouse control plane. A plausible implication is that “OpenHOUSE” has become a convenient systems-oriented name rather than a uniquely identified platform.

2. Residential generation and simulation pipelines

Within the residential-generation usage, the most explicit end-to-end blueprint is the House Plan Generative Model introduced in “Intelligent Home 3D: Automatic 3D-House Design from Linguistic Descriptions Only.” The task is formulated as language-conditioned visual content generation and split into floor plan generation and interior texture synthesis. Text is parsed into a structural graph with node features $X \in \mathbb{R}^{N \times D}$, adjacency $A \in \mathbb{R}^{N \times N}$, and texture attributes $V \in \mathbb{R}^{2N \times M}$. A two-layer GCN-based GC-LPN predicts room bounding boxes $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$, trained with the layout loss $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$. Post-processing converts coarse boxes into polygons, merges segments, assigns polygons to rooms with the weight function $W_{ij}$, and inserts doors and windows by rules; LCT-GAN then generates floor and wall textures conditioned on material and color, after which walls are extruded and rendered with Intel Embree. The same source also gives a suggested OpenHOUSE API surface comprising POST /parse_text, POST /predict_layout, POST /postprocess_floorplan, POST /generate_textures, POST /build_3d, and GET /render (Chen et al., 2020).

This pipeline is notable for its decomposition. Language is not mapped directly to mesh geometry; instead, it is first normalized into a room graph, then into 2D spatial primitives, then into textured 3D geometry. That staged design recurs in later OpenHOUSE-style systems. The paper’s evaluation also fixes concrete reference points for this line of work: GC-LPN reaches bounding-box IoU 0.8348, surpassing MLG at 0.7208, C-LPN at 0.8037, and RC-LPN at 0.7918, while LCT-GAN achieves FID 119.33/145.16 on train/test and MS-SSIM 0.3944/0.3859, outperforming ACGAN, StackGAN-v2, and PSGAN under the reported protocol. The generated 3D houses use wall height 2.85 m, interior wall thickness 120 mm, exterior wall thickness 240 mm, doors of length 900 mm and height 2000 mm, and windows with length equal to 30% of the chosen wall segment. The underlying Text-to-3D House Model dataset contains 2,000 houses, 13,478 rooms, 873 texture images, and natural-language descriptions with average length 173.73 words and vocabulary size 193 (Chen et al., 2020).

The limitations reported there are structurally important. Descriptions originate from templates and are only later refined by human workers; scene graph parsing errors can propagate into layout errors; bounding boxes are coarse; door and window placement is rule-based; and furniture placement is not modeled. In later OpenHOUSE-adjacent work, many architectural choices can be read as responses to those constraints.

3. Structural data substrates and benchmark design

ResPlan provides the clearest dataset-oriented substrate for an OpenHOUSE-style spatial platform. It is a large-scale, simulation-ready dataset of 17,000 realistic residential floor plans curated from real estate listings and delivered in dual geometric and topological representations. Geometry is stored per plan as a single JSON-serializable dictionary keyed by semantic categories such as "bedroom", "bathroom", "kitchen", "living", "balcony", "wall", "door", "window", "neighbor", "inner", "garden", and "front_door", with values given as Polygon or MultiPolygon objects in plan-view coordinates. A uniform wall thickness is enforced and recorded once per plan in "wall_depth" in meters. The graph representation is formalized as $G = (V,E)$, where nodes carry semantic label, polygon centroid, and area, while edges are typed as door, arch, or shared-wall. The per-type adjacency matrices $A^{(t)} \in \{0,1\}^{|V|\times|V|}$, the untyped adjacency $A = A^{(door)} \lor A^{(arch)} \lor A^{(shared)}$, the shortest-path distance $d(i,j)$ over $A \in \mathbb{R}^{N \times N}$0, and the typed degree $A \in \mathbb{R}^{N \times N}$1 are explicitly defined for downstream planning, reasoning, and benchmark construction (Abouagour et al., 19 Aug 2025).

ResPlan’s value for OpenHOUSE-like systems lies in what is already resolved before training or simulation begins. The dataset normalizes source nomenclature, distinguishes interior, exterior, and neighbor walls, includes inner and optional garden polygons, exposes a unique front_door, and provides unit-level rather than multi-unit floor plates. The bedroom-count distribution—1,802 one-bedroom, 8,507 two-bedroom, 6,153 three-bedroom, 616 four-bedroom, and 29 five-plus-bedroom units—is reported as evidence of structural diversity, especially for rare larger units. The open-source pipeline cleans and aligns geometry, merges colinear walls, corrects gaps and overlaps, removes duplicates and slivers, enforces coplanarity across wall, door, and window layers, refines labels, identifies party walls, verifies door placement and connectivity, and emits both per-plan JSON and a room connectivity graph as JSON or NetworkX. The paper contrasts this directly with RPLAN, which offers 80,788 raster images at $A \in \mathbb{R}^{N \times N}$2 without vector-native geometry or graph connectivity, and with MSD, which includes vector and graph formats but releases multi-unit floor plates requiring additional extraction and reconstruction steps (Abouagour et al., 19 Aug 2025).

The dataset is also unusually explicit about OpenHOUSE integration. Recommended 2.5D-to-3D conversion uses wall thickness equal to wall_depth, wall height approximately 3.0 m, floor and ceiling meshes derived from the inner polygon, and subtraction of door and window polygons from extruded wall meshes. Engine-specific guidance is given for Unity, Unreal, Habitat, and Isaac Sim. For RL, the room graph is cast as an MDP $A \in \mathbb{R}^{N \times N}$3 with states given by nodes augmented by agent pose and door states, actions including motion over door or arch edges and door actuation, and transitions derived from the navigable adjacency. Proposed benchmarks include multi-room navigation from front_door, connectivity-aware planning, graph-to-geometry generation, and plan-to-graph extraction, with metrics including IoU, edge precision/recall, graph edit distance, accuracy, and F1. In this sense, ResPlan is not itself OpenHOUSE, but it operationalizes the data layer that such a platform would require (Abouagour et al., 19 Aug 2025).

4. House-scale scene synthesis and digital twins

AnyHome and CHOrD extend the OpenHOUSE-style residential stack from floor plans and room boxes to full house-scale digital twins. AnyHome translates free-form text into an amodal structured representation composed of a floorplan bubble diagram $A \in \mathbb{R}^{N \times N}$4, room-level constrained layout graphs $A \in \mathbb{R}^{N \times N}$5, Semantic Asset Groups with anchors, placement rules, and per-view appearance prompts. It uses GPT-4-1106-preview with JSON outputs and normalized metric quantities, maps unconventional room types to the HouseGAN++ domain, generates floorplan masks with HouseGAN++, fills rooms by rule-based placement under occupancy-mask constraints, retrieves meshes from 3DFuture and Objaverse via CLIP and Sentence-BERT, refines placements by Score Distillation Sampling over multi-view normal maps and masks, and performs depth-conditioned multi-view inpainting with MVDiffusion followed by differentiable back-projection into vertex colors. Quantitatively, AnyHome reduces Out-of-Bound rate from 69.4 for LayoutGPT+Retrieval and 34.2 for CG+Retrieval or CG+Inpainting to 23.7, while improving Caption-sim to $A \in \mathbb{R}^{N \times N}$6 and CLIP-sim to $A \in \mathbb{R}^{N \times N}$7; under a top-down GPT-4V evaluation against Holodeck, it improves Prompt-Align from 7.8 to 9.0, Layout from 6.1 to 8.7, Object from 4.3 to 7.8, and Overall from 6.0 to 7.8 (Fu et al., 2023).

CHOrD addresses a different bottleneck: collision-free and organized house-scale scene synthesis under controllable floor plans. Instead of generating object lists directly, it first synthesizes a 2D top-down layout image $A \in \mathbb{R}^{N \times N}$8 conditioned on floor plan $A \in \mathbb{R}^{N \times N}$9 with a conditional DDPM trained by the denoising loss $V \in \mathbb{R}^{2N \times M}$0. It then runs YOLOv8 on the generated layout image to detect objects and segment rooms, assembles a hierarchical scene graph House $V \in \mathbb{R}^{2N \times M}$1 Rooms $V \in \mathbb{R}^{2N \times M}$2 Object groups $V \in \mathbb{R}^{2N \times M}$3 Objects, retrieves CAD assets by per-category size matching, and renders the result in Unreal Engine. A central claim is that collision artifacts become out-of-distribution in the 2D layout space; the paper reports approximately 32% higher loss on the most colliding 400 samples versus clean ones. The accompanying CHOrD dataset contains 9,706 houses, expands coverage to 26 super-categories across living rooms, bedrooms, dining rooms, kitchens, bathrooms, and balconies, and reports lower artifact statistics than 3D-FRONT, including POR 0.0044 versus 0.0361 and PIoU 0.0018 versus 0.2547. On entire-house evaluation, CHOrD reports FID 11.51 and KID 0.010 on 3D-FRONT, and FID 29.97 and KID 0.039 on its own dataset, with entire-house POR 0.0130 and 0.0125 respectively (Su et al., 15 Mar 2025).

These two systems embody different but compatible OpenHOUSE interpretations. AnyHome preserves an amodal, editable symbolic structure and uses SDS plus egocentric inpainting to reach realistic textured geometry. CHOrD treats the 2D layout raster as the authoritative intermediate and pushes collision avoidance into the generative prior itself. Together they indicate that house-scale OpenHOUSE pipelines have converged on strong intermediate representations rather than direct text-to-mesh generation.

5. OpenHOUSE as hierarchical streaming video understanding

A separate line of work introduces OpenHOUSE as “Open-ended Hierarchical Online Understanding System for Events.” Here the input is a continuous video stream $V \in \mathbb{R}^{2N \times M}$4, and the output is a sequence of hierarchical action instances $V \in \mathbb{R}^{2N \times M}$5 with $V \in \mathbb{R}^{2N \times M}$6, where $V \in \mathbb{R}^{2N \times M}$7 indexes substep, step, or goal. The system is strictly online: no future frames may be used, and when an ongoing instance ends at time $V \in \mathbb{R}^{2N \times M}$8, the system must emit $V \in \mathbb{R}^{2N \times M}$9 immediately. OpenHOUSE decomposes this task into a lightweight streaming module, a context memory, and a frozen VLM. The streaming module is an RNN with three recurrent layers and hidden size 768, with a state-emitting head plus progression heads for steps and substeps. Starts are detected from background-to-action transitions, while ends are detected by progress drops $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$0. Training uses $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$1, $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$2, and $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$3 with the total objective $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$4; description generation is delegated to a frozen VLM such as InternVL2-40B-AWQ, called only at detected boundaries (Kang et al., 15 Sep 2025).

This architecture is motivated by a specific failure mode: successive actions in procedural videos often occur without background frames between them. Pure actionness-based grouping merges adjacent actions into single overlong events. The hybrid boundary detector is therefore the key technical contribution. The paper reports that it nearly doubles F1 over actionness-only grouping: on Ego4D-GoalStep, step F1 (loc.) rises from 16.78 to 39.35 and substep F1 (loc.) from 22.48 to 44.79; on Ego-Exo4D, substep F1 rises from 8.42 to 52.20; on Epic-Kitchens-100, substep F1 rises from 31.46 to 48.95. In full-system evaluation on Ego4D-GoalStep, OpenHOUSE reaches step F1 (loc.) 51.58/39.70/24.76 at temporal IoU thresholds 0.3/0.5/0.7, substep F1 (loc.) 55.17/43.71/28.83, step F1 (loc.+desc.) 15.23/12.67/8.68, and goal accuracy 47.76%. On a 46-minute video at 16 fps, using 4×RTX 3090 and InternVL2-40B-AWQ, the system runs at 24 fps, approximately 16× faster than invoking the VLM on every frame. Latency is also sharply reduced: AEDT on EgoGS is 4.94 s for steps and 1.82 s for substeps, versus 36.36/43.95 s or 64.84/52.64 s for interval-based SDVC baselines (Kang et al., 15 Sep 2025).

Although semantically unrelated to housing, this OpenHOUSE shares several systems properties with the residential literature: strict decomposition of lightweight online perception and expensive generative modules, explicit hierarchical state, and sparse calls to a large model only when a boundary or control decision warrants it.

6. OpenHouse as a lakehouse control plane

In the AutoComp literature, OpenHouse is an operational control plane used at LinkedIn to manage log-structured tables and host automatic compaction. Its scope includes a declarative catalog for table definitions, schema governance, metadata maintenance, and data services that reconcile observed and desired states. The motivating study reports that OpenHouse managed 21K Iceberg tables at the time of the initial analysis, 35K in production during AutoComp deployment, and projected growth to 100K. AutoComp is integrated with OpenHouse through an Observe–Orient–Decide–Act loop: candidate tables, partitions, or snapshots are enumerated and filtered; traits such as estimated file-count reduction $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$5 and compute cost $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$6 are computed; normalized traits are combined into a scalarized score $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$7; and Spark-based compaction jobs are scheduled subject to guardrails, quotas, and budget constraints. In production, quota-aware weighting uses $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$8. The paper evaluates OpenHouse v0.5.131 on AKS with Spark 3.1.1, Iceberg 1.2.0, and ADLS Gen2, using periodic compaction in pull mode and also noting compatibility with push optimize-after-write hooks (Gruenheid et al., 5 Apr 2025).

The control-plane perspective is central. Compaction is not treated as a per-table background optimization but as a fleet-scale governance problem involving HDFS namespace quotas, NameNode pressure, RPC amplification, read timeouts, and cost ceilings. The paper reports that before systematic compaction, 83% of files in OpenHouse were smaller than 128 MB, and manual compaction reduced this to 62%. With AutoComp integrated into OpenHouse’s decision mechanism, production achieved up to 44% reduction in the number of files smaller than 128 MB. In a production transition analysis, AutoComp top-10 reduced 7.44 million files per iteration versus 6.59 million for manual top-100, described as a 12% improvement while compacting 10× fewer tables per iteration. Under a budget of 226 TBhrs per iteration, dynamic selection compacted around 2,500 tables per run. Synthetic experiments further showed that without compaction file count increased by approximately 2,640 files per hour on average and the workload exceeded the five-hour envelope by about 25 minutes, whereas AutoComp reduced query runtimes after the first hour and narrowed variability. The paper also documents format-specific conflict behavior: table-scope aggressive compaction increased client-side and cluster-side conflicts early in the run, while Hybrid-500 showed no cluster-side conflicts, motivating sequential partition compaction within a table and parallelism only across tables (Gruenheid et al., 5 Apr 2025).

In this usage, OpenHouse is neither a generator nor a benchmark. It is a control plane whose importance lies in centralized policy enforcement, deterministic decisioning, and budget-aware actuation across a large multi-tenant estate.

7. Recurring design patterns, misconceptions, and limitations

Across these disparate meanings, several design motifs recur. One is reliance on structured intermediates: HPGM uses text-derived room graphs and bounding boxes, ResPlan uses vector polygons plus typed room graphs, AnyHome uses bubble diagrams and room constrained layout graphs, CHOrD uses a 2D layout image, streaming OpenHOUSE uses hierarchical temporal segments, and lakehouse OpenHouse uses normalized traits and ranked candidates. Another is decoupling a lightweight systems layer from an expensive reasoning or generation layer: GC-LPN precedes texture GANs, OpenHOUSE’s streaming module precedes frozen VLM calls, and AutoComp’s ranking precedes Spark rewrite execution. A third is explicit hierarchy, whether in house $$\hat{b}_i = (\hat{x}_0,\hat{y}_0,\hat{x}_1,\hat{y}_1)$$9 rooms $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$0 object groups $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$1 objects, substeps $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$2 steps $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$3 goal, or fleet $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$4 table $$\mathcal{L}_B = \frac{1}{N}\sum_{i=1}^{N}\| \hat{\mathbf{b}}_i - \mathbf{b}_i \|_2^2$$5 partition. These parallels do not make the systems identical, but they indicate a shared preference for controllable intermediate state over monolithic end-to-end generation (Chen et al., 2020, Fu et al., 2023, Su et al., 15 Mar 2025, Kang et al., 15 Sep 2025, Gruenheid et al., 5 Apr 2025).

The major misconceptions are correspondingly simple. OpenHOUSE is not a single universally fixed software package; not every OpenHOUSE is about residential geometry; and several papers refer to an “OpenHOUSE-style” platform without claiming to define the canonical implementation. There is also a broader benchmark-oriented usage in embodied AI: OpenHEART explicitly argues that its SAFE and ArtIEst framework for opening articulated household objects satisfies key requirements for a household opening benchmark such as “OpenHOUSE,” which indicates that the term also circulates as a prospective benchmark name in manipulation research (Lim et al., 6 Mar 2026).

The limitations attached to the various usages are domain-specific. Residential generation systems still face ambiguity in natural-language parsing, coarse layout parameterizations, multi-view texture inconsistency, detector-induced placement error, and weak support for multi-floor structures or rare long-tail objects (Chen et al., 2020, Fu et al., 2023, Su et al., 15 Mar 2025). ResPlan is single-floor, does not annotate furniture or appliance geometry, and relies on implicit 3D defaults beyond wall depth (Abouagour et al., 19 Aug 2025). Streaming OpenHOUSE still finds overlapping or simultaneous actions across hierarchies challenging, and very long dependencies remain difficult under bounded memory (Kang et al., 15 Sep 2025). The lakehouse OpenHouse must handle unexpected transaction conflicts, imperfect cost-benefit estimates, and changing multi-objective trade-offs across tenants and workloads (Gruenheid et al., 5 Apr 2025).

Taken together, these literatures define OpenHOUSE less as a singular artifact than as a family of open, system-level abstractions centered on structured representation, orchestration, and scalable actuation. In residential AI that family currently spans text-to-layout generation, vector-graph datasets, digital twins, and simulation benchmarks; in video understanding it denotes a strict online hierarchical localization-and-description architecture; and in data systems it names a fleet-scale governance plane for table maintenance.