India’s land, approval, construction, finance and municipal systems are being digitised, but the same physical asset continues to carry different identities across departments. STHAVAR can give every built and infrastructure asset one permanent identity and one traceable lifecycle record
India has built digital systems for identity, payments, taxation, documents, logistics and public services. State governments, ministries, infrastructure agencies and urban local bodies have also created portals for land records, building permissions, project monitoring, property taxation and municipal services.
Yet the same building or infrastructure asset continues to appear differently in each system.
A building may be connected to a survey number in the revenue record, an application number during planning approval, a separate file during construction, a property account after completion, a lender’s reference during financing and an insurance policy during operation.
The asset remains physically continuous. Its administrative identity does not.
This fragmentation is not merely an information-technology problem. It is a governance problem. When institutions cannot confidently establish that they are referring to the same physical asset, they duplicate verification, rely on conflicting records and discover discrepancies too late.
India’s next built-environment reform should therefore begin with a simple principle:
One asset. One permanent identity. One lifecycle record.
Introducing STHAVAR
India should establish STHAVAR, a national system for the permanent digital identification of built and infrastructure assets.
The term is derived from the Sanskrit ‘sthāvara’: that which is fixed, enduring or immovable. It expresses the defining characteristic of the assets the system would identify. Buildings, bridges, roads, stations, airports, ports, dams, utility plants and other fixed infrastructure may change in use, ownership, condition or administrative status, but their identity should remain traceable throughout their existence.
The proposed expansion is:
STHAVAR — System for Trusted, Harmonised Asset Verification, Administration and Registry.
Every registered asset would receive a permanent STHAVAR Ank linked to an authoritative STHAVAR Abhilekh, or lifecycle record.
The public proposition is straightforward:
Every permanent built asset deserves a permanent digital identity.
What the STHAVAR Ank Would Identify
The identifier would belong to the individual asset, not merely to its asset type.
For example, “bridge” is an asset type. A particular bridge across a specific river is the asset instance. “Hospital” is an asset type. A particular hospital building is the asset instance. The asset type may change. A warehouse may be converted into offices. A commercial building may become housing. A station may be expanded into a multimodal interchange.
The STHAVAR identity would not change merely because the use or classification changes.
The identifier should also be distinct from the land-parcel number. A parcel may contain several buildings, and one building may extend across more than one parcel. Parcels may be subdivided or amalgamated while the physical asset remains.
STHAVAR would therefore connect—but not replace—the identifiers already used for land, approvals, taxation, finance and utilities.
A Nationally Governed 128-bit Identity
The identifier should be generated through a nationally governed 128-bit identity standard.
This would provide sufficient capacity for all present and future buildings, infrastructure networks, public assets, utility installations and significant sub-assets across India. It would also support federated issuance by authorised state, municipal and sectoral systems without creating a material risk of duplicate identities.
Internally, the identifier would be stored as 16 bytes. For administrative use, it could be displayed in a compact alphanumeric form such as: 01K8-DR7M-2X9T-4QP6-V3NC-5WZ8H The characters should not encode the asset’s state, district, owner, use or approval year. All of those can change.
The STHAVAR Ank should be permanent, non-semantic and non-reusable. Its only purpose would be to identify the asset consistently.
The associated records would establish what the asset is, where it is located, who owns or operates it, which approvals apply and what has changed over time.
The Lifecycle Begins Before Construction
A STHAVAR Ank should be issued when an asset formally enters the statutory approval or public-investment process. At that stage, the asset may exist only as a proposal for a building, bridge, road section, station, utility plant or public facility. The identifier would connect the asset to:
• the land and location on which it is proposed;
• environmental and infrastructure constraints;
• submitted drawings and models;
• professional certifications;
• statutory approvals; and
• conditions imposed by authorities.
If the proposal does not proceed, the identity would be retired but never reassigned. The historical record would remain available for audit, planning and institutional learning.
Design, Approval and Construction
During design and approval, every formal submission and revision should be associated with the same STHAVAR Ank. This would allow authorities to establish:
• which drawings were submitted;
• which version was assessed;
• which professional certified the information;
• what conditions were imposed; and
• what was ultimately approved.
During construction, inspections, approved variations, test certificates, non-compliance notices and completion evidence would continue under the same identity. This would reduce the present gap between the asset as approved and the asset as constructed.
The identifier would not declare that the asset is compliant. It would allow authorised users to find the records that establish its compliance status.
Completion, Finance and Operation
Once the asset is completed, its STHAVAR identity would continue into operation. The STHAVAR Abhilekh could connect:
• completion and occupancy certificates;
• approved as-built information;
• fire and life-safety records;
• accessibility information;
• major warranties and certifications;
• property-tax records;
• valuation and mortgage references;
• insurance records; and
• operation and maintenance information.
Banks, insurers and valuers would not require unrestricted access to the complete record. Role-based access would allow each institution to verify only the information relevant to its lawful function.
A lender might verify that the asset exists, that the approved area matches the valuation and that completion has been certified. An insurer may need access to occupancy, fire systems, construction type and major alterations.
The identifier would therefore reduce repeated document collection without creating a single open database of sensitive information.
Alteration, Maintenance and Resilience
Built assets change continuously after completion. They are extended, subdivided, strengthened, refurbished, refinanced, repurposed and repaired. Critical systems are replaced. Ownership and operating responsibility may change several times. STHAVAR would preserve this history without erasing earlier records. Every material alteration would update the lifecycle record, showing:
• what changed;
• when it changed;
• who designed or authorised it;
• which approval applied; and
• which previous record it superseded.
For critical public assets, the same identity could support maintenance planning, condition monitoring and capital-replacement programmes.
During floods, earthquakes, fires or industrial emergencies, authorised responders could use the identifier to access essential information such as asset configuration, emergency access, structural risks, hazardous materials and utility shut-off locations.
This transforms the asset record from an approval archive into an operational and resilience resource.
Parent and Child Assets
Large assets require a hierarchy. An airport may have a parent STHAVAR identity, with separate child identities for terminals, utility plants, car parks and other independently managed facilities. A highway may have related identities for operational sections, bridges, tunnels and major interchanges. A development may include identities for the overall precinct, individual buildings, towers and independently owned units.
Not every door, pipe or structural element needs a national identifier. A component should receive its own STHAVAR Ank only when it has an independent statutory, financial, maintenance, ownership or safety significance.
This keeps the system manageable while preserving detailed traceability where it matters.
From Identification to Governance
A national identifier alone will not solve fragmentation. STHAVAR must operate within a clear governance framework.
Every linked dataset should have an assigned custodian responsible for its accuracy, legal status, update cycle and correction process.
Digital records must distinguish between information:
• submitted by an applicant;
• certified by a professional;
• approved by an authority;
• verified during construction; and
• observed during operation.
Every material transaction should leave an audit trail. Access should be role-based, proportionate and logged.
STHAVAR should not become a centralised repository that absorbs every institutional database. It should function as a trusted reference through which separate systems identify the same asset and exchange authorised information.
This is the shift from portals to protocols.
The Identity Spine of the Saptarishi Framework
The Saptarishi Framework proposes a seven-layer digital architecture connecting construction information, land governance, infrastructure coordination, environmental intelligence, finance, municipal systems and resilience.
STHAVAR gives that architecture a common identity spine.
The same asset can be recognised consistently across every layer:
• its design and construction record;
• its land and legal relationships;
• its infrastructure connections;
• its environmental and hazard context;
• its finance and insurance status;
• its municipal approvals and operation; and
• its resilience and emergency information.
The relationship can be stated simply:
Saptarishi provides the architecture.
STHAVAR provides the permanent identity.
STHAVAR Abhilekh preserves the lifecycle memory.
STHAVAR Sutra enables the institutional exchange of that information.
A Practical Route to Implementation
STHAVAR should begin with carefully selected pilots rather than an immediate attempt to register every existing asset. Priority pilots could include:
• new public buildings;
• major transport projects;
• hospitals and schools;
• municipal building-approval systems;
• mortgage-backed developments;
• bridges, dams and critical utilities; and
• assets in disaster-prone urban districts.
Existing assets could be added progressively when they undergo sale, refinancing, major alteration, safety assessment, regularisation or public investment.
Success should be measured not by the number of identifiers issued, but by whether STHAVAR:
• reduces conflicting records;
• shortens verification time;
• prevents approval and construction discrepancies;
• strengthens asset maintenance;
• improves financial transparency; and
• gives emergency agencies faster access to reliable information.
India has already demonstrated the national value of persistent identity and interoperable digital systems. The next frontier is the physical economy.
A building or infrastructure asset should not acquire a new administrative identity every time it moves from one department to another. It should carry a permanent reference from proposal and approval through construction, operation, alteration and eventual decommissioning.
That is the promise of STHAVAR: A permanent identity for every enduring asset—and a trusted memory of its entire life.
Apurva Pathak is an architect, design-governance practitioner and author of the Saptarishi Framework, a proposed seven-layer digital architecture for India’s built environment. He has more than three decades of professional experience across India, the Gulf, Africa, Papua New Guinea and New Zealand.
