AI speeds up standards compliance review when checks are split into three layers: rules verify formal requirements for title blocks, designations, and document completeness; computer vision reads drawings and scans; and a language model looks for semantic inconsistencies in the text and drafts comments tied to a specific clause of the standard. The standards reviewer remains responsible: under GOST 21.002-2014, comments related to violations of regulatory documents are mandatory, so every AI comment must be verifiable. The right project outcome is fewer missed errors and less manual cross-checking, not “fully automated standards compliance review without people.”
Prepared by AIrassvet and verified against public sources October 1, 2026. It is intended for chief project engineers, heads of design organizations and issue departments, standards reviewers, technical clients, and engineering design offices at industrial companies. The standard requirements are cited based on their published text and Rosstandart information as of the verification date; this is not a substitute for the official standard text and is not advice on project documentation review. The AIrassvet section at the end describes the publisher's services.
Contents
- What standards compliance review is and why it is a good fit for AI
- Standards: what to account for in 2026
- Three layers of automated review
- What rules check
- What computer vision checks
- What the language model checks
- Solution architecture
- Risks and limitations
- Step-by-step implementation
- How to measure quality
- Frequently asked questions
- Primary sources and verification method
What standards compliance review is and why it is a good fit for AI
Standards compliance review — the review of documentation for compliance with standards and other regulatory requirements before release. For construction, the procedure is defined by GOST 21.002-2014; for design documentation in mechanical engineering and instrumentation, by GOST 2.111-2013. The standards reviewer checks completeness, correct formatting, designations and title blocks, references to regulatory documents, consistency between specifications and drawings, and much more.
This work is well suited to automation for three reasons:
- A large share of formal checks. Designations, title block fields, completeness, signatures — these are rules that can be described algorithmically.
- Many cross-references. Specification items must match the drawings, schedules must match the explanatory note, and references must point to valid documents.
- Recurring errors. Typical comments from past reviews repeat from project to project, and a system can be trained on them.
But part of the review requires engineering judgment, and a comment without a reference to a standard has no force. That is why AI in standards compliance review is an assistant that prepares a list of possible comments, not an autonomous reviewer. A general overview of AI use in the industry is in the article AI in Construction.
Standards: what to account for in 2026
| Standard | What it establishes | Why it matters for automation |
|---|---|---|
| GOST 21.002-2014 | Tasks, content, and procedure for standards compliance review of design and working documentation for construction; a list of checks for design, text, graphic documentation, and tables; the rights of the standards reviewer | The list of checks in Section 5 is a ready-made foundation for a rules catalog |
| GOST 21.002-2014, Section 7 | The list of comments must include a reference to the standard or another regulatory document; comments related to violations of current regulatory documents are mandatory | Every AI comment must include a reference to the clause of the standard, otherwise it must not be issued |
| GOST 2.111-2013 | Standards compliance review for ESKD design documentation: compliance of designations, completeness, title block, abbreviations, references to standards, signatures | The same approach applies to industrial companies’ design documentation |
| GOST R 21.101-2026 | General requirements for design and working documentation; approved by Rosstandart Order No. 129-st dated 02/12/2026, effective April 1, 2026, and replaced GOST R 21.101-2020 | The formatting rules used by automated review need to be updated for the new revision |
According to the overview of changes to GOST R 21.101-2026, the new revision strengthens requirements for electronic document formats, introduces QR codes, barcodes, and globally unique document identifiers, allows text documents to be prepared without frames and title blocks, and introduces new document codes. For automation, this means the rules catalog configured for the 2020 revision needs to be revised, and the system must understand which revision a specific set was prepared under. Before configuring rules, check the official standard text.
Three layers of automated review
| Layer | What it uses to check | Check examples | Reliability |
|---|---|---|---|
| Rules | Deterministic algorithms on structured data | Filling in title block fields, designation format, completeness against the schedule, references to superseded standards | High: the result is reproducible |
| Computer vision | Recognition of drawings, scans, tables | Presence of a stamp and signatures, legibility, symbols, drawing positions | Medium: depends on file quality |
| Language model | Semantic analysis of text with a search through the standards database | Discrepancies between the explanatory note and schedules, incorrect units, contradictions between sections, drafting a comment with a citation | Requires human review |
Distribution principle: anything that can be checked by rule should be checked by rule. A language model is used where meaning matters, and always with result verification.
What rules check
Rules are the foundation of automated standards compliance review and its most reliable part. If documentation is released electronically from CAD or a document management system, many attributes are available in structured form. A typical rules catalog includes:
- Title block: required fields are filled in, the designation matches the organization's designation system, and the names in the stamp and in the schedule match.
- Completeness: all documents listed in the schedule of referenced and attached documents are present, and page numbering is continuous.
- Designations and codes: designation format, document codes, including new codes under GOST R 21.101-2026.
- References to standards: each referenced standard or code of rules is in the registry of active documents; canceled and superseded ones are identified automatically.
- Signatures and electronic format: the presence of signatures or a certification sheet, and the correctness of the electronic document’s metadata.
- Units and abbreviations: permitted units of measurement and abbreviations from the list.
The registry of active regulatory documents is a separate project asset. It must be kept up to date; otherwise, the rules will start missing references to superseded standards.
What computer vision checks
Project documentation often arrives as PDF, while archived sets come in as scans. Computer vision solves tasks that rules cannot handle:
- it recognizes stamps, tables, and schedules on sheets and turns them into structured data for the rules;
- it finds position designations on the drawing and matches them to the schedule;
- it checks for signatures, stamps, and required formatting elements;
- it identifies unreadable or damaged sheets.
Recognition quality depends on the source files: a vector PDF from CAD is processed far more reliably than a scan. For approaches to document recognition, see the article OCR and Document Recognition for Business.
What the language model checks
A language model is useful where checking requires reading and comparing meaning:
- Consistency across sections. The technical solutions in the explanatory note match the bill of materials and specifications, and equipment names are consistent across the entire set.
- Relevant references. A reference to a standard clause really applies to the solution being described.
- Terminology and units. Consistent terminology, correct units of measurement in the text.
- Drafting comments. The model prepares the comment text in the organization’s style, with a reference to the applicable rule clause from the database.
To keep the model from inventing requirements, it works only with the regulatory document base through search (RAG) and must cite the found clause. For more on the approach, see the article RAG System for Business.
Example instruction for drafting a comment:
You are assisting a standards reviewer. You are given a document excerpt and the found clauses of regulatory documents.
1. Draft a comment only if the excerpt violates the clause shown.
2. Specify the sheet, location, and the violating quote.
3. Specify the standard and clause the comment refers to. Do not use rules that are not in the list.
4. If you are not confident, return the CHECK label and explain what needs to be verified.
Rules clauses: {norms}
Excerpt: {fragment}Solution architecture
- Intake of the set. Documents are uploaded from the document management system or CAD system together with metadata: stage, discipline, standard revision.
- Data extraction. Parsing vector PDFs and CAD files, recognizing scans, extracting stamps, tables, and text.
- Rules engine. A catalog of checks for GOST 21.002-2014, GOST R 21.101-2026, and organizational standards.
- Regulatory document database. Current standards and codes of rules with versions and statuses, plus an index for search.
- Semantic checks. A language model with access to the regulatory base and mandatory citation.
- List of comments. A consolidated list with the source, the rule reference, confidence level, and a note on who found it: rule, vision, or model.
- Standards reviewer workstation. The standards reviewer approves or rejects comments; rejections are saved to improve the system.
If the organization already has a corporate knowledge base, it is convenient to build the regulatory document database in it — see the article Corporate Knowledge Base with AI.
Risks and limitations
| Risk | How it shows up | How to reduce it |
|---|---|---|
| Invented requirement | A comment citing a nonexistent clause | Citations only from the regulatory base, and rule-based verification of the reference |
| Outdated database | Checks against a superseded revision, for example GOST R 21.101-2020 instead of 2026 | Registry of active documents with an owner responsible for updates |
| False comments | Too many unnecessary comments; the standards reviewer stops trusting the system | Confidence threshold, analysis of rejected comments |
| Missed errors | An error in a scan or nonstandard formatting is not recognized | Recall metric on a benchmark set, manual review of complex sheets |
| Blurred accountability | The document is released without human review | The standards reviewer’s signature remains mandatory; AI only prepares the list |
| Confidentiality | The client’s documentation is sent to an external service | Hosting models inside the organization’s environment, access control |
Step-by-step rollout
Step 1. Choose the document type
Start with one discipline or document type with high volume and typical errors, such as the text section or specifications.
Step 2. Build a benchmark set
Take released sets with standards review comment logs. This is the best labeling: you know what a person found and where.
Step 3. Build a rule catalog
Translate the checks from GOST 21.002-2014 or GOST 2.111-2013 and organizational standards into a formal list, taking into account the changes in GOST R 21.101-2026.
Step 4. Prepare the rule base
Collect the active regulatory documents with versions and statuses, and assign someone responsible for updates.
Step 5. Run a pilot alongside the standards reviewer
The system prepares a list, and the reviewer checks the package as usual and compares it. Record the findings that were identified, missed, and false positives.
Step 6. Embedding into release
Add automated checking to the release process: the designer receives the list before the package is handed over for review and fixes formal errors themselves.
How to Measure Quality
| Metric | How to Calculate | Why It Matters |
|---|---|---|
| Recall of findings | Reference findings found by the system / all reference findings | How many errors the system does not miss |
| Precision of findings | Confirmed findings / all findings produced by the system | Whether the system creates too many false positives |
| Share of findings with a referenced standard | Findings with a verified reference / all findings | Compliance with Section 7 of GOST 21.002-2014 |
| Package review time | Median before and after implementation | Time savings |
| Number of return cycles | Rework returns per package | Impact on release quality |
Calculate metrics separately by layer—rules, vision, and model—so you can see where the system is reliable and where it needs improvement.
Frequently Asked Questions
Can AI completely replace the norm reviewer?
No. AI can prepare a list of possible findings and perform formal checks, but responsibility for the review remains with the specialist. Findings under GOST 21.002-2014 must include a reference to the regulatory document, so a person verifies every system-generated suggestion.
Which norm-review checks are easiest to automate?
Formal ones: completion of the title block, designation format, package completeness, presence of signatures, references to canceled standards, and units of measure. These are more reliably checked by rules than by a language model.
What did GOST R 21.101-2026 change for automation?
The standard has been effective since April 1, 2026, and replaced GOST R 21.101-2020. It strengthens requirements for electronic documentation format, introduces QR codes and document identifiers, and allows text documents without frames and title blocks. The catalog of automated checks needs to be updated for the new revision.
Is AI suitable for reviewing scans and archived documentation?
Yes, but with limitations. Computer vision recognizes stamps, tables, and designations on scans, but the quality is lower than on vector PDFs from CAD systems. For scans, it is important to measure recall on a reference set and keep manual review for complex sheets.
Do you need to change the CAD system or document management system?
Usually not. The checking system works alongside existing tools: it receives the package, checks it, and returns a list of findings. The depth of integration depends on the formats your systems support.
Can AI-assisted norm review be used for design documentation?
Yes. GOST 2.111-2013 describes norm review for ESKD design documentation with similar checks: designations, completeness, title blocks, and references to standards. The architecture of rules, recognition, and language models can be applied to design documentation at industrial companies.
Source Documents and Review Method
Verified on October 1, 2026:
- GOST 21.002-2014 "SPDS. Norm review of design and working documentation" — tasks, list of checks, reviewer rights, and the procedure for findings.
- GOST 2.111-2013 "ESKD. Norm review" — definition and scope of norm review for design documentation.
- GOST R 21.101-2026 in the Rosstandart catalog — status: "active," approved on 12.02.2026 No. 129-st, effective April 1, 2026, replacing the 2020 revision.
- Overview of changes in GOST R 21.101-2026 — list of major changes, published March 16, 2026; use the official standard text to configure the rules.
The three-layer review model, architecture, sample instruction, steps, and metrics — editorial analysis by AIrassvet. Commercial automated norm-review systems were not tested for this article, and their speed-up claims are not included.
How AIrassvet helps automate norm review
If norm reviewers spend most of their time on formal checks and specification matching, it makes sense to start automation with one document type and a reference set of past findings. On the AIrassvet website, which also uses the name "AI Studio of Vladimir Lomtev," the following directions are described as applicable to this task:
- Recognition of drawings, title blocks, tables, and scans using computer vision.
- A regulatory document base for RAG, where the model formulates findings with a reference to the relevant clause.
- Deploying models on the organization’s own servers if the project documentation must not leave the secure perimeter.
- Audit of the norm-review process, building a reference sample, integration with document management, testing, and staff training.
The first step is to choose one document type, describe the current review process, data sources, constraints, and the criterion by which you will consider the pilot successful.
Bottom line: rules, vision, and the model under the reviewer’s control
AI for norm review works when each check is handled by the right tool: formal requirements by rules, drawings and scans by computer vision, and semantic inconsistencies by a language model with a standards database. The standards set the framework: findings must reference a regulatory document, and in 2026 the formatting rules were updated by GOST R 21.101-2026.
Start with one document type, build a reference set of past findings, measure recall and precision, and only then embed the check into release. That way, AI will take routine work off reviewers’ plates without lowering documentation quality.