The costly revision error is rarely a missing PDF. It is an obsolete dimension, hand, glass build-up or finish remaining available where someone believes it is the current instruction.
A revised elevation changes four window hands and one glass build-up. The drawing portal shows the new PDF, but the factory has printed the old sheet, the hardware order came from a prior schedule and the packing label template still carries the old mark note. No one is careless; the project simply treated document issue as if it automatically updated every production-facing record. Revision control works only when it controls the information at the point of use and makes superseded information visibly unusable.
Document-control boundary: This guide does not define a contract’s submittal procedure, decide whether an approval is legally binding, select a document-management platform or replace the project’s BIM/CDE protocol. The applicable contract, information protocol and authorised roles govern.
1. Identify a drawing by more than its title
A filename such as ‘window schedule final.pdf’ cannot control custom production. A controlled record needs document number or unique ID, title, revision, issue date, status, author/issuer, approval or transmittal reference, scope/mark coverage and location in the authorised information system. Where a drawing is model-derived, also identify the model/export/version relationship that the project has approved.
ISO 19650-2 addresses information management during asset delivery and includes controlled information production, review and acceptance activities. It does not dictate a universal title block. Its relevance is practical: the project needs a traceable process for knowing which information container is current and whether it has reached the party who must act on it.
Keep drawing, schedule, detail, glass list, hardware list, finish schedule, mark register and change/RFI response in a relationship register. A window revision often changes only one of those documents, but the factory may use several together. If the relationships are not listed, a team can issue a new elevation while continuing to make components from a now-inconsistent schedule.
Do not use a ‘latest’ folder as a control state. Latest is a relative description that becomes wrong when a new file appears. Use explicit revision/status fields and a defined authoritative location.
| Field | Record | Why it prevents obsolete use |
|---|---|---|
| Unique document ID | Number/code plus title | Separates similarly named files |
| Revision and issue date | Explicit values, not file modified date alone | Shows sequence and actual release |
| Status | Draft / review / accepted / superseded / other project term | Prevents review documents becoming production instructions |
| Scope | Opening marks, system families and related schedules | Shows which work is affected |
| Authoritative location | Project-defined CDE/repository reference | Avoids chat/email copies becoming source |
| Relationship | Dependent documents and change records | Shows what else must be reconciled |
2. Turn every revision into an affected-mark impact assessment
A revision cloud shows where a drawing changed; it does not show what production has already done. For each revision, identify affected opening marks, change type, baseline values before/after, material or work state, dependent documents, packing/label effect, potential installed units and decision owner. This turns a visual redline into an operational question: what must stop, be updated, be rechecked or be treated as a formal change?
Classify changes by their actual configuration effect. A spelling correction may not affect factory work. A changed hand, glass make-up, profile section, finish, dimension, screen, hardware, interface or performance requirement can affect orders, machining, glazing, labels and inspection. Do not use revision number magnitude as a risk ranking; a minor-letter revision can contain a critical production change.
Compare the revision against the released baseline, not merely the preceding draft. A drawing may have been revised several times before production release; the relevant question is whether the current issued information changes something already committed. Preserve both values and the disposition so a later audit can see why a particular part was accepted, reworked or replaced.
ISO 10007 configuration-management guidance supports this approach: configuration information and changes need coordinated control across the product life cycle. Apply the principle to the actual project scope rather than inventing a generic approval workflow.
| Revision item | Affected marks | Production state | Required action | Authorised disposition |
|---|---|---|---|---|
| Dimension/geometry | [list] | [not started / cut / assembled] | Hold/recheck/rework analysis | [reference] |
| Glass build-up | [list] | [not ordered / ordered / glazed] | Supplier/order/inspection update | [reference] |
| Handing/hardware | [list] | [not machined / machined / packed] | Machining/parts/label review | [reference] |
| Finish/appearance | [list] | [not coated / coated / packed] | Sample/process/stock review | [reference] |
| Scope/mark quantity | [list] | [various] | Schedule/packing/shipment reconciliation | [reference] |
3. Withdraw superseded information at every point of use
Publishing a new drawing does not remove an old printed sheet, downloaded PDF, spreadsheet export, machining program or handwritten work note. Build a distribution map for each production-facing information type: design repository, supplier project folder, engineering review queue, purchasing, work order, cut list, machining/CNC data, glass order, hardware pick list, finish order, quality plan, inspection form, packing template and site handover pack.
For every affected point of use, choose a controlled action: replace with new revision, invalidate/remove access, mark superseded, quarantine work in progress, reissue an extract or perform a documented briefing. The method depends on the project’s systems, but the result should be auditable. A worker should be able to identify the current revision without comparing filenames or relying on verbal memory.
Do not destroy the superseded record. Retain it in an archive with visible superseded status and relationship to the replacement. History is needed for impact analysis, claims and after-sales; accessibility at the production point is the risk to control.
Where a shop uses digital terminals and printed packets together, verify both routes. A current cloud file does not protect a workstation where yesterday’s printout is still used; a stamped paper packet does not protect a CNC import created from an old model export.
| Point of use | Old record found | Control action | Verifier/evidence |
|---|---|---|---|
| Engineering/shop drawing packet | [revision/location] | Replace and mark/archive old copy | [name/date/photo or system log] |
| Purchasing order | [schedule/revision] | Amend/hold/reissue as authorised | [name/date/reference] |
| Workshop/CNC instruction | [program/export/revision] | Invalidate/reload/verify program | [name/date/reference] |
| Quality inspection form | [criterion/revision] | Replace checklist and brief inspector | [name/date/reference] |
| Packing/label template | [mark/configuration] | Update template and reconcile printed labels | [name/date/reference] |
4. Verify the revision in production, not only in the repository
Sample production-facing records after a change, prioritising marks already in work, special glass, custom finishes, mixed handing, coupled frames and high-cost units. Inspect the current work order, available drawing, cut/machining data, glass/hardware/finish orders, inspection criteria and labels. Compare them to the authorised revision and impact register. Record both matches and discrepancies.
When obsolete information is found, contain the affected population. Identify what has been ordered, cut, machined, assembled, glazed, inspected, packed or shipped; do not assume all items in a batch share the same state. Preserve labels and documents, then obtain the technical and commercial disposition through authorised project channels.
This check must be repeatable after each critical revision, not a one-time document-control audit. The project may choose its own sampling intensity and technology, but should be able to show how it determined that production used the intended baseline. An unverified upload is an activity, not proof of end-state adoption.
| Check | Compare | Evidence-backed result |
|---|---|---|
| Work order | Mark list and revision against release register | Current / mismatch / held |
| Cut/machining data | Dimensions/profile/handing against approved drawing | Current / mismatch / held |
| Component orders | Glass, hardware and finish against current schedules | Current / mismatch / held |
| Inspection | Criteria and sample identity against controlled configuration | Current / mismatch / held |
| Packing labels | Mark/configuration identity against released record | Current / mismatch / held |
5. Close revisions with a visible configuration history
A closed revision record links the old baseline, new baseline, affected marks, distribution/withdrawal actions, verification result, nonconforming population, corrective actions and final dispositions. It should also identify any installation, delivery or after-sales record that must be updated. This is more useful than an email trail because it lets the project reconstruct what was actually released at each time.
Do not call an issue closed merely because the new PDF is uploaded. Closure requires evidence that the relevant points of use were controlled and that affected physical work was dispositioned. Keep unresolved scope, commercial effects and site impacts plainly marked as open if they have not been verified.
FAQ
Is a new drawing revision automatically a change to production?
Not always. Perform an affected-mark and production-state assessment; a revision can be editorial or can alter custom materials, machining, glass, finish or labels.
Can we delete obsolete drawings to prevent mistakes?
Keep an archived, visibly superseded history for traceability, but remove or invalidate obsolete information at points of use.
Does a cloud repository solve revision control?
Only if the project verifies that purchasing, workshop instructions, programs, inspection forms and labels use the accepted revision.
Who decides whether in-progress units can be used after a revision?
The project’s authorised technical and commercial routes must decide after reviewing the affected configuration and physical work state.
What is the most important verification?
Check the information at the point where it drives work: work order, machining data, component orders, inspection record and packing label—not only the repository upload.
Continue the project review
Connect this guide with the proposed window and door systems, then review how Cavorlen approaches manufacturing and quality control. When your schedule is ready, send it through the project review form.
Official sources used
ISO — ISO 10007:2017 configuration management guidance ↗ISO — ISO 19650-2 information management during delivery ↗ISO — ISO 10006:2017 quality management in projects ↗GS1 — Global Traceability Standard ↗Related buyer guides
This guide does not provide a universal drawing-number convention, approval code, revision frequency or contractual change procedure. It does not determine liability for an obsolete document event.