Anyone who manages content knows the sinking feeling: you update the published post, then realize the source still contains the old language. Or you fix the source and forget the published copy. Now both versions look legitimate, and the next person to touch the content has to work out which one should win.
That problem is built into any publishing workflow that uses more than one system. For Structured Ink, I develop an article in Notion, alongside the reason for writing it, the other work it relates to, its draft state, metadata, and the decisions still to be made. Once the article is approved for the website, the exact copy moves into GitHub, where it becomes part of the site itself.
Both systems need information about the same article, but they do not own the same decisions. Preventing drift depends on knowing which system is authoritative for which information and how approved information moves between them.
“Current” Needs a Qualifier
We often call something the current version as though “current” has one obvious meaning.
While I am developing an article, the current version is the one I am actively shaping and reviewing. Most people would expect that to be a rough draft, though with me it might just be in my head. I write in my head a lot before putting the words down.
After publication, “current” means something else. The current public version is the one the website is actually serving. The editorial record still matters, but it cannot overrule what a reader can see.
Notion records the article as editorial work: the question I am trying to answer, the series it belongs to, its review state, its metadata, and the choices surrounding publication. GitHub holds the approved website artifact: the exact words, the metadata used by the site, and the history of what changed. Neither system tells the whole story because each supports a different decision.
The relationship fails when those decisions are not named. If the article is edited independently in both places, there is no reliable way to know which change should win. If the website is live but the planning record still says “not started,” the record is no longer useful. The problem is not that two versions exist. It is that their relationship has become unclear.
Duplication Is Not the Same as Conflict
“Never duplicate information” sounds like sensible systems advice. Sometimes it is. Copying the same fact into five different fields and expecting every copy to stay synchronized is a reliable way to create stale information.
I have dealt with the same problem in docs-as-code systems—and in documentation environments that needed those disciplines—especially when several branches and release trains were moving at once. On XML projects at Cisco, and later with HSG at Everfox, patches and updates had to be carried across multiple active branches and releases. The same bug might be fixed in more than one patch or release, while each release still had legitimate differences that had to remain intact.
The job was never simply to make every copy match. It was to apply the right change to every affected version without overwriting the differences between branches or release trains. That required knowing which versions should receive an update, which source governed the change, and which differences were intentional.
That experience is why I distinguish duplication from conflict. Repeated information can be correct when each instance serves a known version, audience, or purpose. It becomes dangerous when nobody knows which differences are intentional, which updates should propagate, or which source governs the next decision.
A published article and its editorial record are also related without being identical. One is what the reader receives. The other preserves how the work was developed, reviewed, and connected to the publishing plan.
The design problem is not to eliminate every repetition. It is to make sure that two systems are not competing to answer the same question, that the source of truth is always clear, and that the right information stays in the right place.
A Source of Truth Is a Responsibility
The phrase “single source of truth” often gets treated as a technology decision: choose the right platform, move everything into it, and inconsistency will disappear.
Real systems are rarely that tidy. Product facts may originate in one place, approved documentation in another, work status in a third, and reader behavior somewhere else. Copying all of that into one central platform can create the appearance of order while the copied information slowly becomes less reliable.
What matters is knowing where a particular claim should be settled. Which system determines whether a feature shipped? Which version of a procedure can an employee safely follow? Where is ownership recorded? What tells us what customers can see right now?
Those questions can have different answers without making the system incoherent. A source of truth is a responsibility: it identifies the place that governs a particular kind of information and the process for carrying an approved change elsewhere.
For Structured Ink, editorial responsibility does not leave Notion at publication. Notion remains the place where an article is edited and approved. GitHub holds the exact version the website currently serves. If a published article needs a change, the edit happens in Notion first. Once that edit is approved, the updated copy moves into GitHub and is published to the website. That sequence keeps the editorial source and the public artifact aligned instead of producing two plausible histories.
The Human Decision Still Matters
Automation can make the handoff safer. It can check that required information is present, preserve an exact revision, test the website, and confirm that a page is available. Those controls reduce the number of places where an ordinary mistake can become a public one.
Automation cannot decide that the article says what I mean. A status field is not approval. A clean build is not approval. A workflow reaching its next step is not approval. I still have to read the actual words and decide that this is the version I am willing to put my name on.
That is not friction to engineer away. It is the human center of the publishing system.
This is the question I use when designing a workflow: not “Where does everything live?” but “What does each system need to be responsible for?”
Two sources of truth can work inside one publishing flow. The important part is knowing which truth you are looking for, which system governs it, and how an approved change moves without losing the distinctions that need to remain.