What actually goes in a Manufacturing Record Book

Whatever your customer’s book specification says goes in it. That’s the real answer, and it’s worth saying first because the fastest way to build a rejected MRB is to build it from what went in the last one. Two EPCs will specify two different books under the same name.

That said, the same families of content recur, so here’s the shape of a typical request.

Material records. MTRs and material certificates for the pressure-retaining and load-bearing material, matched to where each heat or lot was used. PMI reports where positive material identification was required.

Fabrication and weld records. Weld maps, weld procedures, welder qualifications, and the logs tying welder and procedure to each weld.

Examination and test reports. NDE of whatever types the job carried (radiography, dye penetrant, hardness), plus pressure tests, hydro tests and functional tests.

Inspection records. ITP sign-offs, hold point releases, third-party inspection reports.

Code documentation. ASME data reports and nameplate records on stamped work, or the equivalent for whatever code governs.

Drawings. Final or as-built revisions, not the ones that got it there.

Sometimes more. Datasheets, manuals, spare parts lists, certificates of conformance. Depends entirely on the specification.

The parts people miss

Codes with nothing behind them still appear. Most book specifications require every line of the required-document list to show in the contents, including the codes that turned out not to apply to your scope. Those get marked with the customer’s expected suffix (N/A or similar), because a contents page with gaps reads as an incomplete book, and gets queried like one.

The structure is specified too. Section order, numbering, contents depth, page numbering, sometimes the exact table of contents layout. The contents of the book get the attention; the structure of the book is what the reviewer measures first, because it’s the easiest thing to check.

“The book” might be plural. One per order, or one per tag, per skid or per vessel. Same content, different split, very different assembly job.

The layout may need approval at kickoff. Plenty of specifications ask for the book structure and table of contents to be approved near the start of the project, months before there’s anything to put in it.

Where DocBoss comes in

In DocBoss the book is a structure you define against document codes: which codes belong, in which sections, under which contents layout. The book then generates from the documents already approved on the project, and codes with nothing behind them appear with the suffix your customer expects instead of leaving gaps. One structure can produce a single book or a set split per tag, per skid or per vessel. And because the document list generally exists at kickoff, the full table of contents can be generated with the real documents, numbers and tags in it, ready for the up-front approval, before a single file has been produced.

If your MRB specification runs to double digits in pages, it’s worth seeing this against it.