The reviewer doesn't read your package front to back. They pick a tag off the drawings and go looking for the proof. If they can't get from that tag to its marked datasheet in a couple of clicks, the item gets a comment and the package gets a stamp you don't want. Before you send, pick three tags, open the PDF cold, and time how long it takes to find each one. Wherever you get stuck is where the reviewer will.
The package comes back Revise and Resubmit. The comment reads "Submittal data not found for FIT-305 and LIT-214." You open the PDF. FIT-305 is right there on page 187, inside the flowmeter datasheet, filed under the manufacturer's name. LIT-214 is one of forty level transmitters covered by one sheet that never mentions a single tag.
Nothing was missing. It just couldn't be found, which on a review desk works out to the same thing.
How the reviewer actually reads your package
You built the package the way the work came in: by vendor, by purchase order, by the order the files came off the server. The reviewer reads it the way the design came out: by tag.
Picture their desk. Your spec section and drawings on one monitor, your package on the other, and a stack of other trades' submittals waiting behind yours. They pick FIT-305 off the P&ID, then look for three things: which product you're supplying for it, which page proves it, and whether the marked values meet the spec. A package organized by tag answers all three in seconds. A package organized by vendor makes them reverse-engineer your purchasing.
Most reviewers will give you one good try. After that, "not found" is quicker to write than a search.
Run the three-tag test
This takes five minutes, and it's the closest thing you'll get to sitting in the reviewer's chair.
- Pick three tags you didn't work on last. One ordinary item, one that repeats across stations or panels, and one oddball: a configured instrument, a part with a different order code, something a vendor substituted. Take them off the drawings, not your BOM.
- Close the package and open it cold. Start at page 1, like someone who's never seen it.
- Find each tag's marked datasheet. Use only what the reviewer has: the table of contents, the bookmarks, the tabs, and search.
- Time it. Under a minute each and you're in good shape. Anything longer, write down exactly where you got stuck.
Better yet, hand it to someone on your team who didn't build it. You know LIT-214 is under the level transmitter family datasheet. They don't, and neither does the engineer.
What fails the test, and the fix
The tag isn't in the package at all, only the catalog number. Search for "LIT-214" and you get zero hits. The fix is an equipment schedule that lists every tag next to its part number, and a table of contents whose item rows carry the tag and the page. Now the tag the reviewer is holding leads somewhere.
The tag is one of forty identical ones. Repeated stations are where packages go to hide things. You rightly include the datasheet once, not forty times, but then the sheet has to say which tags it covers. A range the reviewer can read ("LIT-201 to LIT-240") on the schedule and at the top of the sheet beats "see schedule" every time.
Same model, different order codes. Two tags, same transmitter, one with a different range or wetted material. If the schedule shows one catalog number for both, the reviewer can't tell which variant goes where. Give each tag its own order code on the schedule, and mark both on the datasheet.
The tabs don't match how the reviewer thinks. If product data is one 300-page lump, the reviewer can only scroll. Number the sections, put the tab numbers in the table of contents, and group product data so a click narrows the hunt. The mechanics of bookmarks and page labels are in building a PDF package a reviewer can navigate.
They found the sheet, but not the model. The tag leads to a 12-page family catalog with nothing marked. That's a markup problem, and it's covered in how to mark up cut sheets and catalog number highlighting.
Pages that belong to no tag. While you're testing, notice the pages you flip past. If a page can't be tied to a tag on the schedule or a demand in the spec, it's padding, and padding is what buries FIT-305 on page 187.
Run it again on round two
When a package does come back, the comments hand you your next three tags. Before you resubmit, run the test on every tag the reviewer named, then on one they didn't. If they couldn't find it last time, the fix isn't only adding the document. It's making sure it can be found this time. How to answer each comment row by row is in answering review comments on a resubmittal.
How Submittal Kit handles this
Building a tag index by hand, then rebuilding it every time a page moves, is the part that never gets done the night before a deadline. In Submittal Kit the package is built from the project's Equipment Register, so the tags come along for free. The compiled table of contents lists each item with its tag, part number, manufacturer and page, and each section gets a numbered tab. The Equipment Schedule section prints every tag beside its part, collapsing a run of stations into a range like LIT-201 to LIT-240, and shows a tag's own order code when it differs. Every highlighted datasheet page opens with a legend band naming the part number and the tags it covers, and the product data bookmarks are grouped by manufacturer.
Before you send, the Checks tab flags an item with no document and a spec demand no section carries. On round two, the Comment Response Log section keeps every comment and your answer in the package. See Compile a submittal, Configure sections, and submittal packages.
Disclosure: I build Submittal Kit, and the three-tag test works on any PDF, from any tool, in about five minutes.