The reality model, the record and the reasoning that every ORB solution runs on — one traceable account of the physical world.
The reality itself, 1:1 on datum — the city and everything beneath it, on one globe.
The overview across time: every project, figure and change, read at a glance and kept under watch.
Where the judgement is made — reproducible, rule-based, every figure traceable to its source.
All of ORB's reasoning lives in one engine — plain, verifiable, and free of vendor lock-in. One place where every judgement is made, and one place to inspect how.
The numbers are open to inspection, not sealed inside a vendor's model. When a contractor or a lender tells you the ground requires this design, at this depth, at this cost, you have an independent judgement to hold it against — and every figure in it carries the source, the standard and the margin it came from.
The rulebook is data, not code. Which source applies, which standard governs, which norm is in force — all of it lives in configuration, per country and per domain. A new country, a new standard, or a different contract form is a setting, not a rebuild.
There is one front door, and it is your account — which is really your own ORB. Behind it lies your tenant: your projects, your standards, your view of ORB World and the Living Twin. World, the Living Twin and the field app are not separate systems but rights within that ORB, and your role decides what each user reaches.
You join by creating an account; from that moment the ORB is yours. The one exception is the API — a company-level, machine-to-machine integration: an organisation connects ORB directly and runs its own user management, so its people reach ORB through that company rather than individual accounts. Underneath, the GIS layer is substrate and largely a commodity — ORB is not a second Esri or QGIS.
A placed initiative is a single feature. Its assessment, its plan and its programme are successive layers on that same feature, with no ETL, no bridge and no interface between stages. What crosses each boundary is a permission to proceed, and because nothing is copied into a separate system, nothing is lost along the way. After execution the feature stays under watch, so the record that justified a decision is the record it is later monitored against.
The plan layer is where ORB engineers. The design itself — the bore, the route, the heat-net — is produced here and held as a state on the feature, not in a separate tool. ORB does not only assess a plan; it can draw one, and check any plan against it.
These are the states a feature can be in — not steps to march through, but a set you draw on.
You enter at any state and draw only on the ones your question needs — sometimes a single report, sometimes place-and-reason, sometimes only monitoring. It is iterative, not one-way: a design can return to assessment as a revision. A set of states you draw on, not a path you must walk.
The chain is the same for a high-voltage line in Denmark or a water scheme in South Africa. The domain changes; the chain does not.
One globe, one datum. Ground is ground and coordination knows no border, so the same chain holds anywhere on Earth.
Enter at any state — a fresh initiative, a delivered project to verify, an existing asset to monitor. Measuring is one optional station, not the entrance: the twin is already a measured world.
And it learns: what was actually built or chosen is held against what was predicted, sharpening the next judgement.
From the assessment ORB produces one neutral plan layer: constraints · actions · phases · permit triggers. This is where it engineers — the bore, the route, the net. A permit trigger is not advice; it enters the plan as a mandatory work package, carrying the clause that produced it. Each methodology is a thin renderer over the same layer, so adding one is a mapping, not a new system.
Once assessed and planned, initiatives roll up into a funded, multi-year works programme — sequenced across budgets, years and the parties that build it, and driven by standardised norms rather than ad-hoc scheduling. It is held on the same features, so budget, year and priority stay attached to the work itself, and a whole portfolio is steered from one place — not stitched together from separate systems afterwards.
The lenses on the Solutions menu are the sharp end. Underneath, the same object model, graph and engine have been carried across an entire municipality’s domains — above ground and below, technical and social — because a domain is a configuration on one engine, not a new system.
Each is a lens on the same twin, the same graph, the same audit trail. Some are in daily shape, some are early — but all speak one model.
