Why We Track Content Ideas in Two Places Before Publishing
By Luke Ribeiro
Overview
Overview
We rejected a finished article last week because it existed in our production database but had no corresponding planning record. The draft was fine. The metadata was complete. But without the Airtable planning entry, we had no idea why we were publishing it, who requested it, or what signal prompted it in the first place. This is why every Lukco content idea must exist in both Airtable and Supabase before it moves to published status. It's not redundancy for its own sake—it's a forcing function that catches three specific failure modes. First: calendar drift. Airtable holds our editorial calendar, the strategic context, and the original decision to commission a piece. If something makes it to Supabase (our production CMS) without an Airtable record, it means either someone skipped planning or the systems fell out of sync. Both are problems worth catching. Second: metadata gaps. Airtable fields force us to answer questions production doesn't care about: Why this topic? What client pattern or signal prompted it? Which pillar does it support? If we can't fill those fields, we probably shouldn't be writing the piece. The act of creating the Airtable record is a gate, not just a log. Third: automation boundaries. Our promotion workflow checks both systems before moving a post live. If the Airtable record is missing, the automation stops. This isn't defensive programming—it's an explicit choice to make the system brittle in ways that protect editorial intent. The cost is minimal: creating two records instead of one. The benefit is that we never publish something by accident, never lose track of why we commissioned work, and never let tooling drift create invisible gaps between planning and execution. Single-source-of-truth is a fine principle for operational data. For content, where the why matters as much as the what, we want the friction of dual validation. It's a tax we pay willingly because the alternative—publishing without context—is worse than the overhead of maintaining two records. When systems disagree, the workflow stops. That's the point.
We rejected a finished article last week because it existed in our production database but had no corresponding planning record. The draft was fine. The metadata was complete. But without the Airtable planning entry, we had no idea why we were publishing it, who requested it, or what signal prompted it in the first place.
This is why every Lukco content idea must exist in both Airtable and Supabase before it moves to published status. It's not redundancy for its own sake—it's a forcing function that catches three specific failure modes.
First: calendar drift. Airtable holds our editorial calendar, the strategic context, and the original decision to commission a piece. If something makes it to Supabase (our production CMS) without an Airtable record, it means either someone skipped planning or the systems fell out of sync. Both are problems worth catching.
Second: metadata gaps. Airtable fields force us to answer questions production doesn't care about: Why this topic? What client pattern or signal prompted it? Which pillar does it support? If we can't fill those fields, we probably shouldn't be writing the piece. The act of creating the Airtable record is a gate, not just a log.
Third: automation boundaries. Our promotion workflow checks both systems before moving a post live. If the Airtable record is missing, the automation stops. This isn't defensive programming—it's an explicit choice to make the system brittle in ways that protect editorial intent.
The cost is minimal: creating two records instead of one. The benefit is that we never publish something by accident, never lose track of why we commissioned work, and never let tooling drift create invisible gaps between planning and execution.
Single-source-of-truth is a fine principle for operational data. For content, where the why matters as much as the what, we want the friction of dual validation. It's a tax we pay willingly because the alternative—publishing without context—is worse than the overhead of maintaining two records.
When systems disagree, the workflow stops. That's the point.