KhML
KhML - Explanatory Note XML
The KhML project: from a design documentation set we build machine-readable XML per the Ministry of Construction / EGRZ XSD. Stage 1 is open now - a working MVP without a public link. Three more product stages follow.
1 of 4 · MVP
Stage
Web app
Format
Explanatory note XSD
Schema
MVP only for now
Link
- 01 · Client
The client prepares design documentation packages for expert review and submission to systems where the explanatory note is needed not as "PDF text" but as valid XML against the Ministry of Construction schema (EGRZ / ECPE, the Russian state construction registry and…
- 02 · Challenge
Build valid XML not from the explanatory note alone but from the full data set (participants, design documentation, SIG signatures, hashes, land plan / technical conditions / source data).
- 03 · Solution
Stage 1 (MVP) - in progress / delivery per spec: an end-to-end scenario "design documentation set → extraction and manual review → documentation + SIG + hashes → programmatic XML generation → XSD validation → download".
- 04 · Result
Stage 1 result: a working MVP pipeline for preparing valid explanatory note XML against the agreed XSD (no public URL).
AI converter of construction documentation into valid explanatory note XML
About the client
The client prepares design documentation packages for expert review and submission to systems where the explanatory note is needed not as "PDF text" but as valid XML against the Ministry of Construction schema (EGRZ / ECPE, the Russian state construction registry and expert-review systems).
The explanatory note alone is not enough: the XML requires participant details, specialists and registries, design documentation volume files, SIG signatures, checksums, land plan, technical conditions and source data. Assembling such a package manually is slow and error-prone.
We are not publishing a public URL yet: the product is at the MVP stage, and the case describes the core and the four-stage roadmap.
The challenge we started with
- Build valid XML not from the explanatory note alone but from the full data set (participants, design documentation, SIG signatures, hashes, land plan / technical conditions / source data)
- Combine OCR, AI extraction and mandatory manual verification of fields against their source
- Generate XML with program code against the XSD - not "free-form" neural network generation
- Allow changing the XSD version without recompiling, and a path to SaaS in stages 2–4
Stage 1 · MVP (current)
End-to-end pipeline: admin login → project → document set upload (explanatory note PDF/DOCX, scans, land plan, technical conditions, source data) → OCR → extraction of key fields with source and confidence → manual review/edit → upload of design documentation volumes and SIG signatures → matching and checksums (Streebog) → programmatic XML assembly against the XSD → XSD validation and preflight → XML download. "Build on, don't rebuild" architecture: AI extraction is separate from the XML generator and validator; files go through a storage layer; data is tied to organization_id even with a single user.
Stage 2 · commercial layer (planned)
Per the spec: organizations and users, roles, plans/billing/payment, extended user account and admin panel, groundwork for e-document exchange and operations. Not part of MVP acceptance - it will appear in the case after the stage scope is agreed.
Stage 3 · integrations and legally significant layer (planned)
Deeper work with signatures/CryptoPro, exchange automation and stricter personal data requirements (Russian personal data law 152-FZ) in the live environment. Details and criteria will be agreed separately; we will update the case text after release.
Stage 4 · scale and schema versions (planned)
Multiple organizations, limits, monitoring, support for updatable Ministry of Construction XSDs as a "schema file" without rewriting the core, reports and support. We will extend the case as deliveries ship.
How it works
User scenario
- Creates a project and uploads the design documentation set
- Reviews the suggested fields: confirms, edits or enters them manually
- Uploads design documentation volumes and SIG signatures, sees matching and checksums
- Starts XML generation and, if needed, reviews validation errors
- Downloads the XML that passed XSD validation
Team / admin scenario
- A single administrator account at the MVP stage
- Versions of documents and XML artifacts in the project card
- Field registry / mapping / XSD version on the backend (not only in the UI)
- Acceptance test protocol and instructions for extending to stage 2
Technology
- Documents
- PDF/DOCX parsing, scan OCR, document versioning
- AI layer
- field extraction + source; LLM via an adapter (including a Russia-based environment compliant with 152-FZ)
- XML
- programmatic assembly against the XSD + server-side XSD validation (including groundwork for 1.1)
- Files / SIG
- design documentation volumes, CAdES detached SIG, GOST R 34.11-2012 (Streebog)
- Architecture
- extraction / review / XML / validator modules; organization_id; swappable XSD
Timeline: Stage 1 · MVP (45 days per spec) → stages 2–4
Result and business effect
Stage 1 result: a working MVP pipeline for preparing valid explanatory note XML against the agreed XSD (no public URL). Core criteria: scan OCR, AI/rules for fields with a source and manual verification, design documentation and SIG files, checksums (GOST R 34.11-2012), XML generated by code (not a "free-form" LLM answer), server-side XSD validation. Stages 2–4: the description will appear after agreement and delivery - no invented metrics.
A fit if you need
- You need to assemble industry XML/packages against a strict XSD, not a "nice chat with files" - AI agents
- Your documents are mixed: text, tables, scans - you need OCR + human verification - Web applications
- You plan an MVP now and SaaS/e-document exchange later without rewriting the core - CRM and ERP
Frequently asked questions
Questions about this type of project, the same ones clients ask before a similar build.
What about bad scans?
Before we start, we take a sample of your real documents, including the worst ones, and see what gets recognized. A field read with low confidence never moves on without a person. If a scan is unreadable, we’ll say so plainly: it needs a rescan.
Can the model get a total wrong?
It can, which is why we never rely on the model alone. Every field is tied to a spot in the document, totals and requisites are checked by rules, and a person reviews anything in doubt. In the XML project for construction documentation, the model only suggests fields; the XML itself is assembled by code against the XSD schema.
How is this different from plain OCR?
OCR gives you text. You need fields: who the supplier is, the total including VAT, which contract the invoice belongs to. AI extracts them from the recognized text, then rules check the result.
Where are the documents stored?
Depends on the setup. In the cloud version, on the project server. If documents contain personal data or trade secrets, we deploy everything on your servers and connect the model so data never leaves the perimeter. The architecture is designed for 152-FZ.
Need an XML/AI pipeline for an industry schema?
We will build an MVP with XSD validation and lay the architecture for SaaS, e-document exchange and the next stages - as in the KhML project.
FAVORIT
SaaS cost estimation from drawings
Upload a drawing, multi-agent calculation, and a document pack. 5+ months, two stages.
JimmyNeuron Marketing
Системный маркетинг
Реклама, сайты, CRM и сквозная аналитика в одной команде с разработкой. От аудита ниши до потока заявок.
B2C NDA
AI tutor for kids
AI tutor MVP: homework, progress control, and a question bank by subject.