Source control
How to Build a COI Evidence Source Register
A certificate submission can involve a contract, insurance exhibit, portal instructions, certificate, endorsements, agent messages, delivery receipts, and reviewer responses. A source register gives each document or message a stable identity so the team can tell what a statement came from, which version was used, and whether a newer source has replaced it.
Why a source register matters
Many COI problems are not caused by a missing document. They are caused by an unidentified source. A coordinator may compare the current certificate with an old insurance exhibit, rely on portal text that was later revised, or treat an undated email as a final client decision. The individual facts may be accurate, but the workflow cannot be audited because nobody can reconstruct which version supported the action.
The register solves that problem by separating a source from the claim made about it. “Insurance Exhibit V04 dated September 3” is a source identity. “The required limit is $2 million” is a value transcribed from that source. “The certificate meets the requirement” is a conclusion that the register should not make. Keeping those layers separate makes later corrections safer and faster.
Official guidance also distinguishes the certificate from the policy. ACORD explains that a certificate is not the insurance policy and does not amend its terms. The Texas Department of Insurance similarly connects additional-insured and waiver checkboxes to policy endorsements. That is why a certificate, endorsement, policy reference, issuer response, and client review should never be collapsed into one generic “insurance document” row.
The minimum fields for each source
| Field | Purpose | Example |
|---|---|---|
| Source type | Distinguishes a requirement, issued document, professional response, delivery record, or decision. | Client insurance exhibit |
| Short label | Creates a neutral reference without copying confidential text or identifiers. | Insurance Exhibit V04 |
| Version and date | Separates current, superseded, and undated material. | V04 · 2026-09-03 |
| Source owner | Shows who issued or controls that source category. | Client risk team |
| Purpose or authority | Limits what the source can support. | Defines requested evidence |
| Scope | Connects the source to a project, entity, trade, location, phase, or policy line. | Building C electrical work |
| Workflow state | Records current, superseded, pending, conflicting, or reference-only status. | Current—needs comparison |
| Location reference | Lets the team find the authoritative copy in its approved system. | Contract file / insurance tab |
| Owner and next action | Prevents an unresolved source question from becoming an invisible assumption. | Coordinator—confirm portal revision |
Avoid entering policy numbers, personal contact details, confidential contract paragraphs, or direct document links into a browser tool. Use a neutral local label that lets an authorized user find the source in the organization’s existing system.
Record authority by purpose, not by a universal ranking
There is no safe universal rule that says one document always outranks every other document. Each source has a different job. The client or authorized contract source defines the requested evidence. The licensed agent, broker, insurer, or authorized issuer addresses policy-backed document identity and availability. The certificate displays information about insurance at a point in time. Issued endorsements and the policy control their own terms. A portal receipt proves an observed delivery event, not acceptance. A reviewer response documents that reviewer’s stated outcome.
Use a purpose label such as “defines requirement,” “issued insurance evidence,” “explains policy-backed evidence,” “records delivery,” or “records client review.” If a source is being used beyond that purpose, flag the row for professional review instead of silently promoting it to a higher authority.
This distinction is particularly important when a certificate contains a description or checked box. The notation may be relevant to the submission, but it is not automatically the requested endorsement. Record both artifacts and let the licensed issuer identify the policy-backed evidence.
Control versions without deleting the past
Marking a source as superseded is different from deleting it. A superseded source may explain why an earlier package was prepared or why a reviewer rejected a prior submission. Preserve the old label, version, date, and replacement reference so the history remains understandable.
- Identify the new source. Give it its own row before changing any current status.
- Compare scope. A new portal instruction may apply only to one location or project phase.
- Record the relationship. Use “appears to supersede,” “supplements,” or “conflicts—needs decision” until the appropriate authority confirms the effect.
- Reconnect downstream work. Review affected evidence rows, requests, filenames, packages, deadlines, and open decisions.
- Preserve the transition source. Keep the dated client or issuer response that explains the version change.
Do not label an undated source “current” merely because it was received most recently. Receipt time and effective authority are different facts. Record both when available and ask for clarification when they do not align.
A practical source-register workflow
1. Start with the controlling request
Enter the current contract, insurance exhibit, purchase order, or portal instruction as separate rows. Record exact neutral labels and observable dates. If two requirement sources appear inconsistent, keep both and open a conflict rather than choosing the preferred wording.
2. Add issued evidence separately
Create distinct rows for the certificate, each endorsement or policy form reference, issuer response, and any alternative evidence. A package can include several documents that have different dates and scopes. One generic package row is not enough to support a field-level review.
3. Add delivery and review events
A sent email, portal upload, receipt, reviewer response, correction request, and acceptance message are separate sources. Their dates and owners create the evidence trail needed to distinguish “prepared,” “submitted,” “received,” “under review,” and “accepted.”
4. Review unresolved states
Filter the register for pending, conflicting, undated, superseded, and unclear rows. Assign each one to the party capable of resolving it. Policy and endorsement identity goes to the licensed issuer; requirement meaning and client outcome go to the authorized client reviewer; contract effect may require qualified legal review.
5. Export only the administrative index
The register can be copied, printed, or exported as a local CSV, but it does not replace the authoritative documents. Store the exported index through approved internal processes and keep the real files in their controlled location.
Frequently asked questions
Should the newest source automatically become controlling?
No. A newer timestamp does not prove that the source supersedes another document or applies to the same scope. Record the apparent relationship and route the question to the appropriate authority.
Can the certificate and endorsement share one row?
They should be separate when they support different observations. The certificate is not the policy and does not itself amend coverage; an issued endorsement is a different artifact.
What if the team cannot find the authoritative copy?
Use “location unknown” or “copy requested,” assign an owner, and avoid treating a remembered value as verified evidence.
Does a reviewer acceptance message prove coverage?
No. It records the reviewer’s stated administrative outcome. Coverage and policy meaning remain separate questions for the policy and qualified insurance professionals.