Skip to content
Use case 03 · Engineering / Design

Code and specification compliance assessment

A workflow that holds code editions and their applicability, retrieves the source clauses, maps your evidence against them and detects conflicts and gaps. It produces a clause-by-clause matrix that a responsible reviewer approves. It never announces compliance on its own.

Runs standaloneUploads and manual entryResponsible reviewer signs
Workflow 03 · demo runAwaiting sign-off

Compliance engineerRequirements arrive from different code editions, project specifications and authorities, and they contradict each other more often than anyone admits.

  1. Set editions and applicabilityEngineer
    QueuedWorkingDoneSign-off
  2. Retrieve source clausesAutomated
    QueuedWorkingDoneSign-off
  3. Map the evidenceEngineer
    QueuedWorkingDoneSign-off
  4. Detect conflicts and gapsAutomated
    QueuedWorkingDoneSign-off
  5. Record an approved assessmentReviewer
    QueuedWorkingDoneSign-off
Stopped for the responsible reviewer to sign
  • Who uses itCompliance engineer, responsible reviewer, technical approver
  • Lifecycle stageEngineering / Design
  • Buyer groupTrack A · Engineering & Design
  • RequirementsBRD v0.1, sent as written
At a glance

What goes in, what comes out

Goes in
Code editions
Project specification
Evidence
Code & Specification ComplianceFive steps · one approval gate Responsible reviewer signs
Comes out
Compliance matrix
Exceptions
Evidence links
Approved interpretations
What it does

Code & Specification Compliance, step by step

Five steps, one decision point. The last step is a person, every time.

  1. 01
    Engineer

    Set editions and applicability

    Which code, which edition, which parts apply to this project — recorded, not assumed.

  2. 02
    Automated

    Retrieve source clauses

    The actual clause text pulled in, so an assessment is read against the source rather than a paraphrase.

  3. 03
    Engineer

    Map the evidence

    Drawings, calculations, data sheets and statements attached to the clauses they answer.

  4. 04
    Automated

    Detect conflicts and gaps

    Where the specification and the code edition disagree, or where a clause has no evidence at all.

    Do the sources agree?

    Yes Clause mapped to its evidenceNo Precedence clarification requested
  5. 05
    Reviewer

    Record an approved assessment

    The reviewer's interpretation of each exception, with reasoning, signed.

  6. Output

    What lands at the end

    A clause-by-clause compliance matrix with exceptions, evidence links and approved interpretations, exportable for the project record.

Who’s involved

Compliance engineerResponsible reviewerTechnical approver

What you get

  • Compliance matrix
  • Exceptions
  • Evidence links
  • Approved interpretations

In the wireframe

Two source excerpts side by side, a precedence clarification requested, and the engineer's disposition recorded. No compliance verdict is announced.

Use case diagram

Who does what, and who signs

Automated steps prepare the evidence. People make the calls.

Swipe to see the whole diagram

Use case diagram: Code & Specification Compliance People: Compliance engineer, Responsible reviewer, Technical approver. Steps: 1 Set editions and applicability; 2 Retrieve source clauses; 3 Map the evidence; 4 Detect conflicts and gaps; 5 Record an approved assessment. Responsible reviewer approves the final step. Code & Specification Compliance«workflow, built with DeX»«inputs»01 Set editions and applicability02 Retrieve source clauses03 Map the evidence04 Detect conflicts and gaps05 Record an approved assessmentCompliance engineerTechnical approverResponsible reviewer«approves»«documents»Code editions, …
Automated step Done by a person Approval gate Takes part Leads to
What changes

Why this costs you time today

Requirements arrive from different code editions, project specifications and authorities, and they contradict each other more often than anyone admits. Assessing clause by clause is slow, and reproducing last month's assessment is slower.

Task
Today
With this workflow
Reading clauses
From memory or a paraphrase
The source clause text, pulled in
Conflicting editions
Quietly resolved by whoever noticed
Raised, clarified and dispositioned
Re-running an assessment
Start again from scratch
Reproduced from the stored evidence
The line we do not cross

What this software will not do

Life-safety work. These limits are written into the requirements, not added as a disclaimer.

Specific to this workflow

This is the workflow where the limit matters most. The matrix shows evidence and conflicts. It does not conclude that a project complies, and an approval recorded in it is not consent from an authority.

It does not decide compliance

The software assembles evidence, retrieves source clauses and shows conflicts. It does not determine whether anything complies. A named engineer does.

It does not stand in for an authority

An approval recorded in the software never implies consent from an AHJ, Civil Defence, building control or a building surveyor.

Nothing leaves without a named reviewer

Every output carries who approved it. Anything unverified keeps a draft marker until someone signs it.

It does not do sealed engineering

Hydraulic network calculation, definitive sprinkler layout, sealed design, BIM geometry authoring and final cost estimates are all out of scope by design.

Your standards, not ours

NFPA, EN, BS, ISO, FM, UL, LPCB and Civil Defence appear in the requirements as examples. None is assumed to apply to your projects until you say so.

~1/10of traditional build time
~30%of traditional cost

That is a claim about how fast Colakin builds software with DeX, and it is supported by delivered projects. It is not a claim about what any of these fifteen workflows will save your business. The requirements deliberately leave that to a pilot, measured against your own baseline.

How an engagement runs

From a question to a pilot, in five steps

Nothing hidden behind a discovery call. Stop at step one and keep the document.

  1. 01

    You ask for the requirements document

    The full BRD for the workflow you care about, sent as written.

    Same day
  2. 02

    A ten-minute wireframe walkthrough

    A clickable prototype of that one workflow.

    10 minutes
  3. 03

    The Fire Fit Check

    Five questions: fit, hours lost, who approves spend, whether your documents can be shared, and timing.

    One call
  4. 04

    A scope built on your rules

    Your standards, your document formats, your approval gates.

    Within a week
  5. 05

    A pilot against your own baseline

    One workflow, your data, your engineers.

    Q1
Questions

Code & Specification Compliance: questions

Does the software say whether we comply?
No, and the requirements say so explicitly. It assembles evidence, retrieves clauses and shows conflicts. Determination is the responsible engineer's, and the record names them.
Does an approval in the system mean the authority has approved?
No. Approval inside the workflow is an internal engineering sign-off. It never implies AHJ, Civil Defence, building control or building surveyor consent.
How are conflicting editions handled?
Both are held with their applicability. Where they disagree the conflict is raised, a precedence clarification is requested, and the reviewer's disposition is stored with its reasoning.
Can we reproduce an assessment a year later?
That is the point of the evidence links. The matrix holds the clause text used, the evidence attached, the interpretation applied and who approved it.
Next step

Ask for the Code & Specification Compliance requirements document

The business requirements document as written, including what it refuses to do. No brochure, no drip sequence.

  • The requirements document, usually the same working day
  • A ten-minute wireframe walkthrough with the people who specified it
  • No claimed percentage saving — your pilot measures it

Request the document

One working day. A person replies, not a sequence.

We use this to reply, nothing else. No list, no newsletter.