Author supervision vs. technical supervision: who signs off on what, and when

Author supervision (авторский надзор) is the designer confirming the as-built work matches the approved design; technical supervision (технический надзор) is the client-side quality control that accepts hidden works, runs safety checks, and verifies lab results before construction proceeds. They are two different roles, held by two different parties, checking two different things — and conflating them is why field oversight commonly ends up on paper, disconnected from the project, the drawings, and the quality system.

Author supervision: the designer's confirmation

Author supervision is the record of the designer's ongoing site oversight against their own approved design:

• A field-supervision log (журнал авторского надзора) — the designer's running record of site visits and observations, per project.
• Field change orders, issued by the designer against the specific affected work-breakdown node and drawing, routed for acknowledgement and e-signed — not a note in an email.
• Design-deviation reports comparing as-designed to as-built, with a disposition of use-as-is, rework, or redesign. A major deviation can raise a non-conformance automatically, traced back to the deviation that caused it.

The designer is answering one question: does what got built match what was approved, and if not, what's the disposition.

Technical supervision: the client-side gate

Technical supervision is the client's own quality control over the contractor's work, and it gates progress rather than just recording it after the fact:

• Inspection acts, including АОСР (акт освидетельствования скрытых работ — hidden-works acceptance) — evidence-backed with photos. An accepted act is what allows covering work to proceed; a rejection keeps that part of the work blocked until it's resolved.
• Safety checklists on site, where a failed check can raise a non-conformance.
• Lab-test verification — a material test is requested against a specific lab test execution, and a non-conforming result raises a non-conformance automatically, traced to the material and the work it was for.

The technical supervisor is answering a different question: is this specific piece of work acceptable to proceed past, cover up, or rely on.

Why the distinction matters operationally

Confusing the two roles — or running both on paper with no link to the actual project structure — produces the same failure mode either way: a deviation, a failed check, or an unverified material gets buried in a physical folder of acts, disconnected from which work-breakdown node it applies to, which drawing it references, and which quality record it should have triggered. Tying every field change order, inspection act, and lab verification to the specific project node and document it concerns — rather than to a generic project file — is what makes "who signed off on what, and when" answerable after the fact instead of reconstructed from memory.

Where the two connect

An author-supervision deviation report and a technical-supervision inspection act are not competing records — they can reference the same work-breakdown node from two different vantage points (design intent vs. acceptance-to-proceed), and either one failing is what should raise a non-conformance, not a private judgment call by whoever noticed first.

Sources

• Mechanism basis: 02_Products_and_SaaS/e_pms.md (Author Surveillance, Technical Supervision sub-modules); standards basis PMBOK 7 / ISO 21500 / AACE International.
• Note: 03_Marketing_Engine/seo_semantic_core.md flags this exact terminology (author/technical supervision software) as having no distinct English-language market-size data as of 2026-07-07 — this piece is mechanism-driven, not benchmark-driven, by design.