Where a Git Repository Stops Being Enough for Publishing

Our first blog workflow was a Git-tracked folder of Markdown. It was simple, transparent, reviewable and portable, and it fit the work it supported. A file-based source of truth is a legitimate design, and for a modest publishing workflow it may be the best one.

The architecture question changed when the workflow needed stronger guarantees: explicit lifecycle state, concurrent contributors with different permissions, structured review evidence, clear provenance, richer queries, controlled integrations, reliable publication controls, and a durable record of why a decision was made. At that point the real question was whether the source of truth could enforce the workflow we actually needed.

Define the control model first

Before choosing technology, we wrote down what the system has to control.

Requirement	Questions to answer
Lifecycle	What states exist? Which transitions are valid? Who may request, approve, or execute them?
Authority	What can each human, service, or tool read, propose, edit, approve, publish, or archive?
Review	What evidence is required? Which findings block release? Who resolves or accepts risk?
Provenance	Can a reader trace a claim to approved sources, review evidence, and a human decision?
Privacy and retention	What data is permitted, how is it classified, how long is it retained, and how is it deleted or recovered?
Publishing	What final authorization is required, how is it recorded, and how is the public result verified?
Operations	How are failures, retries, monitoring, backups, recovery, incidents, and changes handled?

Files, a database, a content-management system, or a hybrid can support parts of this model. Which one fits depends on scale, collaboration, existing controls, accessibility, cost, operational capacity, regulatory obligations, and the risk of a bad release.

What a repository already gives you

A repository offers version history, code review, protected branches, schema validation, content checks, and reproducible builds. Structured metadata can be validated before publication. For many teams that is enough.

The limits show up when the workflow needs durable structured state across many contributors or systems. They show up when queries and reporting become central, when different actors need field-level or transition-level authority, or when a change has to be recorded as more than a file diff. A database makes those needs easier to model, but it brings no security or governance with it.

A schema constraint catches certain invalid values. Authentication, authorization, row-level or service-level access checks, change approval, audit controls, privacy review, input validation, rate limits, secret management, monitoring, backups, incident response and human accountability all remain separate work that a schema does nothing to replace.

Make the lifecycle explicit

A content item might move through intake, research, draft, editorial review, legal or safety review where applicable, ready for release, published, corrected, and archived. Clear definitions and controlled transitions matter more than what you call the stages.

A structured system should record:

• the authoritative content version and its source references;
• the current state and allowed next transitions;
• the roles and approvals required for a transition;
• reviewer findings, disposition, and evidence;
• the source date and public display date where relevant;
• provenance, authorship, and revision history;
• publication destination and verification result; and
• retention, correction, takedown, and archival rules.

We designed this state for people first. Automation can help with collection, classification, draft preparation, duplicate detection, formatting, or review checklists, but it should run under narrow permissions and fail safely.

AI drafts, people release

AI-generated material can be incomplete, stale, biased, fabricated, or inappropriate for the intended audience. It enters the workflow as labeled draft material with clear source boundaries. It has no authority to approve, publish, change permissions, or take consequential external actions.

In a safe design, each automated component is limited to the data and fields its task needs. Inputs and outputs are validated, useful provenance is preserved, sensitive content is protected, anomalous activity is detected, and meaningful events are logged. Humans can review and override. When a service is unavailable or uncertain, the workflow pauses and waits instead of inventing certainty.

The final release decision stays an explicit human and policy-controlled act. A successful build, a passing automated review, or a completed task is evidence, not permission to publish.

Migrate in stages you can undo

When you move from one source of truth to another, keep the old system until the new one has been validated. Classify the data first and define the schema and retention rules. Map each field deliberately, then run dry migrations in a representative environment. Check record counts and semantic outcomes, reconcile differences, test backups and recovery, and keep a rollback path.

A migration changes the organization’s trust boundary and operating model, so we treat it that way.

Choosing

Use a simple file workflow when it gives the work the controls and visibility it needs. Add structure only where it solves a demonstrated problem. Move to a database or another workflow system when you need explicit state, controlled concurrent roles, richer queries, durable audit evidence, or integrations that a file-centric process cannot reliably support.

The source of truth is the place where you can correctly answer: what is this content, where did it come from, who may change it, what evidence supports it, what state is it in, and who is responsible for releasing it?

Try that on your own workflow. Pick any item and see whether the system can show its state, its sources, its review evidence, and who authorized release. If it cannot, that gap is your reason to add structure, in files or in a database. Keep automated tools and AI drafting on narrow permissions, and keep a human on the final release.

dxdev LESSON · paste into your AI coding agent
LESSON: Choose a content source of truth that can enforce its workflow
SOURCE: dxdev.com/blog/postgres-source-of-truth-for-ai-content-pipeline
WHAT HAPPENED: A publishing workflow outgrew an informal file-and-frontmatter process because it needed explicit lifecycle state, traceable review evidence, concurrent but scoped roles, controlled integrations, queries across structured metadata, and a clear human release decision. A database was one possible implementation, but the architectural need was an enforceable workflow, not a universal rejection of files.
THE RULE: Choose the smallest source-of-truth design that can enforce the required lifecycle, authorization, review, provenance, privacy, retention, observability, recovery, and publication controls. Treat AI output as untrusted draft material; it may assist within a narrow scope but must not approve, publish, access unrelated data, or override human and policy controls.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any content workflow whose lifecycle, approval, provenance, retention, or publication state is ambiguous, bypassable, or not auditable.
  2. Any actor-including an AI-assisted process-that can modify content, metadata, permissions, or publication state beyond its least-privilege role, without authorization, validation, immutable audit evidence, human release control, and safe error handling.
  3. Any proposed database or file migration without data classification, access controls, input validation, schema or content contracts, backup and recovery testing, rollback planning, observability, privacy and retention handling, and a staged non-destructive verification plan.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.