Etogo Twin Engine

ETOGO Property Twin Engine™ — Developer Brief Product objective Build one shared Property Twin Engine that converts property scans, plans, inspection evidence, records and live sensor data into a true-to-life, navigable, interactive and time-aware representation of an entire property. The 3D model is only the spatial container. The actual product is the governed relationship between: Property → Building → Floor → Unit/Common Area → Space → Zone → System → Sub-System → Component → Finding → Evidence → Deliverable → Work Order → Verified Property Fact → Stewardship Record The Engine must preserve and show how a property changes over time. Product configuration The Engine must support two operating modules using the same database, APIs, ontology, evidence chain and registry. 1. Individual Property Module For detached homes, duplexes, townhouses, farms, acreages and small commercial properties. Primary spatial hierarchy: Property → Building → Floor → Space → Zone This module must support multiple physical storeys. “Individual Property” does not mean single-storey. The interface should emphasize: Whole-property walkthrough Interior and exterior spaces Systems and components Findings and evidence Remediation and verification Building versions Sensors and alarms Continuing stewardship 2. Multi-Unit & Multi-Storey Module For apartments, strata buildings, high-rises, hotels, hospitals, schools, mixed-use developments and large institutional or commercial properties. Primary spatial hierarchy: Property → Building → Floor → Unit/Common Area → Space → Zone This module adds: Master Property Twin Building, Floor and Unit Twins Common-Area Twins Vertical-system mapping Progressive model loading Multi-party governance Role-based privacy Building-wide alarms Cascading Findings Floor-, unit- and system-level versions Building command dashboard The two modules must not become separate products or separate data systems. High-rise scalability requirement The architecture must support a building containing at least: 56 floors 100 residential units per floor 5,600 Unit Twins Hallways Staircases and floor-to-floor segments Passenger and service elevator landings Utility and restricted rooms Vertical risers and shafts Shared building systems Every unit and common space must have a permanent ID. The viewer must never load the complete high-rise model at full detail. It must use progressive loading, spatial tiling, caching and levels of detail. Typical loading behaviour: Open property: load site and low-detail building exterior. Select building: load building structure and summary information. Select floor: load only that floor and its operational records. Select unit: load the detailed Unit Twin. Select common area: load only the selected hallway, landing, staircase segment or utility room. Select vertical system: load its route across applicable floors. Select evidence: load detailed scanner data only for the relevant location. Required input formats The ingestion layer should support: Matterport E57 and MatterPak exports LAS/LAZ PLY OBJ GLB/glTF Panoramic images Standard photographs and video IFC Floor plans PDF and DWG-derived drawings Wall-scanner data and images Sensor and device telemetry Original source files must be preserved unchanged with checksums, device metadata, ownership, licensing and capture provenance. Viewer requirements The browser and mobile viewer must provide: Walkthrough navigation Orbit and zoom Plan view Dollhouse view Measurements Floor isolation Object and layer hide/show Cross-sections and clipping planes Saved viewpoints Before-and-after comparison Building-version timeline Finding and evidence filters System and spatial navigation trees The user opens a Property Twin Session inside ETOGO—not a standalone 3D file. Two coordinated maps Spatial Map Answers: Where does it exist? Property → Building → Floor → Unit/Common Area → Space → Zone Systems Map Answers: What property function does it belong to? Property → System → Sub-System → Component Every Finding, Evidence item, Qualified Deliverable and Verified Property Fact must connect to: A spatial location; A system location; or Both. Do not use “Asset” as a hierarchy level below Sub-System. Spatial anchors A Spatial Anchor may represent: A point A surface A bounded region A linear path A saved camera viewpoint Each anchor must store: Coordinates Coordinate reference Building Version Camera position and direction Selected geometry Space ID System/Sub-System/Component IDs Confidence Source and provenance Anchors must never silently move when geometry changes. Permitted version-mapping actions are: Preserve Relocate Split Merge Retire Every action requires a reviewed Registry Event.

Project ID: 40605656