Document Register, Master Document Register (MDR).
A document register, most often called the master document register or MDR, is the controlled index of every engineering document a project will produce or receive: one row per document, carrying its number, title, discipline, document type, originator, and current revision status. Document control owns it, and every discipline-specific register, the P&ID register, the instrument index, the loop folder index, has to reconcile against it rather than run as an island.
What Document Register, Master Document Register (MDR) means.
A capital project issues documents faster than anyone can track from memory. Process, mechanical, electrical, instrumentation, and civil each produce drawings, specifications, and reports on their own schedule, and a mid-size project can carry several thousand numbered documents by handover. The MDR is the one index that holds them all, regardless of discipline or contractor. Each discipline first plans its output on an engineering deliverables register, a forecast of what it will issue and by when, and those planned lines populate the MDR before the documents exist. As documents are actually issued, the MDR carries them through the revision ladder, issued for review, issued for approval, issued for construction, as-built, with a planned and an actual date recorded at each stage. Vendor documents follow the same discipline through a linked vendor document register, so a supplier datasheet or certified drawing returns against the same document number the project assigned. At handover, every discipline register, the P&ID register, the instrument index, the loop folder index, is reconciled against the MDR, because a drawing revision document control never logged is the classic source of drift.
What a document register carries.
Every row identifies one document: a project-assigned document number, a title, the originating discipline, a document type code (drawing, specification, datasheet, procedure, report), the originator, whether it is company or contractor work, and the current revision letter or number with its status. Alongside that sits the revision history itself, planned and actual dates for each stage a document passes through, issued for review, issued for approval, issued for construction, as-built, and a distribution record of who received which revision under which transmittal. A vendor document carries an extra field linking it to its own vendor document number and the purchase order or requisition it belongs to. None of this is engineering content. The MDR indexes documents; it does not hold the drawings themselves.
How the engineering deliverables register feeds the MDR.
Before a discipline issues a single drawing, it plans one on an engineering deliverables register: the list of documents that discipline commits to producing, with a planned issue date for each stage. That planned line becomes a placeholder row in the MDR, so a project manager can see what is coming before it exists, not only what has already been received. As the discipline actually issues each document, the placeholder is updated with the real document number, the actual issue date, and the revision, and the deliverables register and the MDR converge on the same record. A deliverables register that a discipline keeps separately, disconnected from the MDR, is how a planned document quietly never gets logged as received.
The vendor document register and transmittals.
Vendor documents, certified drawings, datasheets, calibration certificates, follow a parallel track. The vendor document register, sometimes issued to a supplier as a supplier document requirements list, tells the vendor which documents to submit, in what format, and against which milestone. Each submission is logged into the MDR under the vendor's own document number, cross-referenced to the internal document it corresponds to and the purchase order it was called up against. Transmittals are the mechanism that moves any of this. A transmittal is the covering record of what was sent, to whom, and on what date, and every document exchange, internal issue or vendor submission, should be traceable to one. A document that changed hands without a transmittal is a document control cannot account for.
Why the P&ID register, instrument index, and loop folder index must reconcile.
A P&ID revision, an instrument index update, and a loop folder are each maintained by a different discipline on its own schedule, but every one of them is also a document with a number, a revision, and a status, which means every one of them is also a row in the MDR. The classic drift is a P&ID revised in the field or redlined during construction that document control never logged: the drawing shows the current state, the MDR still shows the prior revision, and every downstream document built from the P&ID, the instrument index, the loop folder, the I/O list, inherits the mismatch. Reconciling the discipline registers against the MDR before handover is what catches that gap while it is still cheap to fix.
Master document register columns
The core fields on an MDR row. Most projects add more, but these are the ones every register carries.
| Column | Example | What it carries |
|---|---|---|
| Document number | PID-001-INS-0004 | Unique project identifier for one document |
| Title | Instrument Index, Unit 12 | Plain-language document title |
| Discipline | Instrumentation | Which discipline owns the technical content |
| Document type | Drawing | Drawing, specification, datasheet, procedure, or report |
| Originator | Contractor XYZ Engineering | Company or contractor that produced the document |
| Revision | Rev C | Current revision letter or number |
| Status | Issued for construction | Where the document sits in the revision ladder |
| Planned / actual issue date | 2026-03-14 / 2026-03-21 | Forecast versus real issue date at each stage |
| Vendor document link | VDR-0087 | Cross-reference to the vendor document register, where applicable |
MDR vs the registers that feed it
Four registers a project keeps side by side. Confusing them is common; each has its own owner and its own trigger for updating.
| Document register (MDR) | Engineering deliverables register | Vendor document register | Transmittal register | |
|---|---|---|---|---|
| What it lists | Every document the project produces or receives, internal and vendor | One discipline's own planned output with target dates | What a vendor must submit, by document type and milestone | What was sent, to whom, and when |
| Owner | Document control | The discipline lead | Procurement or the discipline managing the vendor | Document control |
| When it changes | Continuously, as any document is issued, revised, or received | At the start of engineering, then as forecasts slip | As the vendor's submission schedule is agreed and updated | Every time a document changes hands |
Common questions
What is the difference between a document register and an engineering deliverables register.
What does MDR stand for.
How does the vendor document register relate to the MDR.
Who owns the document register on a project.
What happens when a P&ID revision never reaches the document register.
Is the document register the same thing as a drawing register.
When is the document register set up on a project.
Run it on your drawings.
Upload a drawing set, get every document populated and classified, export to the format your team uses.