Active-project control
COI Requirement Change Log for Active Projects
When a project lasts longer than one onboarding cycle, insurance evidence requests can change. A change log connects each source revision to the operational effect, responsible party, evidence request, and response status.
Reviewed September 2026 ยท Educational information, not insurance or legal advice
Why a current checklist is not enough
A checklist shows what the team currently plans to submit. It may not explain when a requirement changed, who communicated it, which prior package used the older version, or why an agent request was reopened. A change log preserves that path.
This matters when a renewal occurs during a project, the owner or general contractor changes, a new phase begins, completed-operations evidence becomes relevant, a portal changes its categories, or a client replaces an insurance exhibit. Without version history, a later reviewer may compare the wrong evidence package to the wrong requirement version.
Recommended change-log fields
| Field | Purpose |
|---|---|
| Project reference | Connects the change to one neutral job or vendor record |
| Baseline source | Identifies the prior requirement version and date |
| Revised source | Identifies the new record being compared |
| Effective date | Records when the client says the revision applies |
| Requirement item | Names one entity, field, value, evidence type, date, or portal instruction |
| Baseline and revised values | Preserve both sides of the comparison |
| Classification | Appears added, changed, appears removed, unchanged, or unclear |
| Current owner | Identifies who must provide the next fact, evidence, action, or professional judgment |
| Operational impact | Explains the checklist, agent request, package, schedule, cost, or legal question affected |
| Status and evidence | Records observable completion without making a coverage conclusion |
Create the comparison record
Turn two written sources into a sortable change matrix.
Retain both values and export the result locally for the approved project system.
Eight-step active-project workflow
- Record receipt. Preserve the revised source, sender, date, and delivery channel.
- Confirm scope. Ask whether it replaces the entire earlier request or supplements selected items.
- Freeze the baseline. Retain the prior source and the exact package submitted against it.
- Compare atomic items. Separate coverage lines, values, entities, periods, endorsements, and delivery rules.
- Confirm effective timing. Distinguish the revision date, effective date, evidence deadline, and project milestone.
- Route impact. Send requirement questions to the client, policy/evidence questions to the agent, and legal questions to qualified counsel.
- Update the package workflow. Create a new checklist and version rather than silently overwriting the old one.
- Record outcome. Connect clarification, issued evidence, delivery receipt, and review status.
USGS files-management guidance recognizes that naming conventions help distinguish similar versions and support correct filing. A controlled COI workflow similarly benefits from source labels, versions, and a short description of what changed.
Example change history
| Date | Source | Change | Current action |
|---|---|---|---|
| September 2 | Baseline exhibit V01 | Initial evidence matrix preserved | Package V01 delivered |
| September 18 | Client clarification email | Owner legal entity corrected | Client confirms exact text; agent receives corrected request |
| October 1 | Revised exhibit V02 | Completed-operations evidence appears added | Agent reviews availability and issued evidence |
| October 8 | Portal instruction | Endorsements require separate upload category | Contractor restages package and records receipt |
Control rules for the log
- Never delete an earlier source because a new one arrived.
- Do not backdate a clarification.
- Keep received, effective, due, issued, submitted, and accepted dates separate.
- Do not label an apparent removal as confirmed without a controlling source.
- Do not describe client acceptance as policy verification.
- Use neutral project references rather than policy or personal identifiers.
- Preserve the exact outgoing package version linked to each review cycle.
- Follow organizational retention and access rules.
Who maintains the log?
The contractor or vendor often maintains its operational copy because it coordinates the package. The client controls its requirement and review record. The agent or issuer controls its insurance records and issued evidence. These records can be related without being merged or treated as interchangeable.
Frequently asked questions
Should every email become a new requirement version?
Only communications that materially add, change, remove, or clarify an item need a change entry. Preserve the underlying correspondence according to the approved records process.
Can one change affect several rows?
Yes. A new project entity may affect the holder block, additional-insured request, endorsement schedule, filename, and portal category. Record each operationally distinct item.
What if the client and agent use different terminology?
Preserve both wordings and ask focused questions. Do not force a match based on similar wording alone.
How long should the log be retained?
Follow the contract, company policy, legal holds, and applicable records requirements. This guide does not prescribe a retention period.
Sources and scope
- U.S. Geological Survey: Version-history record for revisions
- U.S. Geological Survey: Files management
- U.S. National Archives: Consistent file and folder naming
The fields and workflow are an original project-control framework, not a legal records-retention rule.