What this prototype does not do

Every parcel, person, name, owner, boundary, encumbrance, due and application in this prototype was generated by a seed script. No record corresponds to a real piece of land or a real person. Any resemblance to a real holding is coincidence.

The names on the demonstration accounts — Rupa Das, Bikash Sarma, S. Baruah — are fictional. The phone numbers are not in service. The map boundaries are synthetic polygons drawn around a village centroid; they are not cadastral survey geometry.

A state pack is either transactional — you can complete a service end to end against synthetic records — or guidance only: correct terminology and process explanation, but no records and no filing. We do not fake records for a state in order to make its badge look better.

Right now 36 of 36 packs are transactional and 0 are guidance only.

ACRES makes no request to any government host, in any state, at any point. It does not scrape a portal, log into one on your behalf, or use an undocumented endpoint. Nothing you do here reaches a real revenue department, and no official anywhere sees it.

Conversely, nothing here reflects the real status of any real land record. If you need your actual record, you must obtain it from your state's own revenue department.

The sign-in screen accepts a seeded phone number and the fixed OTP 123456. No message is sent to any phone. There is no identity check of any kind.

No Aadhaar number is collected, validated, or used. No PAN is validated. No eKYC, no DigiLocker, no eSign, no Aadhaar authentication. Where a form field mentions an identity document, it is a plain text field in a demonstration database.

No payment is processed. No payment gateway is contacted. A "payment" in this prototype writes a row and prints a receipt; no money moves and the receipt is worthless.

Any document this prototype generates is a synthetic PDF. It carries no seal, no digital signature with legal effect, and no authority.

Every fee amount, stamp duty percentage, registration charge and service deadline shown anywhere in ACRES is indicative and unverified unless it is explicitly badged as verified with a citation. At the time of writing, we hold no verified public source for any Assam fee or statutory deadline, so those figures are all badged "indicative — not verified".

These numbers were chosen to make the product demonstrable. They are not taken from a fee schedule, a gazette notification, or a citizen charter. Do not use any number in this prototype to budget a real transaction. Fabricating a citation to make a figure look solid would be worse than saying we do not have one, so we say we do not have one.

The same applies to timelines. Where a step shows a number of days, it is a plausible figure for a demonstration, not a service-level commitment anyone has made.

A language model is used for three things: understanding the sentence you type and mapping it to one service; parsing free text when searching for a parcel; and re-phrasing an outcome in plain language.

The model never decides anything. Eligibility, blockers and fees come from deterministic rules and pure functions. Approval comes from a human officer role. A model can pick the wrong service — that is why the /ask screen shows what it understood and lets you choose differently before anything is filed.

Model output can still be wrong. Any explanation of a legal term here is a plain-language paraphrase for orientation, not legal advice.

• Only a subset of services is implemented, and only for the transactional packs listed above.
• Speech input uses the browser's own speech API where it exists. It is absent on many Android browsers and its accuracy in Assamese and Hindi is poor. Typing and the situation chips are the reliable paths.
• Translations cover the main citizen path. Deeper screens fall back to English rather than showing an untranslated key.
• The officer console is a demonstration of a workflow, not a hardened administrative system. There is no real role verification.
• There is no accessibility audit certificate, no security review, no load testing and no data protection assessment.

To make any of this real for a single state, the following would be needed — none of it is technical decoration:

• A written agreement with the state revenue department, and a legal basis for reading and writing land records on a citizen's behalf.
• Authenticated API access to the state land records system, or an agreed replication feed. Most states have no such public API today, so this is a negotiation, not an engineering task.
• Real identity: Aadhaar authentication through a licensed AUA/KUA, or an equivalent state identity gateway, with consent artefacts and a data protection impact assessment under the DPDP Act.
• Real payment: an authorised payment gateway, the state treasury challan flow, and reconciliation with the department's own accounts.
• Legally effective documents: eSign or departmental digital signature, an official seal, and a verifiable issuance register.
• Verified fee and SLA data, sourced from gazette notifications and citizen charters, with a process for keeping them current. Every figure would then carry a citation instead of an "indicative" badge.
• Real cadastral geometry from the state survey department, with the licensing that comes with it.
• Grievance redress, audit retention, and an accessibility conformance audit against the national guidelines.