Blog › Compliance Checking

Fire and Acoustic Door Scheduling: Reconciling Tags, FRL and Rw

ParitySense team · September 2026 · 6 min read

A fire door schedule is compliant only if every door instance agrees across every document that describes it: the tag on the architectural plan, the row in the door schedule, the wall rating on the fire engineering drawing, and the hardware and certification requirements in the specification. Each document is maintained by a different author on a different revision cycle, and each records the same facts independently. That structure — one truth, four authors — is why door packages are the most reliably inconsistent part of a documentation set.

The facts that must line up

• The tag itself. D1.07 on the plan must exist in the schedule, once. Common defects: doors on plan missing from the schedule (added late, never scheduled), scheduled doors deleted from plan but not from the schedule, and tag renumbering at a revision that only some documents received.
• The FRL. The NCC notates fire resistance as structural adequacy / integrity / insulation in minutes — e.g. -/60/30. A door in a fire-rated wall must carry the rating the wall's classification requires; the deemed-to-satisfy provisions relate doorset ratings to the wall's FRL, and the fire engineer's documentation may vary them via a performance solution. The reconciliation check is blunt: does the schedule's FRL cell for D1.07 agree with the rating of the wall D1.07 sits in, on the current fire plan revision?
• The Rw. Acoustic separation — between sole-occupancy units, or unit-to-corridor — is scheduled as a required weighted sound reduction index. A door scheduled at Rw 30 in a wall the acoustic report requires to perform at a higher level is a defect that no site inspection will catch, because nothing looks wrong.
• The combination. Fire and acoustic doors are a distinct product class. A schedule that upgrades the FRL at Rev D but drops the Rw column entry for the same door has silently converted a fire-acoustic doorset into a fire-only one. Combined requirements are where single-attribute checking fails.
• Self-closing and hardware. Fire doors are generally required to be self-closing or automatic-closing; the schedule's hardware set and the spec's certification requirements (test evidence for the doorset as installed) must not contradict the drawing's door type.

How the drift happens

The canonical sequence: the fire engineer reissues their layout at Rev C, upgrading a corridor wall from -/60/- to -/120/-. The architect updates the wall type on the plans at the next issue. The door schedule — a separate sheet, often a separate file — keeps its old cells, because the person updating wall types was not thinking about doors. Three documents now disagree, and two of them are internally consistent, which makes the error look like a fact. If the schedule change also arrives without a revision cloud, the review process built on clouds never looks at it — the general mechanics of that failure are in unclouded revision changes.

Running the reconciliation

1. Extract every instance. Every tag from the plans; every row from the schedule; every rated wall from the fire drawings; every doorset clause from the spec. This is tedious by hand and mechanical for software.
2. Match on tag. Plan tags to schedule rows, one-to-one. Orphans in either direction are findings before any rating is compared.
3. Compare the ratings. For each matched door: schedule FRL vs the wall rating on the current fire plan revision; schedule Rw vs the acoustic report's requirement for that separation; hardware and closer against the spec. Record each mismatch with the documents, pages and values cited — a finding you can hand a certifier, not a highlighted PDF.
4. Re-run on every relevant revision. The check is only valid for the revision pair it was run on. A new fire plan revision invalidates the FRL comparison for every door on it. This is why the check belongs in the automated pipeline, triggered by document changes, rather than in someone's calendar — the pattern the ParitySense discipline checks implement.
5. Resolve by RFI, not assumption. When schedule and fire plan disagree, the wall requirement usually governs practically, and the contract precedence clause governs formally — but the answer on the record should come from the fire engineer, via an RFI citing both documents. Never resolve a rating conflict by picking the higher number and moving on; the performance solution may say something neither document shows.

What good looks like

A door package that survives certification review has: a schedule whose tag list matches the plans exactly; FRL and Rw columns that trace to the current fire and acoustic documentation; a record of every mismatch found, who resolved it and how; and re-checks logged against each revision that touched the package. The last item is the one manual processes never produce — and the first thing an auditor of the whole compliance process asks for.

FAQ