Product line 03

A model you can walk through is only as good as what it was built from.

Rendering is easy. Rendering something that survives a question about where each surface came from is not. Our twins carry provenance in the model itself: select any element and it resolves to the sealed record — the scan, the capture, the telemetry stream, the drawing — that produced it, with the digest to prove the record has not moved since.

Why provenance-bound

Visualisation that cannot quietly invent.

Every reconstruction pipeline interpolates. Photogrammetry fills gaps, meshes get decimated, textures get inferred, missing geometry gets estimated. None of that is dishonest — but by the time it reaches a screen, a measured surface and a guessed one look identical.

So we make the model say which is which. Elements are tagged at construction time with their derivation: measured, derived or inferred, each resolving to the source artefact and its digest. A viewer can filter to measured-only geometry and see exactly how much of the reconstruction is load-bearing.

If you cannot say which parts of the model are evidence and which are inference, the whole model is inference.

MEASURED DERIVED INFERRED ELEMENT → SOURCE RECORD derivation measured · laser scan pass 03 sealed sha256 342b0a42…5d56a269 custody seq 0147 → anchored ✓ inclusion proof valid

Fig. 06 — provenance-bound geometry

Twin classes

Four things worth twinning.

Different sources, different physics, one model layer and one provenance rule.

Scene & incident twins

A location reconstructed from laser scan, photogrammetry, body-worn and fixed camera capture, and measured survey. Navigable at true scale, measurable between any two points, and scrubbable along a timeline assembled from the timestamps in the underlying records.

  • Line-of-sight and visibility analysis from any position
  • Placement of exhibits at their recorded coordinates
  • Timeline reconstruction across multiple capture sources
  • Every surface resolvable to its sealed source

Network twins

The topology of an optical access network as a live model — terminals, splitters, feeder and distribution fibre, and the line terminal — with per-node state pulled from the management plane. Useful for planning a build, and considerably more useful for explaining why a segment is degrading.

  • Optical budget and split-ratio visualisation along a path
  • Fault localisation rendered against the physical route
  • Terminal fleet state from the remote management agent
  • Capacity and upgrade modelling before trenching

Facility & asset twins

Buildings, plant rooms, racks and cabinets modelled from reality capture and drawings, with condition and sensor data bound in. The value is not the render — it is that the render is tied to a dated, sealed record of what was actually there.

  • As-built versus as-designed difference, made visible
  • Dated condition snapshots that can be compared
  • Sensor and telemetry overlay with source attribution
  • Change history as an append-only record

Training & rehearsal twins

Reconstructed environments used as practice ground — walking an examiner through a scene before they attend it, or a field engineer through a cabinet before they open it. Built from the same models, so training matches the real asset rather than an artist’s impression of it.

  • Guided procedure walkthroughs at true scale
  • Scenario branching with recorded trainee decisions
  • Assessment against a defined procedure
  • Shared sessions with multiple participants

Pipeline

Capture to walkthrough.

The chain is deliberately the same shape as the evidence pipeline, because it is the same problem: something enters, gets transformed several times, and has to remain accountable to what it started as.

  1. Capture and seal

    Scans, imagery, survey data, drawings and telemetry are sealed at intake exactly as digital forensics evidence is — digested, encrypted, and written into the custody chain before any processing touches them.

  2. Register and align

    Sources are brought into a common coordinate frame and time base. Registration parameters are themselves recorded, so the transform applied to any source can be inspected and reproduced later.

  3. Reconstruct and tag

    Geometry is built and each element tagged with its derivation class and the identifier of the source records behind it. Interpolated regions are marked as interpolated at the moment they are created, not annotated afterwards.

  4. Bind live state

    Where a twin represents something operating, current state is bound in from the management or sensor plane and clearly distinguished from the static reconstruction it is drawn over.

  5. Publish and review

    The twin is published to a browser viewer that needs no installation, and to headset review for the cases where true-scale presence genuinely changes what a reviewer notices. Both surfaces expose the same provenance panel.

Delivery surfaces

Immersive where it earns its cost.

Headsets are excellent for spatial judgement and poor for reading text. We use each surface for what it is good at rather than putting everything behind a visor.

Browser viewer

The default. Runs on the machine the reviewer already has, shares by link with scoped access, and carries the full provenance panel, measurement tools and timeline. No installation, no specialist hardware.

Headset review

True-scale walkthrough for spatial questions — sightlines, reach, clearance, position — where the answer is different when you are standing in it. Sessions can be shared and recorded as a reviewable path.

Exhibit export

Fixed viewpoints, measured sections, annotated stills and camera paths exported as court-presentable material, each carrying the digest of the twin build it came from so the exhibit is tied to a specific model version.

Interoperability
StageAccepted / produced
Reality capturePoint clouds and structured scan output; photogrammetric image sets with camera metadata; measured survey.
Geometry exchangeStandard scene-description and mesh interchange formats, so a twin can be taken into an existing engineering or visualisation toolchain rather than trapped in ours.
Live stateManagement-plane telemetry from network elements; sensor and time-series feeds; structured log and event streams.
ProvenancePer-element source references resolving into the evidence ledger, with digests and inclusion proofs retained on export.

Have something worth reconstructing?

Tell us what the model has to answer and what will be argued about afterwards. That second part usually determines the build.