Why a Fictional Jurisdiction
The first question governments ask is not "can you build this?" — it is "does this actually work?" To answer that question concretely, you need to run the system through a complete scenario.
Using a real country raises immediate problems. Real boundaries are politically sensitive. Real names imply official endorsement. Real cadastral data carries legal and privacy implications that take months to negotiate before a technical demonstration can begin.
A fictional jurisdiction removes all of those obstacles while preserving full technical fidelity. The workflows, data structures, cryptographic operations, and federation queries are identical to what a real deployment would produce. The jurisdiction name is the only thing that is synthetic.
The Republic of Novaterra
Novaterra is a fictional lower-middle-income country designed to represent a technically plausible but non-existent jurisdiction. It has no real borders, no real government, and no geopolitical significance.
- Administrative structure: National → Province → District, with 5 provinces and 25 districts
- Legal system: Civil law tradition modeled on LADM and VGGT principles
- Cadastre maturity: Partial digitization with mixed legacy records — representative of where many real jurisdictions currently are
- Survey system: Licensed surveyors with government verification
This profile was chosen deliberately. A jurisdiction that already has a complete digital cadastre does not need Landblock. The interesting and common case is a jurisdiction transitioning from paper-based or partially digitized records to a sovereign digital registry.
What the Simulation Executed
The simulation runs a single complete scenario: parcel registration with federation verification. That scenario is deliberately comprehensive — it exercises every layer of the registry and every major federation capability.
- DID-based identity registration for a fictional landowner and surveying authority
- Field survey submission with polygon geometry (12 vertices, EPSG:4326)
- OGC-compliant geometry validation and topology checking
- Survey provenance recording with cryptographic surveyor signature
- Basic Administrative Unit creation and LADM entity linkage
- Human review and approval by a district registration officer
- Rights, restrictions, and responsibilities assignment
- Tamper-evident audit trail generation with hash chaining
- Five federation query types with cryptographic proof responses
Each step produces verifiable artifacts. The simulation does not mock the cryptographic operations or skip the validation checks — it runs the actual registry code against synthetic input data.
Federation Queries Demonstrated
The simulation exercises five federation query types, each producing a structured JSON proof response:
- Existence verification — does this parcel exist?
- Ownership verification — who holds rights, and what are they?
- Rights and encumbrances — full RRR record with geometry
- Ownership history — bitemporal record including pre-digital legacy reference
- Workflow audit — step-by-step administrative process verification
Each response includes a registry state hash, authorizing DID, workflow instance reference, and ECDSA signature. An external verifier can confirm the proof without contacting the Novaterra registry directly.
The complete simulation report and all five federation proof JSON examples are available in the Novaterra directory of the Landblock Core repository.
Standards Validated
The simulation confirms compliance with the standards that matter most to government evaluators and auditors:
- ISO 19152 LADM — all core entities created and correctly linked
- OGC Simple Features — geometry validation, topology, CRS compliance
- W3C DID — identity verification and digital signatures throughout
- VGGT alignment — workflow includes community consultation and human approval gates
What This Is Not
This simulation is not a pilot, not a policy claim, and not evidence of deployment. It is a reference implementation — the technical artifact that allows a government to evaluate the system before committing to an implementation program.
The value of a reference implementation is that it makes the evaluation conversation specific. Instead of "can your system handle our tenure categories?", a government can ask "we need this workflow step — where in the configuration does that live?" That question has a concrete answer.