Forty-seven comments and one Excel file

Transmittal 2 comes back with forty-seven comments. Twelve on the P&IDs, most on the narrative spec, three that reference "see previous submittal" without a page number. Project manager assigns disciplines, sets a return date. Mechanical knocks out their sheet in a week. Document control starts the comment log in Excel, because the comment log is always Excel.

Three weeks later you resubmit. The log shows all forty-seven closed. The customer opens Transmittal 3 and finds comment 31 still open: it was checked off in the spreadsheet, but the fix never made it into the datasheet that shipped. And comment 19 was never answered at all, because the markup sat on a PDF nobody reopened.

Comment rounds fail quietly

The failure mode is not laziness. It is that the comment and the file live in two different places. You check a comment off in the Excel log, but the fix never gets made in the source file, or it gets made and never re-exported. The log says closed; the released file still has the original wording. One open item blocks commercial acceptance, and the team only finds out on Transmittal 4.

• The comment log lives in one spreadsheet; the markups live in Bluebeam; the real status lives in email.
• Nothing ties each comment to the file revision that fixed it, the person who verified it, and the export that actually shipped.
• "Closed" means three different things: fixed, won't fix, or fixed in the native file but never re-exported.
• A markup on a PDF nobody reopened never gets a response, and nobody notices until the customer does.

Forty-seven comments is manageable. Forty-seven comments across twelve file versions is a reconciliation project.

What a closed round actually requires

Before you call a comment round done, someone needs to answer: for each comment, show me the file revision where it was fixed, who verified, and what else changed in that same export batch. That is tedious work with folders and email. It is straightforward work with a structured review session where every response links to a versioned file and the release step will not complete with open items.

How Kord closes the round

• Every comment is pinned to the file it refers to — the line, cell, or region on the P&ID or datasheet — so a markup can't sit on a PDF nobody reopens. Comment 19 lives on the drawing, not in a separate Bluebeam file.
• Each comment links to the file version that resolves it, so "closed" means the fix is in a released revision, not a checked box in an Excel row the source file never got.
• The review session is the log: comment ID, source file, location, owner, status, and resolving revision in one place instead of split across a spreadsheet, Bluebeam, and email.
• Checklist templates require a second reviewer on critical specs, so no discipline closes its own items unchecked.
• The release won't complete with open comments, and it exports a manifest of approved versions — so the resolved set ships with the transmittal instead of as a spreadsheet three days later.

Iterative submittals are how EPC and modular equipment work actually gets done. The tooling should match the rhythm (grouped reviews, visual diffs on resubmit, audit trail from comment open to release) instead of forcing each round through a new Bluebeam session and a fresh hunt through Sharepoint. That is the gap between markup tools and document-set review. Not sexy. Just the difference between Transmittal 3 and Transmittal 5.