Fire door detection and schedule matching

What AI fire-door detection should actually deliver

A useful drawing-review pipeline produces an opening register: each door instance linked to its plan location, schedule row and relevant project requirement. It identifies missing records, conflicting text and unresolved matches so the team can investigate them. A coloured symbol on a PDF is an aid to that review, not proof that a door has a particular tested performance.

For design coordination, the buyer is often an architect, design manager, fire-safety consultant or contractor managing repeated plan and schedule checks. For an existing building, the same register may help organise inspection records, but the evidence and responsibility are different. Agree which workflow you are commissioning before deciding what the model should return.

Floor Plan Analyzer is AxcelerateAI’s specialist drawing-intelligence practice. We fine-tune models on your drawing conventions and engineer the document routing, matching, review and export steps around your team. The workflow below is a scoping method, not a claim that every document type or asset platform is already integrated.

Keep document evidence and installed-door evidence separate

A plan can show an opening and its reference. A schedule can state a design rating. A strategy or specification can establish a project requirement. None of those records, on its own, establishes the current condition of the installed assembly. Keep the evidence classes separate in the output rather than collapsing them into a single compliant flag.

UL Solutions’ application guide treats the frame, door, hardware, glazing and other accessories as parts of an assembly and discusses certification markings and installation instructions. That is why a schedule value is only one part of the evidence a reviewer may need. The guide’s North American certification context should not be silently translated into another jurisdiction’s terminology.

Intertek’s October 2026 inspection guidance describes checks of the installed opening, including condition, components, labels and operation. Those observations cannot be obtained from a floor-plan symbol. A document-review export should leave physical inspection unverified unless appropriate inspection evidence is supplied and reviewed.

References: UL Solutions: doors, windows and related hardware application guide; Intertek: fire-door inspections and field labeling (9 October 2026)

Begin with an issued document register

Request the floor plans, door schedule and its continuation sheets, relevant specifications, door-set details and the fire-strategy or compartmentation information the reviewer uses. Include the issue register and addenda. Record the project, building, level, sheet number, revision and issue status. Keep superseded documents available for traceability without treating them as current.

Document understanding comes before door detection. Shortlist plan views, schedules and requirement documents; separate legends, enlarged details and illustrative symbols from actual opening instances. OCR helps read titles, tags and table headings, but it cannot decide that an older issue is the approved design.

Agree a conflict process with the document owner. The extraction system should report both sources when a plan and schedule disagree. It should not choose the newest-looking date, substitute a familiar value or invent a contractual order of precedence.

Locate openings, then read their references in context

Locate door symbols and candidate openings on the relevant views. Preserve a bounding box or polygon with sheet/view coordinates and the detected tag. A room name, dimension or nearby annotation can resemble a door reference; use geometric context and the project’s conventions to propose the association.

A door type is not the same as a physical instance. A repeated type can describe several openings, and a paired opening can contain more than one leaf. Build identity from project, building, level and opening reference where needed. Do not merge different floors simply because both have a D-01.

Keep original OCR text, any normalised tag and the source crop. A substitution such as O for 0 can create a plausible but wrong join. Normalisation rules should be explicit and reversible; ambiguous alternatives belong in the review queue rather than being silently corrected.

Recover the schedule without losing its table structure

Read the row and column relationships, merged cells, repeated headers and continuation notes. Preserve the column label from which each value was taken. A figure under acoustic performance, a hardware-set number and a fire-related notation can all look like short codes; reading a string correctly is not enough if it comes from the wrong column.

Store the raw rating text and its evidence location. Only add a normalised field when the project reviewer has approved a mapping. Do not treat different national rating systems, smoke notations or test references as interchangeable because their labels contain the same number.

A blank cell is unknown until its meaning is resolved. A note may apply to several rows, or a table may use a symbol for not applicable. Record that interpretation rule and source. Absence of a detected rating is not evidence that the opening has no fire-related requirement.

Reconcile both directions and keep uncertain matches open

Join the plan instance to its schedule row using the scoped identity, then check completeness in both directions. A door on a plan with no row is a different exception from a schedule row with no plan instance. The latter may be an unused type, a different phase, an omitted view or a genuine coordination gap; the machine should not declare which explanation is correct without evidence.

Where references are unclear, retain the candidate matches and reason. One extracted row matching two distinct openings may be correct for a type schedule and wrong for an instance schedule. Document the schedule’s role before applying duplicate rules.

Keep matching confidence separate from evidence completeness and review status. A strong OCR score can coexist with an obsolete revision or a missing requirement document. Route those cases by their actual failure mode so the reviewer knows what to resolve.

Compare with explicit project requirements, not a universal wall rule

If the team wants requirement comparison, the responsible reviewer must identify the governing project documents and approve the rule set. Link a drawn compartment boundary or room relationship to that evidence; the geometry is a way to locate a candidate, not an independent source of a door rating.

In particular, do not copy a wall’s fire-resistance value into a door field as an automatic default. UL’s guide discusses distinctions between wall and opening-protective ratings within its applicable context. The engineering implication is to preserve the actual requirement source and its applicability rather than derive a universal formula from a coloured line.

Report text disagreement as a candidate discrepancy with both values and their source locations. A missing requirement is a missing-input exception, not a pass. If the scope includes escape-route analysis, validate the room graph, barriers and traversable connections separately; a straight line through a drawing does not establish a usable route.

References: UL Solutions: doors, windows and related hardware application guide

Worked example: four drawn openings, five review records

The following invented example uses a plan A101-R02, schedule A601-R02 and review matrix FS01-R02. The labels FD30 and FD60 are copied as raw fictional project strings, not prescribed ratings or a cross-jurisdiction mapping. The matrix is an assumed input provided by the example’s reviewer; no building-code requirement has been inferred.

The plan contains D-01 through D-04. The schedule contains D-01, D-02, D-03 and D-05. D-01 has agreeing text. D-02 has FD30 in the schedule and FD60 in the supplied matrix. D-03 has a blank schedule rating. D-04 has no schedule row. D-05 is a schedule-only record. The union is five review records: it is not a five-door plan count.

All five start as Needs review, including the agreeing record. The example contains one text agreement, one text conflict, one blank rating, one plan-only record and one schedule-only record. Those categories demonstrate reconciliation; they are not inspection findings, a real project result or evidence of model accuracy.

What belongs in the export and review queue?

A reviewer needs to move from a finding back to evidence without searching the entire set again. Export stable opening IDs, source tags, plan/schedule revisions and locations, raw text values, matched candidates, requirement references, discrepancy category and reviewer disposition. Include a separate inspection-evidence field if inspection records are in scope.

The downloadable five-row CSV mirrors the example. Blank values mean unknown or absent evidence as described in the finding, never a zero rating. Every inspection state is Not verified. It is an educational review register, not an installation certificate, statutory inspection form or approved remedial instruction.

For a production system, agree whether the destination is Excel, an asset register, a CDE issue list or an API. Validate the field mapping and identifier rules with its owner. Preserve source crops or links with appropriate access controls, and record who accepted a match or resolved a conflict. Approval should not erase the original machine proposal.

Manage revisions without losing the audit trail

Compare equivalent issue sets and retain the last reviewed baseline. A moved symbol, changed tag and replaced schedule row need different handling. If identifiers change, propose a link using the old and new evidence and ask for review rather than assuming that one door disappeared and another was created.

Generate a change list of added, removed, modified and unresolved records. Preserve accepted decisions that still apply, and reopen a decision when its evidence changes. Do not overwrite the released register or issue work orders merely because a new extraction run completed.

Define the handoff: who resolves document conflicts, who checks product evidence, who performs site inspection and who authorises any action. The pipeline’s history should show source version, extraction version, proposed finding and human disposition; it is a record of review, not a substitute for professional responsibility.

Where this workflow stops

In England, the government’s fire-door guidance distinguishes routine checks under the Fire Safety (England) Regulations from assessing inherent fire performance through the fire-risk-assessment framework. That guidance has a specific building and regulatory scope. This page does not set inspection intervals or give project-specific compliance instructions.

The relevant point for a drawing-intelligence buyer is the separation of activities. Document reconciliation can organise evidence and flag uncertainty. It cannot observe a closer, inspect damage or verify that an installed opening matches its supporting documentation. Commission the appropriate site and professional work through the people responsible for the building.

The same boundary applies commercially: do not call a text-agreement export a compliance certificate, a completed inspection or a list of doors safe to retain. The deliverable should state the documents reviewed, issue dates, exclusions, outstanding evidence and reviewer responsibilities.

References: GOV.UK: England fire-door guidance (updated 8 August 2025)

Evaluate a pilot on your difficult cases

Choose authorised, representative plans and schedules with your reviewers. Include repeated tags on different levels, paired openings, merged schedule cells, missing rows, unreadable text and conflicting issues. Reserve examples that were not used for training so the acceptance test can reveal failures outside the development sample.

Have reviewers establish the reference matches and finding categories. Measure detection omissions, duplicate instances, wrong joins, raw-text extraction and requirement-link errors separately. Include the effort needed to inspect crops, correct the register and import the export; a headline accuracy figure hides which task failed.

Agree acceptance criteria, data handling, retention, ownership, deployment and support before rollout. A successful sample extraction does not establish a measured production benefit. The pilot should provide evidence for the next decision, with unsupported document types and unresolved exceptions recorded.

• Agree document scope, jurisdiction/context and reviewer-provided rules.
• Create a reviewed reference register and hold out evaluation examples.
• Check instance identity, raw text, row joins and missing-evidence behaviour.
• Test actual review/export flow in a safe destination copy.
• Define release responsibility and re-review triggers.

Bring a sample set and the decisions you need to make

For a useful discovery discussion, prepare one authorised plan/schedule package, its issue register, the requirement sources your reviewers use and a sample of your desired register or issue format. Include a difficult example and an accepted manual review if available. Remove confidential details you are not authorised to share.

Leave your work email in the form at the top to arrange the next step. After a successful enquiry, you can choose an optional discovery-call time on Calendly. The email-only form does not submit a drawing. To share a drawing link immediately, use the existing drawing form below; we will scope the review workflow around your team’s requirements.

Sources and scope notes

Technical references checked 31 October 2026. The GOV.UK document is scoped to England and was updated 8 August 2025. The UL reference concerns its certification and application framework; Intertek’s inspection article is dated 9 October 2026. They support the evidence boundaries explained here, not a universal rating-conversion or code-check engine.

The proposed pipeline, example register and schematic are original educational material. No customer names, inspection outcomes, accuracy benchmarks or savings are invented. The separate door/schedule project linked below remains at its published stage; this guide does not turn it into a certified fire-safety deployment.

References: GOV.UK: England fire-door guidance (updated 8 August 2025); UL Solutions: doors, windows and related hardware application guide; Intertek: fire-door inspections and field labeling (9 October 2026)