What a Real Jurisdiction Would Change — and What It Wouldn't

The Fear of Lock-in

Governments are right to be cautious about vendor lock-in in critical infrastructure. A land registry carries legal authority that cannot be transferred to a third party without political consequence. If the system a government adopts encodes assumptions about their legal framework, their tenure categories, or their administrative hierarchy in ways that cannot be changed without renegotiating with a vendor — that is a sovereignty problem.

The Landblock Registry Template is designed specifically to avoid this. The distinction that matters is between what is architecture (fixed across all deployments) and what is configuration (set by the jurisdiction for their own deployment).

What Stays the Same in Every Deployment

The following components are identical across all jurisdictions. They are governed by international standards or the Landblock protocol — not by any single government's preferences.

Component	Governed by
Seven-layer registry structure	Landblock architecture
LADM data model (ISO 19152)	International standard
OGC geospatial compliance	International standard
Federation proof format	Landblock protocol
DID-based identity framework	W3C standard
Cryptographic audit trail	Landblock architecture
Workflow engine (the engine itself)	Landblock architecture

Standardizing these components is what makes cross-registry federation possible. If every jurisdiction uses a different proof format, proofs cannot be mutually verified. Standardization here is a feature, not a constraint.

What a Jurisdiction Configures

Legal framework (Layer 0)

The constitutional authority, land tenure categories, RRR types, and approval thresholds are all jurisdiction-specific configuration. A civil law jurisdiction configures different RRR types than a common law jurisdiction. A federal state configures a different approval hierarchy than a unitary state. These are YAML configuration files, not code changes.

Administrative hierarchy

The registry supports any depth of administrative hierarchy. National → Region → District → Municipality is one pattern. National → Island → Settlement is another. The hierarchy is declared in configuration and maps to LADM AdministrativeUnit entities.

Coordinate reference system

The Novaterra simulation uses EPSG:4326 (WGS84) for simplicity. A real jurisdiction typically uses a national grid CRS with legal standing for boundary disputes, with WGS84 as a secondary display CRS. Both are configured in spatial.yaml.

Workflow definitions (Layer 2)

The workflow engine executes state machines defined in JSON. A jurisdiction defines the steps, approval roles, escalation paths, and required documents for each workflow type. A systematic adjudication workflow looks different from a voluntary registration workflow. Both run on the same engine.

Identity provider

Landblock uses DIDs as an abstraction layer. The underlying identity source can be a national ID system, a biometric registry, an existing government PKI, or self-sovereign DIDs anchored by government keys. The registry logic does not change — only the DID issuance adapter.

Blockchain anchoring

Blockchain anchoring is optional. A jurisdiction can anchor critical registry milestones to a public chain, use a private consortium chain, or simply store cryptographic hash logs in a government database. The registry is fully functional without any blockchain. Anchoring adds an independent verification layer for cross-registry trust.

Configuration vs. Code: Effort Estimates

Change	Mechanism	Effort
Jurisdiction name and legal references	jurisdiction.yaml	Hours
Administrative hierarchy	admin-units.yaml	Hours
Tenure types and RRR categories	rrr-types.yaml	Hours
Coordinate reference system	spatial.yaml	Hours
Workflow steps and approval gates	workflows/*.json	Days
Identity provider integration	API adapter	Days–Weeks
Legacy data migration	ETL scripts	Weeks–Months
Existing system integration	Custom API connectors	Weeks
Capacity building and training	Change management program	Months

The pattern is consistent: the technical adaptation work is measured in days to weeks. The significant timelines are in legacy migration and organizational change — which are true of any land administration modernization, regardless of the platform chosen.

What a Pilot Would Add Beyond This

A production pilot requires things that are governance and process, not technical:

• Legal authorization — a government instrument establishing the registry's authority
• Data protection compliance — mapping national privacy law requirements to system controls
• Disaster recovery and business continuity planning
• Interoperability agreements with other government agencies
• Public consultation and stakeholder engagement records
• Third-party security audit

None of these require changes to the architecture. They are the governance scaffolding applied on top of a working technical foundation.