Ādaži Digital Twin starts from a public base twin first, not from a fully semantic or interoperable stack.

This module explains the difference between base twin, logical twin, inferred semantic seeds, and transport/interoperability so municipal reviewers and partners do not confuse one layer with another.

WS2 expects the product to explain data lifecycle, seven-layer management posture, and semantic interoperability. Those obligations are surfaced here instead of being hidden inside generic product language.

Institutional framing

Local Digital Twin Theory

Explain clearly what is base, what is logical, what is already an inferred semantic seed, and what still belongs to interoperability and future service packs.

Reference surface

Base

92%

Current maturity of this twin layer inside the platform.

Logical

74%

Current maturity of this twin layer inside the platform.

Semantic

39%

Current maturity of this twin layer inside the platform.

Interoperable

16%

Current maturity of this twin layer inside the platform.

Operational

12%

Current maturity of this twin layer inside the platform.

Four layers the municipality should not confuse

Base twin: Geometry, location, public provenance, and observable baseline facts. It answers what exists and where.

Logical twin: Layer definitions, bundles, inventory, counts, route references, and viewer-ready management logic. It makes the baseline usable.

Semantic seeds: Public-data classifications that already mean something for a domain, but are not yet official semantic packs.

Interoperability and transport: Shared models, exchange formats, cataloging, and context handling. This carries meaning across systems without being the meaning itself.

Current maturity of the Ādaži twin

Base: 92% currently evidenced inside the product.

Logical: 74% currently evidenced inside the product.

Semantic: 39% currently evidenced inside the product.

Interoperable: 16% currently evidenced inside the product.

Operational: 12% currently evidenced inside the product.

From public baseline to future semantic packs

Collect and normalize: Bring public geometry, identifiers, and basic attributes into one clean local twin payload.

Structure as a logical twin: Organize the payload into stable layers, bundles, counts, selection logic, and viewer-ready management surfaces.

Expose inferred semantic seeds: Classify public points and route results without pretending they are already authority-grade domain semantics.

Add transport and interoperability: Prepare shared models, cataloging, JSON-LD or NGSI-LD transport, and federation logic before multi-party reuse.

Operate services on top: Attach municipal service logic, analytics, guidance, and future domain packs such as waste, WEO, or SAMI.

Why this separation matters for WS2 pilot details

Seven-layer management path: The Ādaži authority should be able to understand what exists now across source systems, acquisition, knowledge, interoperability, services, orchestration, and visualisation without confusing that with domain semantics.

Data lifecycle from collection to sharing: The product should explain how data is collected, normalized, interpreted, exchanged, and reused, not only how it is visualized.

Semantic interoperability posture: Inferred semantics should be separated from their later transport model so the city can see what is already classified and what still needs standardization.

Own-instance control: The city should see its own Ādaži instance, its own baseline, and the path for adding its own semantic or operational packs later.

Service growth without rebuild: The base and logical twin should accept later packs such as municipal waste, WEO, SAMI, or EO semantics without replacing the platform.

Current twin model register

Layer	Current status	What it contains	What it does not contain yet
Base twin	Active	Boundary, roads, buildings, green-blue systems, and places for Ādaži	Authority semantics, operational rules, or standardized exchange
Logical twin	Active	Layer definitions, bundles, counts, route target, scene payloads, and management logic	Full cross-authority federation or domain-grade semantic contracts
Semantic seeds	Partial / inferred	Civic, mobility, commerce, waste, and route meaning inferred from public data	Authority-approved packs such as WEO, SAMI, or municipal waste operations
Interoperability / transport	Planned	Current internal JSON payload only	NGSI-LD, JSON-LD, DCAT, context broker, LDES, or federation path

Data lifecycle and transport path

Stage	Current posture	Next expectation
Collection	Public geometry and public reference sources only	Add authority and partner datasets when the baseline is accepted
Normalization	Local twin payload and layer inventory	Shared identifiers and authority data alignment
Semantic interpretation	Inferred seeds for civic, mobility, commerce, waste, and route	Formal semantic packs and domain ontologies
Transport and exchange	Internal payload only	NGSI-LD / JSON-LD / RDF / DCAT and brokered exchange
Reuse and federation	Not active yet	Cross-city reuse, pilot federation, and service interoperability

WS2 pilot-detail alignment register

Requirement	Manual expectation	Current platform posture
Rq2 data lifecycle	Describe tools, standards, components, and the data lifecycle from collection to use and sharing.	Theory and Docs separate collection, normalization, semantic interpretation, transport, and reuse.
Rq13 seven LDT layers	Each authority should control one LDT instance through management interfaces across all seven layers.	The product distinguishes source data, acquisition, knowledge logic, interoperability, services, orchestration, and visualisation even if not all are fully implemented yet.
Rq17 semantic interoperability	Ensure semantic interoperability of exchanged data through open standards such as NGSI-LD or LDES.	Semantic seeds are explicit, but transport remains local. The interoperability register keeps NGSI-LD, JSON-LD, RDF, LDES, and DCAT as future obligations, not fake current features.
Rc7 catalog and broker posture	Prefer DCAT cataloging and a context broker capable of JSON-LD, RDF, or NGSI-LD.	Documented as pending architecture. The product makes this visible instead of mixing it into the base twin.