Full Door Package Intake That Processes Hardware Schedules Elevations and Division 8 Specs in a Single Read

Full door package intake reconciles door schedules, elevations, partition schedules, floor plans, and the 087100 hardware specification in a single read. Full door package intake catches contradictions that no document reveals alone. Fresco’s published process treats simultaneous cross-document reconciliation as a structural requirement for a defensible Division 8 takeoff.

Why Division 8 bids fail at reconciliation, not at counting

One opening touches at least five document classes before an estimator has enough information to price it. The door schedule identifies it, elevations describe its door and frame types, and the partition schedule supplies wall data. Floor plans establish its location and handing, while the 087100 specification describes its hardware. Those documents can disagree even when each looks complete on its own.

Faster counting does not settle which hardware assignment to use when documents give different assignments for the same opening. Nor does it supply handing, leaf count, wall type, or existing-frame information when the architect leaves those columns out of the schedule. This distribution of information is a feature of how Division 8 documents are authored. Fresco’s published intake process is built around that constraint and does not examine any document in isolation. Even when extraction is accurate, an item can be missed at ordering if the documents are not checked against each other.

What the door schedule alone cannot tell an estimator

The door schedule is the starting point, but even that starting point may be spread across a package. Fresco’s intake description gives the example of one large hospital package with eleven separate schedules across multiple pages. Those schedules must be brought into one normalized table before reconciliation can begin. When each schedule is checked on its own, a door code that appears in more than one schedule can be missed, even though that code should refer to one opening.

Normalization establishes a common record, but it does not make missing information appear. The schedule pass identifies absent columns, including handing, leaf count, interior or exterior, STC, lead-lined, wall type, and existing frame. Each gap requires the document that actually contains the answer. Handing comes from the floor plan, leaf count from the elevation, and wall type from the partition tag at the opening, checked against the partition schedule. In Fresco’s simultaneous intake, the combined schedule table is therefore the prerequisite for comparison. A schedule reader returns what the architect tabulated, while a full-set reader can establish what remains unresolved.

Why elevations exist in the intake and what they resolve that the schedule leaves open

The elevations pass detects pairs for the count. A pair is one opening with two leaves, so an opening count and a leaf count answer different estimating questions. The schedule may identify the pair, but the elevation reveals it because both leaves are drawn. Reading that elevation against the schedule fills the leaf-count gap without treating the pair as two openings.

That distinction must survive into the output. By separating openings from leaf count in its counts export, Fresco makes the information revealed by the elevations available for estimating. The same pass normalizes door and frame types into a table. It supplies a structured view of hollow metal versus wood construction and frame profile where the schedule does not reliably provide one.

What the partition schedule contributes and where throat sizing lives

The frame must fit the partition at the opening, so it depends on wall information. The partition schedule pass normalizes wall code, description, total thickness, fire rating, STC rating, and stud information. The partition tag at the opening links that data to the door record. The door schedule or the elevation on its own gives only part of that link. Deferring it leaves frame specification dependent on information that has not yet been reconciled.

Stud information belongs explicitly in the table, but stud width is not frame throat size. The throat matches total wall thickness, which makes the distinction material to the frame specification. Similarly, a wall’s hourly rating is not the door’s label rating, so the two cannot be treated as interchangeable values. Total wall thickness is extracted when the architect provides it. When a partition has multiple layers of board and the set never states the total, that arithmetic remains the estimator’s responsibility. The intake makes the missing value visible rather than silently substituting stud width or an assumed total.

The floor plan pass as the only way to catch doors that exist in neither the schedule nor the elevation

The floor plan pass checks whether the normalized records match the openings drawn on the plans. It detects doors shown on the plans but absent from the schedule, as well as scheduled doors that appear nowhere on the plans. It also finds door codes that occur more often on the plans than in the schedule. An opening missing from both the schedule and the elevation cannot be discovered by comparing those documents alone. Finding it requires a detection pass through the plans.

A total can match the schedule exactly and still be wrong in two directions at once. A plan-only opening and a schedule-only opening can offset numerically without either record becoming correct. Matching totals prove less than a match at each opening. Fresco’s intake description also explains a more useful handoff for a scheduled code that the plans never show. Rather than stop at a missing-door flag, the system takes the estimator to the area where that door should be.

The two hardware set conflicts that live between the schedule and the 087100 spec

Neither of the two principal hardware set conflicts changes the number of openings. Both concern the relationship between the schedule’s assignment and the specification’s content.

The first conflict assigns the same opening to different hardware sets. Fresco’s published example places hardware group 107.3 in the door schedule and 107.4 in the specification for the same opening. Both values may be extracted correctly, but only one can govern that opening. The intake must surface the disagreement and retain both values. Deciding which document governs remains the estimator’s work.

The second conflict occurs when the schedule assigns an opening to a set that does not appear in the specification at all. Here, the door count is correct but the hardware behind the assignment is missing. The schedule can be internally consistent, and the specification can be internally consistent, because neither document alone contains the contradiction. Only the comparison exposes the absent set.

A further risk concerns how hardware quantities are reported per set. The convention is unsettled between the trade’s certifying body, its most-cited code authority, and its most-used software. Reversing that convention on a large project can multiply downstream quantities while leaving the arithmetic internally consistent. The relevant intake requirement is to recognize the convention.

What the intake produces as output and what remains the estimator's judgment

The takeoff has three Excel files for schedules, counts, and hardware. An issues report records every discrepancy found across the documents, and a marked-up PDF shows the plans. Together, these outputs separate the extracted quantities from the questions that still affect the bid. The deliverable is more than a populated spreadsheet because unresolved relationships remain visible.

Fresco’s published hospital example shows how an AI-assisted review list was cut down to the three or four openings with real problems. That is the useful boundary of automation, with extraction and formatting removed from the review while genuine conflicts remain for judgment. A disagreement over which hardware set governs does not become safe to automate simply because there are fewer such disagreements. The issues report is also a bid artifact because it documents assumptions and discrepancies in writing. Those records become clarification items in the bid letter rather than uncertainties left outside the submitted scope.

Where institutional owner standards make the intake more complex than document reading

Institutional work can change the task from extracting hardware sets to authoring them. When an owner standard governs, the project’s 087100 specification is not necessarily the sole authority. The estimator must know that the standard exists, locate it outside the bid set, and build conforming sets.

The University of Toronto’s door hardware standard, revised August 14, 2025, requires surface-mounted overhead closers that are all field serviceable. It requires Horton or Rhinotek operators for all doors. It also requires all cylinders for locksets to be supplied and installed by the University of Toronto Lock Shop. These requirements constrain hardware selection and responsibility, rather than merely describing a preferred format for the schedule. An intake that treats the project specification as complete authority can miss that distinction.

In its discussion of institutional intake, Fresco names Cornell, Michigan State, and a city fire station as examples where owner standards turn hardware-set extraction into authoring. Another institutional owner’s design guidelines also impose hardware constraints through panic hardware requirements and door-swing rules keyed to path of travel. The useful comparison is therefore between project requirements and owner requirements. Surfacing a conflict supports the estimator’s authoring work without pretending that extraction alone completes it.

How sequential, document-by-document intake tools handle these same documents

Reading one document at a time can help extract schedules, put specification content in order, and report what is in each file. Those outputs can reduce the work of reading and formatting. Their boundary is that a document-level result does not establish whether its contents agree with the rest of the package. That is a different output category.

A schedule table can faithfully retain a hardware reference whose set is absent from the specification. An elevation summary can correctly identify a pair without correcting the schedule’s leaf count. A plan count can match the schedule total while containing different openings. Sequential extraction only becomes reconciliation when those results are brought together and tested against one another. The meaningful criterion is therefore whether a workflow returns reconciled opening records and cross-document issues, or leaves the estimator to build those relationships after receiving separate document outputs.

What Fresco's full-package intake does across all five document layers

Fresco is built exclusively for Division 8, and its published intake process reads all five document layers in a single pass. It normalizes the layers into structured tables before cross-document reconciliation. The schedule establishes the opening records, elevations resolve pair status and door and frame types, and partition data supplies the wall information behind frame specification. The plan pass checks the records against the openings drawn, while the specification pass checks the hardware assignments against what is in each set.

That approach addresses the gaps left by separate document outputs without transferring the estimator’s decisions to the software. Its Excel takeoff, issues report, and marked-up plans help Division 8 contractors and estimators see both the quantities and the scope that is still unresolved. The distributor application is relevant too, with Fresco’s homepage carrying a commercial hardware supplier’s response that the platform could help it bid on more jobs. Its practitioner testimonials also emphasize time saved on manual work and the capacity of one person to get more done. The central test, however, remains the reconciled opening, with its counts, frame information, and hardware references assessed together rather than accepted because each source looks correct alone.