A customer complains about a letter they received six months ago.
The organisation still has the current template. It also has an approval record. But neither of those facts necessarily answers the question that now matters:
Which approved version was actually used when this communication was generated?
This is where communication evidence becomes different from ordinary document storage.
The aim is not simply to prove that a template existed. It is to preserve enough evidence to connect a generated communication with the controlled version and governance history behind it.
Start with the question you may need to answer later
When a generated email, PDF or letter is questioned, several different facts may matter.
- Which communication template was requested?
- Which approved version of that template was current at the time?
- When was the communication rendered?
- Can the generated output be linked back to that version?
- Can the integrity of the evidence be checked?
- What approval history sat behind the version used?
These are generation and governance questions.
They are not automatically the same as asking whether the communication was sent, delivered, opened or read.
That distinction is fundamental to a useful evidence model.
Generation evidence is not delivery evidence
A communication normally passes through several stages.
Approved template → Generation → Sending → Delivery → Customer interaction
Different systems may be responsible for different stages.
A communication platform may be able to establish which approved template version produced a PDF. An email provider may then record whether the message was accepted for sending. Another system may provide delivery status. Customer interaction data may indicate whether a link was clicked or, in some environments, whether a message was opened.
Those events should not be collapsed into a single vague claim of "proof".
Generation evidence can help answer which controlled wording was used to create the communication.
Delivery evidence concerns what happened after generation and depends on information available from the configured sending systems or delivery providers.
Generating a communication does not, on its own, prove that it was sent or delivered.
The template name is not enough
Suppose a system records:
template = payment-reminder
That tells you which type of communication was generated, but it does not necessarily identify the wording.
If the payment reminder has gone through 15 controlled versions, the template identifier alone cannot answer whether the communication used Version 12, Version 14 or Version 15.
This is why generation evidence needs to remain connected to customer communication version control.
A stable template identifier tells you which communication was requested. The version record tells you which controlled wording was used.
An approval record is not enough either
An organisation might also be able to show that Version 15 was approved.
That still does not, by itself, prove that a particular generated communication used Version 15.
Approval evidence answers:
Was this version authorised according to the organisation's workflow?
Generation evidence answers:
Was this the controlled version used when this particular output was created?
The strongest evidence chain connects those two records rather than treating them as separate islands.
For the approval side of that chain, see What an Approved Wording Workflow Needs to Record.
What should a generation record contain?
The exact design depends on the organisation, communication type, architecture and retention policy. A useful generation record may include:
- a stable template identifier;
- the specific approved version used;
- a generation or evidence record identifier;
- the rendering timestamp;
- the approval context associated with that version;
- an integrity value, such as a cryptographic hash of the rendered output;
- information needed to relate the output to the relevant transaction or business event, subject to the organisation's data-handling design; and
- where applicable, the retained rendered communication itself.
Not every organisation needs to retain every generated document forever. The evidence model should reflect applicable regulatory requirements, operational needs, data minimisation, retention policy and the type of communication involved.
The important point is that the evidence should be designed intentionally rather than discovered accidentally during an investigation.
The final output depends on more than the template
This is an important technical point.
A template may contain wording such as:
Hello {{customer_name}}, your payment of {{amount}} is due on {{date}}.
The approved template version controls the fixed wording and structure. But the actual generated communication also depends on the data inserted at generation time.
That means knowing the template version alone may not be enough to reconstruct exactly what an individual customer saw.
A useful evidence strategy therefore needs to consider the relationship between:
- the approved template version;
- the dynamic data used at generation time;
- the rendered output; and
- the organisation's retention policy.
Different organisations may choose different approaches. Some may retain the complete rendered communication. Others may retain a more limited evidence record and rely on other controlled data sources where reconstruction is required.
What does a cryptographic hash actually prove?
A cryptographic hash can provide a compact fingerprint of a piece of digital content.
If the content changes, the hash normally changes too. That makes hashes useful for integrity checking and tamper-evident evidence records.
But a hash needs to be understood correctly.
A hash is not a copy of the communication.
You cannot take a hash and reverse it to recover the original PDF, letter or email. Instead, the hash can later be compared with a retained or reconstructed output to check whether the content matches the recorded fingerprint.
This creates an important design choice.
An organisation that retains the complete rendered communication can compare the retained content with the recorded hash directly.
An organisation using a hash-focused evidence model may instead need the original data and controlled rendering context if it later wants to reconstruct the output and compare it with the recorded evidence.
Neither model is automatically right for every organisation. Retention requirements, personal-data considerations, operational needs and regulatory obligations all affect that decision.
Evidence should include time
A rendering timestamp is another important part of the record because approved wording changes over time.
Suppose Version 9 was approved on 2 June and Version 10 became operational on 18 June.
If a customer communication was generated on 12 June, the existence of Version 10 today does not tell you what should have been used at that earlier moment.
The evidence chain needs a chronology:
Version approved → Version operational → Communication generated
That timeline makes it possible to understand the state of the controlled communication at the moment the output was produced.
The calling application should not have to decide which historical version to use
Version selection becomes more difficult when every connected application is allowed to request its own historical template version.
For example:
template = arrears-reminder
version = 8
If Version 9 has since been approved for operational use, an old configuration could continue requesting Version 8 unless every consuming application is updated correctly.
An alternative architecture keeps the template identifier stable while the communication platform controls the approved version used for normal generation.
The calling system asks for the communication it needs. The controlled communication system resolves the version that is approved for use.
This reduces the number of places where historical-version selection has to be governed.
What if an old communication needs to be reconstructed?
Reconstruction depends on what the organisation chose to retain.
If the complete rendered communication was retained, the historic output may already be available.
If it was not, reconstruction may require several pieces to still exist:
- the exact historical template version;
- the data originally used to populate the communication;
- the relevant rendering rules or compatible rendering environment; and
- the evidence record against which the reconstructed output can be checked.
This is why retention strategy needs to be considered alongside evidence strategy.
A template archive without the relevant dynamic data may not reproduce the exact customer output. Likewise, retaining customer data without the historical template version may not establish the wording that surrounded it.
Evidence should survive later template changes
A generation record should not become less meaningful when the underlying template changes.
If Version 21 is live today, evidence relating to a communication generated from Version 14 last year should continue to point to Version 14 and its associated history.
That historical link is one of the main reasons version identifiers should be stable.
It also prevents the current template from being mistaken for evidence of what existed at an earlier date.
Where regulatory record keeping enters the picture
Record-keeping requirements depend on the activity and regulatory regime, so there is no single evidence specification that applies to every customer communication.
For example, FCA COBS 4.11 requires adequate records of certain financial promotions that firms communicate, approve or confirm compliance with, subject to its scope and exceptions. The section also contains different retention periods for different categories of financial promotion.
For certain MiFID, equivalent third-country and optional-exemption business, COBS 4.11A also requires records of communications to clients and marketing communications within its scope.
These are examples of specific record-keeping requirements. They should not be read as a universal rule for every communication or every regulated organisation.
The organisation still needs to determine what records it must retain, for how long and in what form according to the rules that apply to its business.
What the CommsPliant Evidence Vault records
CommsPliant is designed to keep generation evidence connected to the controlled communication lifecycle.
A connected system requests a communication using the template identifier. It does not select an arbitrary historical version. At generation time, CommsPliant uses the latest approved version available for that template.
The CommsPliant Evidence Vault provides the evidence layer around that event. The evidence can include the approved-version context, approval history, rendering timestamp and a tamper-evident hash associated with the rendered communication.
CommsPliant's default evidence approach does not require every implementation to retain the full rendered customer communication inside the Evidence Vault. Full content retention can be configured where the organisation's requirements call for it.
Where full content is not retained, the hash acts as an integrity fingerprint rather than a substitute for the content itself. Reconstruction therefore depends on the relevant historical version and the original data remaining available through the organisation's chosen retention architecture.
This distinction matters because an evidence system should not claim more than the underlying records can demonstrate.
What the Evidence Vault does not claim
The Evidence Vault is not a magic certificate saying that every communication was compliant.
It does not turn an approved version into regulatory approval.
And a generation record does not automatically establish that the customer received the communication.
Instead, the Evidence Vault is designed to preserve a controlled evidence chain around questions such as:
- Which template was used?
- Which approved version generated the communication?
- What approval history sat behind that version?
- When was the output rendered?
- What integrity evidence was recorded for that output?
Those are narrower claims, but they are also much more useful because they can be tied to specific records rather than assumptions.
Why communication evidence should not depend on a software release
If communication content lives inside application code, evidence can become fragmented across source control, Jira tickets, deployment logs, approval emails and output systems.
Each system may contain a small part of the story.
Separating controlled communication content from application releases can make that story easier to follow, while Engineering continues to control the integration and technical environment.
The distinction is explored further in When a Wording Change Should Not Wait for a Software Release.
A simple communication-evidence test
Choose one customer communication generated several months ago and try to answer these questions without asking the original project team for help:
- Which template produced it?
- Which version of that template was used?
- Was that version approved at the time?
- Who approved it?
- When was it rendered?
- Can you verify the integrity of the recorded output or evidence?
- If the content itself was not retained, could it be reconstructed from the records that still exist?
- Can you distinguish generation evidence from sending or delivery status?
If those answers exist across five different systems and have to be manually reconciled, evidence exists, but the evidence chain may be fragile.