LandStack — Parcel Exception Referral

Five Karnataka state systems hold records about the same physical parcels and share no common key: Bhoomi (the pahani/RTC), Kaveri (registration and encumbrance), e-Swathu (gram panchayat property), e-Aasthi (urban khata) and Mojini/Dishaank (survey and sketches).

LandStack ingests records from those systems, detects where they disagree about the same parcel, assembles the evidence, and refers each case to the officer statutorily empowered to act on it.

The demonstration subject is a road corridor in Shettihalli, Tumakuru — a real road with fabricated parcels along it. A second, smaller set of records covers Divya Villas, a converted plotted layout by Zion Estate at Lingambudi village, Kasaba hobli, Mysuru taluk, Mysuru district, covering Survey Numbers 83/2 and 84/2.

The legal constraint that shapes everything

No officer can alter a Record of Rights by a data write. Substantive change happens only through a mutation proceeding under ss.128–129 of the Karnataka Land Revenue Act 1964, an appeal to the Assistant Commissioner under s.136(2), or revision by the Deputy Commissioner under s.136(3). There is no online RTC correction facility anywhere in Karnataka, for citizens or officers. Section 133 makes the pahani presumptive, not conclusive, evidence of title.

LandStack therefore writes nothing to any government record, ever. It is a referral system, not an adjudication system. It never decides which record is correct — that is the officer's function, and where title is disputed, the civil court's.

Framing rules

These govern all copy, headings, tooltips and empty states. They are not decoration; they are the product.

1. LandStack reads records, not registries. No portal connection, no scraping, no live feed. Every record was obtained as a citizen-facing certified document and entered manually.
2. Output vocabulary is Confirmed, Disagreement, Unmatched, Insufficient data. Never "verified", "validated" or "title confirmed".
3. Every record carries a visible Real or Synthetic badge. Anything fabricated to populate a screen says so on its face.
4. Never "declared vs delivered", "land intelligence", or "single source of truth".
5. No AI model names, no internal costs, no margin figures anywhere.
6. Computer vision, satellite imagery and drone capture are roadmap only, marked "Not built — roadmap" wherever referenced.

Running it

npm install
npm run dev          # http://localhost:3000

npm test             # Vitest — 57 tests
npm run typecheck    # tsc --noEmit, strict
npm run build        # 42 static pages

No database, no environment variables, no external API calls at runtime. All data lives in typed JSON under /data and is loaded at build time. Deploys to Vercel with zero configuration.

Turning a certified document into a SourceRecord

This is the whole ingestion path. It is manual by design — there is no portal to connect to.

1. Obtain the document as a citizen would: a pahani (RTC) through Nadakacheri or a Bhoomi kiosk, a Form 16 encumbrance certificate or certified instrument extract through Kaveri, a Form 9 from the gram panchayat, a khata extract from the urban local body, or a sketch extract through the Mojini workflow.

2. Add an entry to data/records.json. Give it an id of the form <SYSTEM>-<DOCTYPE>-<SURVEY> (for example KA-EC-83-2, BH-PAH-84-2).

3. Set provenance. "Real" only if every field below was read off an actual issued document. Otherwise "Synthetic", and put the reason in notes. Do not mix: a Real record with invented owner names is the one failure mode this field exists to prevent.

4. Copy rawKeyString character for character as the document prints it — 84*2, 84/2, 086/01. Do not tidy it. Normalisation happens in code and the raw string is displayed above the normalised form on every screen.

5. Fill parcelKey with the LGD village code and the village name as printed on that document. Where a document spells the village differently from its neighbours, keep the printed spelling — KA-EC-83-2 prints "Lingaabudi" where other records read "Lingambudi", and that difference is preserved.

6. Fill extent by unit. Populate only the units the document actually prints; leave the rest null. Put the literal printed line in asPrinted — that string is what every screen shows. kharabA and kharabB are recorded separately and are deliberately excluded from the comparable area.

7. Fill owners. nameAsPrinted verbatim, and script set to "Kannada" or "Latin" according to what is on the page. Never transliterate: a cross-script pair returns no score and the verdict becomes Insufficient data, which is the intended outcome.

8. Set the flags. isPaiki where the pahani carries the allotment as a paiki; bupaFlagged where the pahani carries the Bu.Pa conversion flag; mrNumber where a mutation register entry is printed.

Nothing else is required. The reconciliation run in lib/run.ts derives the parcel grouping, the verdicts and the disagreements from the record set alone, deterministically.

Replacing the district boundary data

The Karnataka outline in data/karnataka-districts.ts was imported from the Vantis codebase (components/shared/KarnatakaMap.tsx) rather than redrawn, and restyled to this palette. It is SVG path data, not GeoJSON — 31 districts keyed by slug, plus a label coordinate each, against the viewBox 0 0 1633.9257 2366.7335.

To swap in different boundary data:

1. Replace DISTRICT_PATHS with a Record<string, string> of district slug to SVG path d attribute, and set KARNATAKA_VIEWBOX to match your source.
2. Replace DISTRICTS with one { id, label, lx, ly } per district; lx/ly are label coordinates in the same viewBox space.
3. If you are starting from a karnataka-districts.geojson, project it to a flat SVG coordinate space first (for example with d3-geo's geoMercator and geoPath) and emit the path strings. Do not add a runtime mapping dependency — the component must keep making no network calls.
4. SUBJECT_DISTRICT in components/KarnatakaMap.tsx selects which district is filled gold.

The original carried no accuracy caveat, so one is stated in the file and in the figure caption: this is a schematic outline for locating a district on screen. It is not a survey document, it is not to scale, and no boundary shown has evidentiary value. LandStack holds no parcel geometry at all. The second map level is an adjacency diagram drawn from boundary fields printed on the encumbrance certificates — it is not a sketch of anything.

How matching works

Full detail is on the /method screen. In short:

• Key. normaliseKey trims, collapses whitespace, splits on the first of *, /, -, and strips leading zeros per segment. One separator means the second segment is the hissa; two means the second is the surnoc and the third the hissa. The printed string is never altered.
• Name. Honorifics and relational prefixes are stripped, then an order-independent token-set comparison where a single letter stands in for any token starting with that letter, combined with an edit distance on the longest substantial shared token. Cross-script pairs return null.
• Extent. Both sides converted to m² (1 acre = 4046.86 m², 40 gunta = 1 acre, 1 ha = 10 000 m², 100 cent = 1 acre). Tolerance is the greater of 1% or 100 m². A converted figure is never displayed as if it were the record.
• Verdict. Confirmed needs a key match, a name score ≥ 0.85 and an extent within tolerance. e-Swathu and e-Aasthi records are never confirmed.
• Routing. Every disagreement resolves to exactly one officer. Where it cannot, the case is not referable and the screen says so.

Comparisons are anchored on the pahani rather than run over every pair of records. A referral asks an officer to act on an entry in the Record of Rights, so a difference between a registered deed and a survey sketch belongs to no officer, and comparing every pair would raise the same underlying fact several times over — four identical requests to the ADLR for one sketch, or one owner conflict addressed to two different officers under two different provisions.

Limitations

Restating /method, because these are the point rather than the caveats.

• LandStack writes nothing to any government record. A flag raised here is a data-integrity finding, not a determination of right.
• A pahani entry carries a rebuttable presumption of correctness under s.133 and is not conclusive proof of title.
• Corrections happen only through the statutory mutation, appeal or revision process. There is no online RTC correction facility in Karnataka.
• No transliteration between scripts. A cross-script name comparison returns no score at all. A wrong transliteration would let two different people read as one.
• No live portal connection. No feed, no scrape, no API. Every record was entered by hand.
• No way to key an e-Swathu or e-Aasthi record to a survey number. The state maintains no such link. Where a local-body record is placed against a parcel it is placed on owner name, village and approximate extent — an association, never a match.
• No title opinion. Nothing on any screen is one.
• No parcel geometry. LandStack cannot tell you where a boundary runs on the ground.
• Sakala clocks exclude gazetted holidays, so an elapsed working-day count is an upper bound. Services not on the notified list read Not a notified Sakala service — no day-count is invented for them.
• Referrals are session state only. Nothing is persisted and nothing leaves the browser. A full page reload re-seeds the demonstration.
• No parcel geometry, at any level. The state and district outlines are schematic locators. The village layout is hand-drawn and illustrative. Cadastral geometry is held by SSLR and KSRSAC and is not available to us.
• A finding may be an observation rather than a disagreement. Where a comparison passed but the entry is still worth an officer's eye — a name printed in a different form, a sketch difference inside the tolerance — it is raised as an observation and labelled on screen as "not a disagreement". Putting a false mismatch on an officer's desk is the fastest way to have the whole queue ignored.

Known limits in the underlying data

Surfaced in the interface as an amber Manual verification required badge:

• Kaveri digitised records are reliable only from 2003–2004 onward.
• Roughly 58% of hissa maps are georeferenced, so ULPIN exists only on georeferenced parcels.
• Roughly 7–9 lakh paiki numbers exist statewide with no spatial record.
• Converted land drops out of Bhoomi tracking entirely.

The Bu.Pa handoff

On conversion the pahani is flagged Bu.Pa (ಭೂ ಪರಿವರ್ತನೆ), Bhoomi stops tracking the parcel, and nothing carries the record across to the gram panchayat or the urban local body. Statewide, Aadhaar-linkage checking found roughly 72.11 lakh parcels in non-agricultural use against only 4.69 lakh recorded as converted, out of about 4.11 crore agricultural plots.

Divya Villas was seeded as an instance of this class. That is an assertion carried in the brief, not a finding: the conversion flag sits on a Synthetic pahani, and the two Real certificates are Nil encumbrance certificates, which say nothing about conversion. The parcel screen says so.

Spatial navigation

Four levels, each a distinct route so the path can be driven by URL:

/                    Karnataka -> Tumakuru road corridor (the landing screen)
/parcels             flat index of every parcel, both districts
/parcels/[composite] the five-system crosswalk
/queue               exception queue, FIFO
/queue/[id]          case sheet + printable referral note
/ledger              append-only audit trail
/records/[id]        a single source record
/method              the matching rules, the routing table, and the limits

Position lives in the URL. /?at=870 puts you 870 m along the road, so coming back from a parcel returns you to the stretch you were standing on rather than to the Karnataka map.

Records with no shape are listed, never drawn. A paiki is a textual-only sub-division carried in the pahani with no spatial record, and an e-Swathu Form 9 prints no survey number at all. Neither can be placed on a map, so both appear in the sidebar under "Held, but not on the map" with the reason. The absent shape is the finding; dropping them silently would hide it.

The corridor shows what the records show. Owner and extent come from the records themselves, never from the layout file. An earlier build kept copies in both and they drifted — hovering Sy. 107/2 showed one owner while opening it showed another. parcelDisplay in lib/corridor.ts is now the single path, and a test asserts the two agree.

The Tumakuru corridor

/ is the landing screen and has two states. It opens on Karnataka; clicking Tumakuru transitions in place into a road corridor you travel along.

• Plan view — Leaflet over a real basemap, with forward/back chevrons, arrow keys (↑ ↓ ← →, Home, End) and a position scrubber. Parcels are tinted by case status and clickable through to the five-system view.
• Perspective inset — a schematic view down the road from the current station, parcels receding by their recorded distance ahead and lateral offset. It is captioned SCHEMATIC — NOT A PHOTOGRAPH, NOT A SURVEY because that is what it is.

The road is real. The parcels are not.

The centreline is OpenStreetMap way 400940819 — Shettihalli Main Road, Tumakuru, 1752 m. The basemap around it is genuine OSM road and building geometry for the corridor's bounding box (728 roads, 4 781 building footprints). All 26 parcels drawn against it — every boundary, survey number, owner and extent — are fabricated, five of them wired through to full five-system records. The screen says so above the map, and the LGD code 999061 is a demonstration code rather than a real village code.

Why there are no raster tiles

There is no keyless raster basemap that permits pre-caching:

• OpenStreetMap's own tile servers refuse bulk downloads. They return HTTP 200 with an "Access blocked" image, so a naive cache silently fills with 244 identical refusals — which is exactly what happened on the first attempt here.
• CARTO now requires an API key, and stamps "API KEY REQUIRED" across unkeyed tiles.
• Stadia, MapTiler and the rest need a key, which would mean an env var and a runtime dependency.

So the basemap is the OSM vector data, extracted once into data/tumakuru-basemap.json and rendered by LandStack in its own palette. That keeps the geometry genuinely real, needs no key, makes no runtime network call, and works with no connection at all. Attribution is required either way and is shown on the map: © OpenStreetMap contributors.

Two districts, one spatial surface

Tumakuru is the corridor. Mysuru holds the only two Real documents in the corpus — issued encumbrance certificates for Sy. 83/2 and 84/2 — and is reached through /parcels, /queue and /ledger rather than through a map of its own. Between them the corpus covers all eight rows of the routing table; the corridor alone covers all eight too.

A referral note derives its location and its addressee from the parcel's own records (placeOf in lib/run.ts, officerOffice in lib/constants.ts). It used to build both from a fixed project constant, so a Tumakuru case was addressed to "Tahsildar, Mysuru taluk" — an officer with no jurisdiction over the parcel, which makes the note unactionable.

The crosswalk

ParcelIdentity (in lib/types.ts, built by lib/identity.ts) holds what each system already calls a parcel alongside the shared anchor those references were matched against.

We do not mint a new parcel identifier. Karnataka already has too many; inventing a sixth is the first thing an officer would object to. The contribution is normalisation and linkage, not a new number.

Three rules are enforced in code and visible on screen:

• All five systems always appear. A system holding no record is carried with referenceHeld: null and linkMethod: "unlinked", never omitted. Absence is a finding, and a missing row hides it.
• linkMethod is never a key method for e-Swathu or e-Aasthi. They carry no survey number, so the best available is "name and extent" at low confidence, with a note saying what did and did not corroborate.
• ulpin is null unless the parcel is georeferenced, and ulpinNote then says why.

Layout

app/                     Screens — /, /parcels, /parcels/[composite], /queue,
                         /queue/[id], /ledger, /records/[id], /method
components/              Nav, KarnatakaMap (both levels), SakalaClock, Term
                         (glossary), store (session referrals + ledger), ui
lib/types.ts             The domain model
lib/extent.ts            Unit conversion — comparison only
lib/reconcile.ts         normaliseKey, nameScore, extentDelta
lib/routing.ts           routeDisagreement — the routing table
lib/run.ts               The reconciliation run, records -> MatchCandidate[]
lib/identity.ts          The crosswalk — ParcelIdentity per parcel
lib/geography.ts         District / taluk / hobli / village hierarchy and counts
lib/corridor.ts          Tumakuru corridor geometry and road coordinates
data/tumakuru.json       Corridor centreline (real OSM) + 26 fabricated parcels
data/tumakuru-basemap.json  Real OSM roads and buildings for the corridor bbox
components/corridor/     PlanMap (Leaflet), PerspectiveInset, CorridorScreen
lib/constants.ts         Sakala limits, tolerances, data-quality flags, framing copy
data/records.json        The record set
data/systems.json        What each system holds and cannot tell you
data/karnataka-districts.ts  Imported district boundary paths

Terminology

The department's own words are used in the interface, with the English gloss in a tooltip — not the reverse: pahani (ಪಹಣಿ), khata (ಖಾತೆ), MR number, phodi (ಪೋಡಿ), tippan (ಟಿಪ್ಪಣಿ), akarband (ಆಕಾರಬಂದ್), hissa (ಹಿಸ್ಸಾ), surnoc, J-Slip, Bu.Pa (ಭೂ ಪರಿವರ್ತನೆ), kharab A and B, paiki, 11E sketch, Nadakacheri, Sakala, durasti. Kannada is rendered in a Kannada face and never transliterated for display.