Etogo Twin Engine
Budget: $2,000 – $3,000 CAD
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.
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.