What a package manifest adds

A checklist answers whether a requirement appears ready. A manifest goes one step further: it identifies the exact filename that will be delivered for each document row. This supports a reproducible submitted snapshot and makes later corrections easier to compare.

The manifest should be generated after the current written requirement is understood and before files are uploaded. It is especially useful when a package contains a certificate plus general-liability, auto, waiver, primary-and-noncontributory, or completed-operations endorsements.

Recommended manifest fields

Seven-step manifest workflow

1. Freeze the requirement. Use the current contract, exhibit, portal instruction, or client clarification.
2. Inventory document types. Keep certificates and endorsements in separate rows.
3. Identify coverage or scope. Avoid calling every supporting file “endorsement.”
4. Choose one package version. Apply the same controlled version to the outgoing set.
5. Generate and inspect filenames. Resolve duplicates and warnings before renaming local copies.
6. Open every actual file. Confirm the document matches its manifest row.
7. Snapshot and deliver. Preserve the exact outgoing set, manifest, and permitted receipt.

NARA guidance emphasizes consistent component positions and meaningful names. The manifest makes that convention explicit, so another team member can understand the package without relying on the submitter’s memory.

Example manifest

The status is administrative. “Ready after review” means the contractor completed its package check; it does not declare policy compliance. “Need confirmation” keeps a question visible rather than omitting the row.

Manifest checks before delivery

• No two rows create the same filename.
• Every required evidence category has a row.
• Every row points to one actual opened file.
• The project reference is neutral and correct.
• The document type matches the file.
• The date meaning is consistent.
• The version matches the outgoing attempt.
• No unnecessary policy or personal identifier appears in a filename.
• The client’s file-size, extension, and category rules are followed.

Frequently asked questions

Should the manifest be sent to the client?

Only if the client requests or accepts it. Its primary role is internal package control.

Can one row represent several endorsements?

Separate rows usually make omissions easier to detect, but follow the actual package and portal requirements.

What if two documents generate the same name?

Do not append a random suffix without understanding why. Confirm the document type, scope, date, or version that distinguishes them.

Should excluded files remain visible?

An internal manifest may record an excluded or superseded item so the decision is traceable, but only the intended files belong in the submitted snapshot.

Sources and scope

• U.S. National Archives: File naming conventions
• Harvard Medical School: File Naming Conventions
• Texas Department of Insurance: Certificates FAQs

The manifest fields and workflow are original administrative guidance. They do not replace the client’s requirements or the authorized issuer’s records.