Use one row for each required decision or evidence item, with separate completeness and review states.
Start with the required decisions
Build the register from the actual product and coordination requirements rather than requesting every document that a supplier might own. Product identity, profile drawings, installation instructions, samples and project-specific evidence may need different reviewers and due dates. Give each item a stable identifier and a clear description of what must be submitted. Include the responsible submitter and the requirement it answers. Where a document is not applicable, require a short recorded reason instead of allowing an empty row to resemble completed work.
Separate the status fields
Document received, information complete and technically accepted are different events. Use a completeness field for presence of requested information, and a distinct review field for the authorized disposition. A checklist percentage can describe recorded items only. It must not imply that the design is safe, compliant or ready to build. Add the document revision, received date, reviewer, response date and open comments so someone else can understand the current state without reconstructing email history. Link to the actual file rather than relying on its title alone.
Manage resubmissions deliberately
Keep the stable item identifier when a revised document arrives, but increment or record its revision and retain the earlier response. Request a description of what changed so a reviewer can focus on the unresolved issue without missing new differences. Identify items that affect procurement or other submissions and make those dependencies visible. Before release, verify that the correct disposition belongs to the current version. At closeout, retain a final register with links to the installed product records. It should provide an audit trail of decisions, including items deliberately excluded from the package.
Evidence & scope
Original planning guidance. References support their stated technical scope; examples and workflows do not establish product approval.