Build The Reference File Before You Edit Anything
By Gabriel Tan | April 2026
A company was going through a rebrand. New name, new positioning, new visual identity. Fifteen documents needed to go out within the same fortnight: updated website copy, a press release, client letters, an internal memo to staff, partner communications, social media copy, a media kit, and pitch decks for two different audiences. Seven people across the firm were drafting different pieces.
Within the first week, the problems surfaced. One writer referred to the company by its old name in paragraph three of a client letter. Another used the previous tagline in a pitch deck. Two documents described the rebrand as a "refresh" while three others called it a "new direction," which carried a different implication entirely. The tone in the staff memo was casual and excited. The tone in the client letter was formal and cautious. The social media copy sat somewhere in between and matched neither.
The instinct was to start editing immediately. Open each document, fix the problems, get them out the door. Fifteen documents, fifteen sets of edits, done by end of week.
That instinct is wrong. Here is why, and what to do instead.
The problem with editing first
When seven people edit fifteen documents without a shared reference, each person makes different choices. One writer describes the rebrand as a strategic evolution. Another frames it as a response to market changes. A third implies the old brand was not working, which contradicts the narrative the CEO approved. Someone uses terminology from the old brand guidelines that should have been retired. Someone else introduces new language that has not been approved.
Each document gets edited in isolation. Each editor applies their own judgment about what sounds right. The inconsistencies only surface when someone reads all fifteen documents side by side, which usually happens after half of them have been sent.
At that point, the firm either recalls and re-edits (expensive, embarrassing), or lives with the inconsistency and hopes nobody notices (risky, unprofessional). A rebrand where the company's own communications cannot agree on what to call itself or why the change happened is worse than no rebrand at all.
The problem is not that the editors are bad at their jobs. The problem is that no single reference defines what "right" looks like across all fifteen documents. Without that reference, consistency is impossible regardless of how talented the team is.
The first-principles move: build the reference file first
Before touching a single document, build one reference file that every editor works from. This takes less than a day. The fifteen documents come together faster after the reference file exists than they would have if editing had started on day one.
The reference file has four sections. Here is what goes into each one and how to build it.
Section 1: terminology rules
This is a two-column list. Left column: approved terms. Right column: terms that are banned and why.
To build it, gather every document that has been drafted so far. Read through them and list every term used to describe the company, the rebrand, the old brand, the new positioning, and the company's products or services. You will find variations. Some are harmless preferences. Others carry strategic or legal risk.
For the company rebrand, the old brand name, old tagline, and previous positioning language all needed to be retired from external communications immediately. But different writers were still using them out of habit. One document used the old name and new name in the same paragraph. Another used the old tagline in a pull quote. The terminology rules caught every instance before the documents went out.
For each term on your list, decide: approved, banned, or conditional (acceptable in some contexts but not others). Write the approved alternative next to every banned term. If a term is conditional (for example, the old brand name might be acceptable in a "formerly known as" construction but nowhere else), note the specific context where it is allowed.
This section prevents the most visible errors. A rebrand that uses the old name in its own announcement materials signals a company that has not thought through its own change.
Section 2: narrative framework
This is the core message, broken into parts, that every document must reflect.
For the company rebrand, the narrative had three parts: why the change was happening (the company had outgrown its original positioning, not because the old brand failed), what it meant for clients (same team, same service standards, new capabilities), and what the new brand represented (a specific positioning statement that captured the company's direction). The narrative explicitly prohibited two framings: never position the rebrand as a reaction to a problem, and never imply the old brand was deficient.
To build this for any multi-document project, answer three questions. What is the core message? What are the two to three supporting points that every audience needs to hear? What framings are explicitly prohibited?
Write it down in plain language. Three to five sentences for the core message. One sentence per supporting point. One sentence per prohibited framing. This is not a press release. It is the backbone that every press release, internal memo, client letter, and social post draws from.
Every document will emphasise different parts of the narrative depending on the audience. But no document should contradict the narrative or introduce a framing that is prohibited.
Section 3: audience registers
Different audiences need different emphasis, but all audiences need a common core so the message does not drift.
For the company rebrand, seven audiences needed communication: staff, existing clients, prospects, partners, media, industry bodies, and social media followers. Each had different concerns.
Staff needed clarity about what was changing operationally and reassurance about what was staying the same. Existing clients needed confirmation that their service, team, and terms were unaffected. Prospects needed to understand the new positioning and what the company now offered. Partners needed confirmation that business relationships were continuing under the new brand. Media got the rebrand announcement with the narrative framework and a media kit. Industry bodies needed updated registration details and positioning. Social media followers got a shorter, more conversational version of the core narrative.
To build this section, list every audience that needs a document. For each audience, write one sentence answering: what is this audience's primary concern? Then note which parts of the narrative framework (Section 2) should be emphasised for this audience.
The common umbrella section appears in every document. The tailored emphasis changes per audience. This structure ensures that if a staff member reads the client letter, or a journalist sees the partner communication, the messages are consistent. Different in emphasis, identical in substance.
Section 4: communication tone
Different document types require different registers. An internal memo reads differently from a client letter, which reads differently from a press release, which reads differently from a social media post.
For the company rebrand, three registers were defined. Internal (direct, energetic, plain language, focused on what is changing and what each person needs to do). External formal (measured, confident, forward-looking, no speculation about competitors or market conditions). External conversational (warm, accessible, shorter sentences, used for social media and community-facing content).
To build this, look at the types of documents you are producing and group them by register. For each register, write two to three rules that define the tone. What is the default sentence length? Is the tone formal or conversational? Are contractions acceptable? How direct should the language be?
This section prevents the situation where an internal memo sounds like a press release, or a social media post sounds like a legal document. Each register has its own rules. The writer checks which register applies before they start.
Lock the reference file, then produce
Once all four sections are written, the reference file is locked. No further changes without sign-off from the project lead. This is the single source of truth for every document in the project.
From this point, every editor works from the same reference. Terminology is consistent because the approved terms are defined. The narrative is consistent because the core message and its parts are written down. Audience emphasis is consistent because each audience's primary concern and tailored messaging is mapped. Tone is consistent because the registers are defined.
The fifteen documents for the rebrand came together faster after the reference file was built than they would have if editing had started on day one. The writers were not faster. Nobody was guessing. Every decision that should be made once (what do we call ourselves now, how do we frame the change, what tone do we use for this audience) was made once, in the reference file, and applied everywhere.
When to use this method
Any time multiple people are producing output that should sound like it came from one voice. The rebrand is one example. Here are others.
Press releases across multiple clients. Each client has a brand voice guide. But the firm's editorial standard, anti-AI checklist, and QA checklist are shared across all clients. The reference files stack: firm-level standards plus client-level voice.
Monitoring reports from different analysts. If three analysts produce monitoring reports for the same client and the reports read differently, the problem is not the analysts. The problem is a missing format guide and QA checklist. Build the reference file. The output becomes consistent.
Newsletter editions across months. If the January newsletter sounds different from the March newsletter because different people wrote them, the newsletter needs a voice and format reference file that persists across editions. Build it once. Maintain it quarterly.
Crisis communications. An incident happens. Statements need to go to media, clients, staff, regulators, and social media within 24 to 48 hours. Speed pressure means multiple people writing simultaneously. Without a locked narrative, terminology rules, and audience registers, the statements contradict each other. Build the reference file first, even under time pressure. Thirty minutes spent locking the narrative saves hours of recall and re-editing.
Event briefings for different stakeholders. If the CEO briefing, the media briefing, and the sponsor briefing for the same event contradict each other or carry different tones, the event needs a narrative framework and audience register map before anyone starts writing.
The pattern is the same every time. Multiple documents. Multiple writers. One voice required. Build the reference file first. Lock it. Then produce against it.
How to build your first reference file this week
Pick a project or client where multiple people produce output that should be consistent but is not. Your highest-volume client or your next multi-document project.
Section 1: Terminology rules. Pull existing documents. List every term used to describe the company, its products, its stakeholders, and its key messages. Flag variations. Decide which terms are approved, which are banned, and note the approved alternative for every banned term. Time: 60 minutes.
Section 2: Narrative framework. Write the core message in three to five sentences. Write two to three supporting points. Note any framings that are explicitly prohibited. Time: 30 minutes.
Section 3: Audience registers. List every audience. Write one sentence per audience describing their primary concern. Note which parts of the narrative framework each audience should hear emphasised. Time: 30 minutes.
Section 4: Communication tone. Group your document types by register. Write two to three tone rules per register. Time: 20 minutes.
Total time: under three hours. The reference file is done. Lock it. Share it with every person producing documents for that project or client. The first set of documents produced against the reference file will tell you whether it is specific enough. If inconsistencies still appear, the reference file is missing something. Add it.
Within one to two iterations, the file stabilises. Consistency is a system outcome, not a talent outcome. The reference file does the work that used to require a senior editor reviewing every document and catching every variation manually.
When your team produces documents, is there a single reference file that defines what "right" looks like across all of them? Or is each writer making different choices every time?
Gabriel Tan is the founder of Mekong Bridge Advisory. He builds structured execution systems for PR and communications firms.
