A content pipeline that cannot publish itself
Website copy work usually runs on hunches, and automating it means handing a model write access to a live site. We built the other version: the agent reads and proposes, plain code computes the before and after, and one click by a person is the only thing that publishes.
- FieldContent operations
- EngagementOur own build, layered onto open-source software
- StatusComplete and gated, live publishing switched off
Built so the part that decides cannot write
The pipeline reads a site's own search performance and turns it into a ranked queue of specific, page-level wording changes. It edits text: body copy, page titles, descriptions and headings. It never touches code, layout or configuration, and it never writes a new article.
It runs as two separated planes. One holds the evidence, the review queues, the audit trail and the code that writes. The other is the agent, which reads the current wording and records a proposal. Once a change is approved, the server publishes it through whichever channel the site uses: a change request on the site's own repository, an object store, a content system's own publishing interface, or a clearly written handoff to the client's technical staff when their platform has no way to accept a write.
Content changes nobody could check or contain
This work usually goes wrong in one of two ways: it is argued from opinion, or it is automated by something given more access than anyone would grant a new hire.
Decisions made on a hunch
Which page to change, and what to change on it, came out of a meeting. The site's own performance data already existed; nobody had turned it into a queue of work.
Automation with more access than trust
An agent that can edit a file can edit the wrong file. Giving a model write access to a live site means relying on it to leave code, layout, redirects and metadata alone, and relying on something is not the same as preventing it.
Sign-off with nothing to sign off on
When the system making a change also writes the summary of it, the review has no independent object. A reviewer approves a description of the change, and which of the two was accurate shows up later.
Every capability here exists to stop something
The pipeline is built out of what it refuses to do. Each item below is a control.
The part that decides cannot write
In normal operation the agent reads the current wording and records a proposal. That is the whole of its authority. It cannot clone a repository, edit a file or make a commit, and no instruction can grant it those, because it was never given them.
- The agent reads current text and records a proposal
- It cannot clone a repository, edit a file or make a commit
- Every write is performed by the server, and only after approval
Guards that end outside the agent's reach
Layered checks confine any change to content text. The actual change is re-checked before it can be committed, and the last check runs as a required status on the build server, where the agent has no way to influence it.
- Every change is confined to content text and cannot touch code, layout or configuration
- The final check runs on the build server, outside the agent's reach
- Translation files accept changed wording and keep their keys locked
A before and after that code computed
The change list a reviewer reads is computed from the real change by plain code. That same computed text is what the drafting model is given as its ground truth and what a second model checks the message against. A model can describe a change; it cannot invent one.
- The before and after list is computed from the real change
- A second model checks the message against that same computed list
- Each proposal carries the search evidence that raised it
One click, and only that click
Approval is a single conditional update to one record. The first click decides and nothing after it changes anything, so a duplicate click, a forwarded link or a corporate mail scanner opening the link in advance is harmless.
- The first click decides; a repeat click changes nothing
- Approval links are single use, short lived and stored only as hashes
- A reply saying yes only sends a confirmation link
What happens after someone says yes
An approval starts a write, and the write is the part that can damage a live site. So the publishing path is the most fenced part of the system.
Publishing starts switched off
Writing to a live site stays off until someone deliberately turns it on. Turned on but with no measurement window in place still counts as off: the pipeline will not write into a state it cannot observe.
It switches itself back off
A measurable fall in organic search traffic or a rise in crawl errors turns writing off again on its own, without anyone having to be watching at the time.
Every publish is reversible
Each channel captures a way back before it writes anything, saves a draft, checks the preview, publishes, checks the live page, and reverts by itself when that check fails.
It cannot blank what it did not touch
A protected-field check runs on the change before any write and again on the rendered page, so canonical tags, indexing directives, redirects and page metadata come through an edit intact.
What it changes, and where it stands
No figures on this page. What follows is what the pipeline does in operation: drafting from signals, holding for review, and publishing only what a person signed.
Checkable
Every proposal
A reviewer reads the exact before and after, computed by code, with the search evidence that raised it sitting beside the text. Sign-off becomes a decision instead of a formality.
Reversible
Every publish
Nothing is written without a way back captured first, and a live page that fails its check is put back without anyone being called.
Gated
Where it stands
Proposal to approval to publish runs end to end under automated tests, and a separate harness grades whether the pipeline is working. Publishing stays behind the sign-off switch at every step.
Would you approve what your automation is about to do?
If a system is going to change something you own, the useful question is what stops it. We design the stops first, then the automation.
Discuss your project