Products / ForgeGIS / Digital Twin
Shipped in 1.2.3
ForgeGIS · Digital Twin

Streams like video.
Auditable like a ledger.

A living geospatial simulation that records itself as it runs.

You define a scenario once — the terrain, the physics, the inputs that change over time — and the engine advances it step by step on the GPU. Every change it computes is written down as it happens, so the run you watch live is a file you can replay, branch, and prove long after it finishes.

See it run What you can rely on
1 file
A finished run is a standard GeoPackage. Its presentation snapshots open directly in QGIS with no ForgeGIS™ software installed at all.
5 contracts
Recording, ledger, orchestration, wire and co-residency — frozen additive-only and pinned externally by the validation suite
1 shared past
A what-if branch inherits its parent's history byte-for-byte instead of duplicating it, and diverges only after the fork point

What a digital twin gives you

Three capabilities come for free, because they all read from the same recorded truth rather than a separate export — and a fourth because that truth is written in a format you already own.

Replay

Scrub it like video

Move frame-by-frame through a finished run, or stream it to a remote viewer that cannot tell replay from live. The past is always reconstructable, exactly.

Fork

Branch it into a what-if

Branch the run at any saved point into a what-if timeline. The branch shares its ancestor's history byte-for-byte and only diverges forward — so comparisons are honest.

Audit

Prove what you were shown

Recompute the checkpoints and confirm that what the viewer showed is exactly what the engine computed. The recording verifies against itself, on demand.

Open anywhere

No reader of ours required

The recording is a published format, not a private one. Hand a finished run to a reviewer who has never installed anything of ours, and the GIS tools they already have will open it.

The life of a twin run

From a locked definition to a file that can be replayed, branched, and proven — the recording is written as the run happens, not exported afterward.

The lifecycle of a digital twin run Registration locks a twin's identity. The run then advances epoch by epoch, and every published step is written to an append-only GeoPackage recording before it is shown anywhere. Three capabilities read from that one file: replay, fork, and audit. Register terrain · physics parameters · forcings IDENTITY LOCKED Run — epoch by epoch e1 e2 e3 e4 · · · eN each step advances GPU-resident state and publishes it The recording append-only · one file a GeoPackage, opens in QGIS VERIFIABLE Replay scrub any past frame; a viewer cannot tell it from live Fork — what-if branches share history exactly, then diverge forward only Audit prove what was shown is what was computed — years later Nothing is ever displayed that was not first recorded.
Registration freezes what the twin is; the run advances it; the recording is written underneath the whole way. Replay, forking and audit are all readers of that one file.

The one rule that makes the rest work

A change becomes visible — on screen, on the network, to any consumer — only after it is durably written to the recording. Nothing is ever displayed that was not first recorded. That is why replay, forking and audit are exact rather than approximate, and why “saved” and “shown” are the same moment: if you can see it, it survived a power loss.

See it run

Two worked demonstrations, each read back off its own recording. One asks what a decision costs; the other asks whether the engine can be trusted to answer.

Satellite view of Black Canyon with a narrow ribbon of simulated water threading south down the gorge
Fork a decision

Hoover Dam, both ways

A GPU flood simulation over real SRTM terrain runs to epoch 54 and is paused mid-event, then forked in place. One decision is overridden in the branch — release rate, ten times higher — and the ledger conserves water across the split.

Read the showcase →
Satellite view of a coastline with a bright simulated plume running inland from the shore
Check the math

The plume that checks its own math

A conserved scalar carried on a wind while it spreads, held against the closed-form Gaussian solutions and reported to the decimal — then taken to a coastal what-if where one anchor becomes six worlds in a single recording.

Read the showcase →

The pieces, and how they connect

Four products cover the full lifecycle — authoring, persistence, operating, and remote viewing. They interoperate through fixed contracts, not shared code, which is why you can mix and match them.

Product Your role with it What it does for you
ForgeGIS Studio™ Author & operate The analyst's seat. Build a scenario on a canvas, run it, pace it, pause it, fork it, and scrub the replay — all in one browser workbench.
ForgeGIS™ (engine) Computes & records The runtime that advances the simulation on the GPU, publishes each step, and writes the recording. Also serves runs live over the wire.
ForgeData™ Stores & catalogs Production-grade persistence. Recordings land in a catalog by reference, with the same durability and integrity guarantees as the engine's own ledger.
Seaglass Globe™ View remotely A lightweight remote viewer that renders live or replayed runs on a 3D globe over the network — without ever embedding the engine.
Studioauthor & drive
›
Enginecompute & publish
›
Recordingdurable GeoPackage
›
Globe / QGISview & verify

Why “by contract” matters to you: the four products agree on fixed, published formats rather than private internals. A recording written today opens with tomorrow's reader; a viewer built against the spec works against any conformant run. Nothing breaks silently when one piece evolves.

What you actually do with it

Operating a twin is a small, stable vocabulary of actions. You issue them from Studio's panels or from the headless MCP interface — the same verbs either way.

Register

Define the scenario and freeze its identity

Run

Advance it epoch by epoch

Pace

Throttle to wall-clock for viewing

Pause / Resume

Hold and continue cleanly

Fork

Branch a what-if timeline

Stop

Drain and finalize the recording

Scrub / Replay

Move to any past frame

Verify

Prove the recording's integrity

Query

Read frames, epochs and snapshots

Two ways to run the same thing

Pacing is a viewing convenience, not a change to the result. A run throttled for a live audience and a run let loose at full speed produce a bit-identical recording — the wall-clock timing lives only in annotations that are stripped before anything is compared. You never have to choose between “watchable” and “correct.”

The guarantees you can build on

These properties hold no matter which product you are using or how the run was driven. They are what make a twin trustworthy as evidence, not just as a visualization.

Nothing is a lie in flight

A change becomes visible — in the registry, in Studio, on the wire — only once it is durably written. There is no window in which a consumer can act on state the engine has not yet committed, because that window does not exist.

Replay equals live

A remote viewer cannot distinguish a recording being replayed from a run happening now. The same client code, unchanged, handles both — demonstrated end to end with zero modifications.

Identity is content

A twin's identity is computed from what it actually is — its structure, its code, its terrain. Two twins that would compute different numbers can never share an identity, so results cannot be quietly swapped.

Forks share history exactly

A what-if branch inherits its parent's past byte-for-byte and diverges only after the fork point. Any difference you observe downstream is caused by your change — nothing else.

It fails loud, never fakes

Unknown data, uncertified physics, a missing terrain hash, an oversized frame — every one is a named refusal, not a silent substitution. A gap can only exist because you explicitly chose it.

Speed never changes the answer

Every performance option — how the run is paced, whether the viewer shares the GPU — is invisible to the record. Turn them on, off, or let one fail mid-run: the recording is byte-for-byte the same. You never trade correctness for throughput.

Reproducible where it counts

Re-running the same scenario on the same backend is bit-identical. Across different hardware, agreement is within tolerance — the system is honest about where exact parity is and isn't a property of correct math.

Interoperability in practice

The same recording serves very different consumers at the same time, each reading only what it needs through a shared, published surface.

Connection What crosses it, in plain terms
Studio → Engine Scenario definitions and run control — start, pace, pause, fork, stop — plus status and integrity checks, all in-process.
Engine → Recording Every published step, written durably before it is announced anywhere. The acknowledgment is the publication.
Engine → Globe Live and replayed frames over the network, with automatic recovery if a viewer falls behind — it is told exactly where to resume.
Engine ↔ Globe (same GPU) On a large-VRAM workstation, state moves as on-device copies through shared graphics memory. Meaning and the durable record still travel the normal path.
ForgeData ↔ Engine A second, independent storage implementation producing identical bytes — proof the format is a real contract, not one program's habit.
Recording → QGIS A finished run is a plain GeoPackage. Standard GIS tools open its snapshots directly, no ForgeGIS runtime required.
Where it runs

One machine, headless, catalog-backed, or nothing installed at all

All on one machine. Studio embeds the engine; you author, run, scrub and fork in a single process, recordings on local disk.

Headless / automated. Drive twins by command through the MCP interface, exposing a live endpoint for a Globe on the same network.

Catalog-backed. Recordings land in ForgeData's catalog by reference; every consumer reads the identical format.

Playback with nothing installed. A sealed recording is served or opened on its own — the format guarantees third-party readability.

Co-resident on a large-VRAM workstation. Engine and viewer share one GPU, so twin state reaches the renderer without leaving the card. Optional, off by default, and the recording is identical either way.

Running engine and viewer on one GPU

On a workstation with a large graphics card, the engine and the viewer can share it directly. Twin state then reaches the display without ever leaving the GPU — no copy back to main memory, no trip across the network.

Standard path versus co-resident path Normally twin state leaves the GPU and comes back: engine GPU, readback to main memory, across the network, upload to the viewer GPU — four copies of every frame. Co-resident, engine and viewer share one physical GPU through a ring of slots in shared VRAM, so the state is copied once, on the device. WITHOUT CO-RESIDENCY — STATE LEAVES THE GPU AND COMES BACK Engine GPU Main memory Network Viewer GPU 4 copies of every frame — the cost grows with scene size WITH CO-RESIDENCY — STATE NEVER LEAVES THE GPU Engine Shared VRAM — a ring of slots Viewer 1 on-device copy — no CPU, no socket, no readback
The engine writes finished state into shared graphics memory; the viewer reads it in place. Meaning, durability and audit still travel the normal path.

The saving scales with scene size rather than being a flat speedup — the bigger the raster, the more the skipped copying matters. And because the state is already on the GPU next to the renderer, the viewer can compute over live twin state as it displays it instead of making a separate pass.

What it does not change is the part that counts. The recording is byte-for-byte identical whether the mode is on or off — enforced by test, including when the feature is switched off mid-run or fails outright. The simulation never waits on the display: if the viewer cannot keep up, frames are skipped rather than the run being slowed. Engine and viewer keep separate graphics contexts, so co-residency never reduces how many other applications can use the card, and any fault falls back to the network path loudly and automatically. It is an accelerator, never a second source of truth.

When it applies: this is built for large-VRAM systems — roughly 24 GB-class cards and up. On smaller hardware there is nothing to gain, and the mode simply stays off. It is optional everywhere and disabled by default.

Who it's for

Four seats, one recording.

The analyst

Builds and branches scenarios

Runs scenarios on a canvas, watches them evolve, and branches alternatives — without writing code or managing the plumbing underneath.

The reviewer

Checks the work independently

Receives a self-contained recording and can independently replay it, verify its integrity, and confirm the visualization matches the computation.

The integrator

Builds against published contracts

Writes against fixed specifications, confident that a conformant client works with any conformant run — today's and tomorrow's alike.

The operator

Runs it headless, at scale

Drives twins headless and automated, streams them to remote viewers, and stores them at scale — with durability and recovery built in.

The digital twin is a ForgeGIS engine capability, driven from the ForgeGIS Studio canvas, and shipped in 1.2.3. This page describes capabilities and interoperability at a user level; for normative detail, the frozen format and contract specifications are authoritative.

Want the depth behind this?

The showcases carry the validation blocks this page leaves out — definition hashes, run identifiers, fork ordinals, and the recorded API exchanges behind every figure. Seaglass Foundry™ is happy to walk an evaluator through it.

rich@seaglassfoundry.com