Building a Claim Register

When you create content for five different platforms, a single factual error can spread like a virus. If you rely on your memory or separate notes for each script, you risk having a '5:30 PM shuttle' on TikTok but a '4:30 PM shuttle' on YouTube. This inconsistency damages audience trust.

To prevent this, you need a claim register. This is a central, definitive record—a single source of truth—where every approved fact lives. Instead of you, your editor, and your manager each checking a park's website five separate times to verify a shuttle time, you record that fact once in the register.

For example, you enter 'Last shuttle leaves at 5:30' into the register. Now, whenever a script needs that time, the team refers to the register rather than the original website or a random Slack message. If the park changes the time to 4:30, you update it in one place. Because the register is the only approved record, you immediately know exactly which facts need to be updated across your entire production pipeline.

A claim without a source is just a guess. To maintain audience trust, every factual claim in your register must be tethered to a specific piece of evidence and the exact date that evidence was verified. This prevents 'knowledge drift,' where a fact is repeated so many times that the team forgets where it came from or fails to notice when the original source has been updated.

Consider the claim: 'Last shuttle leaves at 5:30.' In your register, you do not simply write the time. You pair it with a direct URL to the park's official timetable page and a verification date, such as 'October 12, 2025.'

By recording the date, you create a deadline for re-verification. If you are filming in November but your source date is from October, you know immediately that the information is potentially stale and needs a fresh check. When you build your register, you treat every claim as a research entry: the claim is the what, the link is the why, and the date is the when. This discipline ensures that if a viewer questions a fact, you can point to the exact source used at that moment in time.

Knowing a fact is true is only half the battle; you must also know every place that fact is currently hiding in your production pipeline. This is where mapping comes in. Mapping is the process of listing every single version of a piece of content that uses a specific claim from your register. If you only update your main script but forget the pinned comment on YouTube, you have still published an error.

Take the '5:30 shuttle' claim. In your register, you don't just list the source; you create a map of its appearances. You record that this specific fact appears in the TikTok on-screen text, on slide four of the Instagram carousel, and in the YouTube pinned comment.

When you map your claims, you are creating a checklist for your future self. If the shuttle time changes to 4:30, you don't have to guess where the old time is or search through dozens of folders. You look at the map for that claim and see three specific targets. You then go directly to those three assets, update the text, and check them off. This ensures that the 'truth' in your register is mirrored exactly across every platform.

Your audience follows you for two different things: verified data and your unique perspective. To maintain trust, your claim register must strictly separate these. A Verified Claim is an objective fact that can be proven by an external source. A Personal Observation is a subjective experience—something only you witnessed or felt. If you mix these in your register, you risk treating an opinion as a fact or, worse, trying to find a 'source' for a feeling, which leads to misleading content.

Consider the difference in your register: The statement 'Last shuttle leaves at 5:30' is a Verified Claim because it is written on the park's timetable. However, the statement 'The steps are gentle' is a Personal Observation. There is no official 'gentleness' certificate from the park; this is based on your lived experience walking the trail with your nephew.

In your register, you mark these with different labels. You link the shuttle time to a URL, but you link the 'gentle steps' observation to your own field notes or footage. By clearly distinguishing the two, you ensure that when you update your scripts, you know exactly which lines need a source check and which lines represent your own authorial voice.

While mapping tells you which platforms use a claim, linking tells you where inside the production files that claim lives. A production asset is any specific draft, file, or scheduled item—such as a Google Doc script, a CapCut project, or a scheduled Facebook post. Without direct links, your team spends valuable time hunting through folders to find the exact line that needs changing.

For example, take the claim 'The walk has 300 steps.' In your register, you don't just list 'YouTube'; you link the claim directly to the specific assets. You might create a link to the 'YouTube_Walkthrough_Final_Script.docx' and specify the exact location: the Chapter Title for the 4-minute mark. Similarly, you link the claim to the 'Snapchat_Story_Draft_02' file, specifically the text overlay on the third clip.

When a fact changes, you don't search for keywords; you click the links in your register. This takes you instantly to the exact asset and line that requires an update. This process transforms your register from a passive list into an active navigation map for your entire production pipeline, ensuring no stray mention of an old fact survives the final export.

To ensure your team never misses a detail, the claim register cannot be a random list of notes. It must follow a strict, repeatable structure. This standardization transforms the register from a simple document into a reliable system that anyone on your production team can use without asking you for clarification. By keeping a consistent order, you ensure that every 'what' (the claim) is immediately paired with its 'why' (the source), 'when' (the date), and 'where' (the versions).

Imagine you are organizing a spreadsheet. Instead of scattered comments, you build every row using this sequence: [Claim] $\rightarrow$ [Source] $\rightarrow$ [Date] $\rightarrow$ [Versions]. For the shuttle example, your row would look like this:

1. Claim: 'Last shuttle leaves at 5:30'
2. Source: 'Park Official Timetable (URL)'
3. Date: 'Oct 12, 2025'
4. Versions: 'TikTok text, IG carousel slide 4, YT pinned comment'

When you adopt this structure, you create a mental habit of completeness. You cannot enter a claim without immediately looking for the source and the date. This prevents the 'half-finished' entries that lead to errors during the final production push.