Below is an analysis by points and the adaptation of our system "Single Construction Portal" for the new strategic direction of the Government of the Russian Federation from 2 March 2026 № 398-r. The document directly sets the frame to 2030 years for digital transformation of construction and housing and communal services, with emphasis on a single digital contour, machine-readable data, TIM/BIM, integration, customer-centric services and AI.
What exactly changes at the level of state logic
According to the document, the state is moving away from a set of disparate IPs to a single digital environment in construction and housing. Key accents are:
- All procedures should go into electronic form - not only the submission of documents, but also the entire life cycle of the object.
- Computer readability becomes a mandatory architecture, not an “option”: XML-patterns, registers, digital passports, uniform exchange formats.
- TIM/BIM and the digital twin are no longer just an innovation, but a target model of the industry.
- Integration of federal and regional contours - through GISOGD, Stroycomplex.RF, spatial data, supervision, expertise, public services, GIS housing and communal services.
- AI is permitted and encouraged in expertise, analytics, monitoring, forecasting and services.
- Import substitution is not a wish, but a basic principle of digital transformation.
- Client-centricity - the portal should not be an "archive of documents", but a working environment for citizens, business and government.
What it means specifically for our portal
To put it bluntly:
Our system can no longer be just an applicant's office or a showcase of services.
It should become an operational platform for the life cycle of construction and operation, where there are:
- a single object register;
- single document flow;
- unified digital processes;
- API-integration;
- layer of spatial data;
- machine-readable templates;
- events, statuses, control, analytics;
- preparation of data for AI.
That is, the portal must be rebuilt from a model:
« + files + statuses»
in the model:
“ Object + Participants + processes + Data + Integration + Analytics + Services.
Analysis of the document by semantic blocks and how to adapt the system
Unified Digital Industry Management Environment
The document requires the creation of a single digital environment for construction management and housing and communal services, as well as the integration of regional systems with federal ones. Separately named GISOGD subjects, “Stroykompleks.RF”, the project management system of state customers, the Unified State Enterprise of Expertise and related platforms.
What to do in the portal:
- make a single register of capital construction objects;
- make a unified register of participants: developer, technical customer, designer, contractor, expert, inspector, CC, RSO;
- make a unified register of processes: permits, expertise, construction, supervision, commissioning, operation;
- go to the end-to-end object identifier in all modules;
- to have a single event log on the object: who, what, when changed, what status, what document generated.
Bottom line: the object becomes the core of the system, not the statement.
Full transfer of procedures to electronic form
The document directly states that the target state is the transfer to the electronic form of all procedures for interaction of participants in the investment and construction cycle.
What to do in the portal:
- remove the “pseudo-number”, where the user downloaded PDF, printed, signed, downloaded back;
- implement native digital forms with routing;
- support:
- Structured statements;
- machine-readable applications;
- Checks before sending;
- versionality;
- legally significant signing;
- status model according to the regulations.
Minimum of mandatory entities:
- Application;
- set of documents;
- route of approval;
- observation;
- the order;
- version;
- decision;
- connection with the object and the stage of the life cycle.
Machine-readable formats and XML
The document several times focuses on XML-schemes of documents, machine-readable templates, translation of documentation and data into a structured format.
It's critical.
If you have now 80% Data is PDF/scan/Word, the system formally works, but is strategically outdated.
What to do:
- Enter a two-way document model:
- visual form;
- structured data layer.
- make a template register XML/JSON-schemes;
- all new processes to design on the principle of:
- First, the data structure;
- then screen;
- Then the print form.
What documents to translate first:
- gradplan / initial permit documentation;
- tasks and initial data;
- Executive documentation;
- Acts;
- Conclusions;
- construction control cards;
- input documents;
- documents of housing and communal services on accidents, charges, technical condition.
TIM/BIM as end-to-end technology
The TIM document indicates as the basis for the transition to end-to-end digital technology throughout the entire life cycle of the facility, up to the country’s digital twin. Indicators for the growth of the share of expertise on projects in the form of an information model and for the coverage of construction with digital tools were also established.
What this means for the portal:
your portal should learn to work not only with documents, but also with the model of the object.
Modules are required:
- card BIM/TIM-model;
- storage of references to models and their versions;
- connection of the model with the stages;
- the relationship of the model with comments, conflicts, prescriptions;
- visualization of statuses by model elements;
- comparison of model, estimates, graphics, acts and photo fixations.
Practically:
- at least start with BIM-light:
- the model register;
- viewer;
- metadata of the model;
- completeness checks;
- relationship of the model with examination and supervision.
- Next step is 4D/5D integration:
- terms;
- volumes;
- cost;
- fact/plan.
Continuous monitoring of project implementation
The document separately requires continuous monitoring of objects, especially those financed from the budget, with the use of TIM and the project management system of state customers.
What to do in the portal:
- implement the construction monitoring panel:
- Stage;
- status;
- risks;
- rejection of deadlines;
- photo fixation;
- the regulations;
- payment/contracting;
- Executive documentation;
- readiness for types of work.
- Make a dashboard for the manager:
- delays;
- objects with critical risk;
- objects without updates;
- difference of plan/fact;
- Red contracts;
- objects without valid model/documentation.
Architecturally: you need not just an office, but a management layer BI + event layer.
Customer-centric superservice
The document directly speaks about the development of the Digital Construction Superservice and the support of even unskilled participants, including individuals in the IHS.
Therefore, the portal should have 3 different UX models:
- citizen;
- Business/Professor;
- authority / control / operator.
What you need to add:
- Instead of departmental sections:
- Building a house;
- Obtaining permission;
- make changes;
- pass the examination;
- enter the object;
- transfer the object to operation;
- to apply for housing;
- conduct OSS;
- pay for services;
- collect the debt.
- Smart Feeding Master:
- asks questions;
- determines the route;
- assembles a set;
- It warns of risks and gaps.
This is especially important: the document clearly moves the system from “know the rules — submit” to “the system itself leads the user”.
Spatial data and map
The document fixes integration with Stroycomplex.RF and with a single digital spatial data platform.
Without a strong GIS layer, the portal will be incomplete.
What you need:
- map of objects;
- Layers:
- land plots;
- OX;
- zones;
- engineer;
- restrictions;
- stages of construction;
- accidents/incidents;
- development plans;
- Heat supply/water supply schemes.
- spatial search;
- display of territorial planning conflicts;
- linking documents and statuses to geometry.
Minimum:
Each object should have a georeference, a set of spatial attributes, and a related history of changes.
Housing and communal services: GIS, Public services, OSS, debt, technical condition
In the second part, the document very clearly formulates a target model for housing and communal services:
- OSS in electronic / correspondence format with GIS housing and communal services;
- Charges and payments are available through the state services;
- filing for collection of debt - in electronic form;
- digital accounting of housing stock and technical condition;
- digital passports of municipal infrastructure;
- development of the “smart home”.
For our portal it means:
If we want to be a single portal, we must have not only a building block, but also an operating housing and communal services.
Modules are required:
- passport of the MKD / residential house;
- technical condition;
- overhaul;
- incidents and accidents;
- Interaction with the CC/RSO;
- accruals and notifications;
- treatment of residents;
- OSS;
- Debt and claim block;
- public infrastructure and electronic passport of the object.
Key idea:
Construction and housing are already considered as a single digital chain, not two independent industries.
Artificial Intelligence
The document expressly provides for the introduction of AI:
- to evaluate the developer;
- analysis of reporting;
- predictive analytics of timing failure;
- analysis of construction photos;
- support of expertise;
- processing of anonymized data;
- development of industry services.
How to adapt the system correctly: do not start with a “chat bot for the sake of a tick”. You need to build an application AI on quality data.
Priority AI scripts for the portal:
- Predictive risk of failure of deadlines;
- checking the completeness of documents;
- search for contradictions and conflicts in data;
- Intelligent routing of applications;
- analysis of photo fixation of the progress of work;
- Tips for the inspector/expert;
- search for anomalies on accruals / accidents / housing and communal services;
- smart search for regulations and documents;
- NLP - analysis of incoming calls and automatic categorization.
But first the base:
- single directories;
- clean data;
- Structured events;
- storage of impersonal datasets;
- MDM/NSI.
Import substitution and technological independence
The document directly says that the use of Russian software and hardware is the main priority. What this means for the system:
- conduct an audit:
- OS;
- DB;
- brokers;
- GIS-stack;
- BIM-viewer;
- ECM/EDO;
- CI/CD;
- monitoring;
- cryptography;
- office converters;
- integration tires.
- Create a matrix:
- critically dependent on foreign software;
- can be replaced quickly;
- can be left temporarily in an isolated circuit;
- It requires re-design.
At the architectural level:
The portal must be vendor-resilient, otherwise, after 1–2, any integration will run into incompatibility or regulatory restrictions.
What should be the target architecture of the portal
I recommend a target model of 8 layers.
Layer 1. Single Object Core
- OKS
- Land plot
- MCD / Housing Fund
- the Communal Infrastructure
- Participants
- documents
- Events
- statuses
- Geodata
Layer 2. Process Engine
- BPM / workflow
- Routes of coordination
- SLA
- regular terms
- Escalation
- Completeness Checks
Layer 3. Documents and machine readability
- templates XML/JSON
- Versionality
- electronic forms
- Printable forms
- EP
- Archive of legally significant actions
Layer 4. Integration layer
- API gateway
- ESB / event bus
- Integration with external GIS/registries
- Data Showcase
- subscription to events
Layer 5. Spatial layer
- map
- Geoobjects
- Spatial requests
- Thematic layers
- map binding with processes
Layer 6. BIM/TIM layer
- Models
- viewer
- Version
- elements
- connection with acts, regulations, expertise
Layer 7. Analytics and AI
- KPI
- monitoring
- Forecasts
- risk-scoring
- Requirements based on anomalies
Layer 8. UX-layer roles
- citizen
- Developer
- Designer
- Contractor
- Inspector
- Expert
- Authority
- UK / RSO / Housing and Utilities Operator
What modules should be added or reworked first
Block A. Construction
- Register of objects and participants
- Personal office of the professional participant
- Digital Statements and Routes
- Executive documentation in structured format
- BIM/TIM module
- Construction monitoring
- Integration with expertise and supervision
- Superservice for IHS and mass services
Block B. Utilities
- Passport MCD / Housing Fund
- Digital passport of municipal infrastructure
- Incidents / accidents / dispatching
- OSS
- Accruals / notifications / payment circuit
- Debt contour and electronic recovery
- CC/RSO/Municipal Cabinets
- Module “smart home / IoT-ready”
Block B. End-to-end components
- NSIs and classifiers
- API and integration bus
- Geoplatform
- Event Storage
- BI and KPI
- AI-services
- Audit, Security, EP, Action Log
KPI, to which the system should be oriented
The document itself tells you what indicators should lie in your dashboards:
- the share of data transferred from regional GISOGD to the federal contour;
- the share of positive expert opinions on documentation in the form of an information model;
- share of digital OSS;
- the proportion of payment documents available electronically;
- the number of entities where there is electronic debt collection;
- IQ of cities and indicators of digital maturity.
For an internal portal management model, I would add:
- share of end-to-end services without paper;
- Percentage of structured documents;
- the proportion of objects with a through ID;
- the proportion of objects with geolinking;
- the share of objects with BIM/TIM;
- average time of the route;
- number of returns due to incompleteness;
- accuracy of the predictive model by the time;
- The percentage of integrations operating through API without manual exchange.
The main gaps that are almost certainly there now
With a high probability, most of these systems have 7 typical problems:
- the system is built around statements, not around the object;
- data lives in documents, not in entities;
- integration point and fragile;
- there is no single map and object connectivity;
- BIM/TIM is either missing or decorative;
- HQ-contour is not associated with the construction site;
- no normal data layer for AI and monitoring.
If this is the case, then it is pointless to refine the interface until the foundation has been redesigned.
Practical adaptation: a plan by stages
Stage 1. 0–3 months
- conduct architectural gap analysis by order;
- describe the target process map;
- select the object core;
- approve NSIs and cross-cutting identifiers;
- determine the list of primary XML / machine-readable templates;
- Create a map of mandatory integrations.
Stage 2. 3–6 months
- launch the register of objects and participants;
- Transfer key services to native digital forms;
- implement an event model;
- deploy API gateway;
- make the base GIS-layer;
- Implement the supervisor's dashboard.
Stage 3. 6–12 months
- connect BIM/TIM module;
- implement digital executive documentation;
- run the OSS module and the housing and utilities passport;
- make a digital contour of accidents / incidents;
- Include risk-scoring and smart completeness checks.
Stage 4. 12–18 months
- launch predictive analytics for construction;
- withdraw the electronic recovery and the associated process unit;
- scale integration to the entire regional contour;
- prepare anonymized data storage under AI;
- Translate the manual to KPI from the system, not Excel.
My direct recommendation for our system
If we adapt briefly and without bureaucracy, then we need to make 5 strategic reversals:
1. From the service portal to the object life cycle platform.
2. From file archive to structured data system.
3. From a set of cabinets to a single digital outline of participants.
4. From manual control to monitoring and predictive analytics.
5. From the “digitalization of the showcase” to the digitalization of the process core.
Result
Orders don’t just update goals. It actually fixes a new standard of the industry IT system:
- a single environment;
- machine-readable data;
- TIM/BIM;
- Integration;
- spatial layer;
- digital housing and communal services;
- AI;
- import substitution;
- customer-centricity.
For a single construction portal, this means one thing:
The system should be developed not as a public services site, but as an industry digital platform for managing construction and operation.