Schema-First Gates for Reliable AI Publishing Pipelines

The most useful publishing agent is not the one that writes fastest. It is the one that refuses to publish an invalid artifact.

AI can generate a polished article in seconds. That makes writing look like the hard part of an automated publishing system.

In production, it usually is not.

The fragile part is the boundary between a plausible document and a valid repository artifact. A model can produce a sensible category name, a clean slug, a source list, and a hero reference that all look correct while violating the exact contract the website expects. If the pipeline discovers that mismatch only after pushing to the default branch, CI has become the first validator instead of the second verifier.

That is backwards.

A reliable publishing pipeline should be schema-first: inspect the contract, generate against it, validate before mutation, let CI independently repeat the checks, verify deployment, and only then call the article published.

repository contract
      ↓
generate article + media
      ↓
pre-commit validation
      ↓
commit
      ↓
CI / build
      ↓
deploy
      ↓
live verification
      ↓
published

This sounds conservative. In practice, it is what allows the automation to become more autonomous.

The Dangerous Gap Between “Reasonable” and “Valid”

Language models are optimized to produce plausible outputs. Repository schemas are designed to accept only exact outputs.

Those goals overlap, but they are not identical.

Imagine a site with a constrained topic field:

const TOPIC_IDS = [
  'ai-agents',
  'android-mobile',
  'developer-tools',
  'devops-cloud',
  'knowledge-systems',
] as const;

An article about Android release engineering might tempt an agent to emit:

topic: android-engineering

Semantically, that value is perfectly reasonable. Structurally, it is invalid.

Astro content collections are explicitly designed to catch this class of mismatch. A collection schema defines the shape of content data, and Astro reports an error when an entry does not match that schema. The important architectural lesson is not merely that validation exists. It is where validation belongs in the workflow.

If the agent can read the schema before writing, guessing an enum is unnecessary.

Treat the Repository as the Source of Truth

A publishing prompt can describe intent:

• choose a topic,
• create SEO metadata,
• attach a hero,
• add sources,
• publish when ready.

But the prompt should not duplicate every implementation detail of the repository. Those details evolve.

The repository should own constraints such as:

• allowed topic IDs;
• required frontmatter fields;
• ID formats;
• maximum title and description lengths;
• media dimensions;
• asset manifest structure;
• permitted MIME types;
• source URL rules.

This is the same separation that makes other agent systems more reliable: intent lives at the orchestration layer, while executable constraints live close to the code that enforces them.

For a broader version of that idea, see Multi-Agent Review Pipeline for AI Coding Agents, where implementation and verification are deliberately separated instead of asking one model to trust its own output.

Schema-First Means Reading Before Generating

The first gate should happen before the article exists.

An agent should inspect the current schema and extract constrained values. It should not rely on remembered values from an earlier run, documentation copied into a prompt, or a semantic guess.

A practical sequence looks like this:

1. Read content schema
2. Read topic/category definitions
3. Read media policy
4. Read one or two current valid articles
5. Generate against those contracts

This makes the generation task narrower.

Instead of asking the model, “What category fits this article?”, the system asks, “Which member of this current allowed set best fits the article?”

That small change converts an open-ended language task into a constrained classification task.

It also prevents schema drift from becoming prompt drift. When the repository changes, the next run sees the new contract directly.

Pre-Commit Validation Is the Real Publish Gate

The second gate happens after generation but before repository mutation.

At this point, the pipeline should have the complete candidate artifact: Markdown, frontmatter, sources, media manifest, and physical hero asset. Now it can run the same checks a developer would run locally.

For a static content repository, that may include:

npm run validate
npm test
npm run check
npm run build
npm run verify:dist

Not every change needs every command, but schema and content validation should be non-negotiable before a publishing commit.

The rule is simple:

If deterministic validation can reject the artifact before commit, do not wait for CI to reject it after commit.

This is especially important for autonomous agents because a commit is a side effect. Once the default branch changes, other systems may react: CI starts, deployment hooks fire, notifications appear, caches invalidate, and downstream automations consume the new state.

Pre-commit validation keeps malformed artifacts out of that chain.

CI Should Verify, Not Discover the Obvious

CI remains essential even when local validation passes.

The two gates solve different problems.

Pre-commit checks answer:

Does the candidate satisfy the repository contract in the environment available to the publisher?

CI answers:

Does the committed state satisfy the contract in the canonical clean environment?

GitHub Actions exposes workflow status and per-step logs specifically so failures can be diagnosed at the job and step level. That makes CI an excellent independent verifier.

But if CI repeatedly catches invalid enum values, malformed frontmatter, missing asset files, or incorrect hashes that the publisher could have checked beforehand, the pipeline has pushed responsibility too far downstream.

A healthy split looks like this:

Gate	Primary job
Generation constraints	Prevent unsupported values from being invented
Pre-commit validation	Reject malformed candidate artifacts
CI	Reproduce validation in a clean canonical environment
Deployment verification	Confirm the built artifact reached the hosting boundary
Live smoke test	Confirm readers can actually access the intended result

Each gate should add confidence rather than repeat avoidable mistakes.

Media Needs the Same Contract Discipline

Text is only half of a modern article pipeline.

A generated hero can exist visually and still be invalid operationally. The repository may require a specific width and height, a unique asset ID, a physical file, a content hash, a manifest, alt text, provenance, and a public path.

Those are not editorial details. They are integrity constraints.

A safe media pipeline should therefore verify:

generated image
→ required dimensions
→ encoded web asset
→ byte count
→ SHA-256
→ unique asset ID
→ manifest
→ article reference
→ rendered public path

Notice that “the model generated an image” is only the first step.

The asset becomes publishable only when the repository can prove what file it has and how the article references it. This is why a fake path or guessed hash is worse than a blocked publication: fabricated metadata destroys the verification chain.

Source Links Need Render Verification Too

Source metadata can also pass a superficial review while failing readers.

A source may have a valid HTTPS URL in frontmatter, yet the renderer could output plain text instead of an anchor. Or the URL could resolve to a generic landing page rather than the evidence the article relies on.

A robust pipeline checks three layers:

1. Evidence: the source actually supports the factual claim.
2. Metadata layer: the real title and URL are stored in the article contract.
3. Rendering: the final Sources section contains clickable links.

This is a useful pattern beyond publishing. Validation should follow data across boundaries instead of stopping where the producer hands it off.

“Committed” Is Not a Publication Status

One of the easiest automation mistakes is treating a successful write operation as the business outcome.

A Git commit proves that Git accepted a new repository state.

It does not prove that:

• CI passed;
• the static site built;
• deployment completed;
• the new route exists;
• the hero loads;
• source links are clickable.

So the state machine should not be:

draft → committed → published

It should be closer to:

candidate
→ locally_valid
→ committed
→ ci_verified
→ deployed
→ live_verified
→ published

This distinction matters because status drives behavior. If the system marks a topic processed at committed, a failed deployment can cause the next run to move on and leave a broken article behind.

The cursor should advance only at published.

Auto-Recovery Works Better With Narrow Failure States

Once the pipeline has explicit gates, recovery becomes easier to automate.

A failure can be classified by boundary:

• schema failure: regenerate or repair metadata;
• media failure: re-encode, resize, re-hash, or rebuild the manifest;
• source failure: replace or remove unsupported evidence;
• CI failure: inspect the failing step and repair the attributable artifact;
• deploy failure: retry only when the failure is transient or fix the deployment-specific issue;
• live verification failure: inspect routing, rendering, or propagation before declaring success.

That is much better than one generic BLOCKED state.

The agent can keep working when the remedy is safe and deterministic, while still stopping at real authorization, credential, licensing, or governance boundaries.

Autonomy Comes From More Gates, Not Fewer

It is tempting to make an autonomous publisher “more autonomous” by removing checks.

That usually creates an agent that acts more often but can be trusted less.

The stronger approach is to automate the checks along with the actions.

This is also why the architecture in How to Automate Medium Publishing Without a New API Token deliberately separates deterministic preparation from provider boundaries. The principle is the same even when the canonical destination is your own site: automate what can be verified, and make every irreversible boundary explicit.

A trustworthy publishing agent can be aggressive about recovery because it is conservative about truth.

It knows the difference between:

• generated and stored;
• stored and valid;
• valid and committed;
• committed and deployed;
• deployed and live.

That vocabulary is not bureaucracy. It is the control surface that makes unattended execution possible.

A Practical Minimum Contract

If you are building an AI publishing workflow today, start with five rules:

1. Read constrained values from the current repository before generation.
2. Run deterministic validation before every publishing commit.
3. Treat CI as independent verification, not the first validator.
4. Require physical, hash-verifiable media instead of metadata-only assets.
5. Advance the processing cursor only after live verification succeeds.

Then add recovery logic around each boundary.

The result is slower than “generate and push” on the happy path by a few checks. It is dramatically faster when something changes, because failures become local, attributable, and repairable.

That is the real goal of an autonomous editorial pipeline: not publishing without humans at any cost, but producing a result whose state can be proven at every step.