Approval is a question, not a gate

An agent can write and publish a blog post without leaving a record of which revision a person approved. The page is public, the workflow says “approved,” and yet a second person may not be able to identify the exact text, approver, or time involved.

Approval is better understood as a question put to a person about one exact text. The answer is a record. It is not an abstract publishing switch that a workflow flips from “pending” to “approved.”

This article explains the shape of that record. It does not claim that any workflow meets a rule, and it reports no publishing, legal, trust, or business outcome.

What exactly did the person approve?

“The post” is not precise enough. A post can change after review. An agent can rewrite a paragraph, a marketer can correct a fact, or a publishing job can send a different revision than the one shown to the reviewer.

The useful object is one exact public revision: the text that readers actually receive at a particular point in time.

Illustration, not a measured result.

At 09:00, an agent produces revision A. A person reviews and approves it. At 09:20, the agent changes the headline and publishes revision B. A workflow that retains only a general “approved” status cannot answer whether the person approved revision B. A revision-level record can show that approval was attached to revision A, while revision B required a separate decision.

The practical question is simple:

Can a second person identify the exact text, the approver, and the time of the approval?

If the answer depends on memory, a chat message with no revision identifier, or a status field detached from the content, the record is incomplete for that question.

This distinction matters even when the person and the content team are acting in good faith. The issue is not whether someone intended to approve the post. The issue is whether the workflow can connect the person’s answer to the exact text that became public.

Why a publishing gate is not the same as an approval record

A gate says that a step passed. An approval record says who answered, which revision they answered about, and when the answer was recorded.

Those are different operational facts.

A gate might block publishing until an approved value is present. But the value may not identify the revision. It may not show whether the text changed afterwards. It may not distinguish approval from a different action, such as marking a draft ready for another review.

An evidence-based model asks the workflow to preserve the relationship between:

• the exact content;
• the person who reviewed it;
• the approval decision actually given; and
• the time at which that decision was recorded.

That model does not prevent every publishing error. It does not establish that an approval was thoughtful, that every factual claim was checked, or that a process satisfies an external requirement. It gives you a narrower and more inspectable question: which public revision received which person’s approval?

Treat the distinction as an auditability question, not as a promise about the quality of the decision.

How the Open Blog Baseline frames the question

The Open Blog Baseline frames approval around the public revision. Rule E18 states:

“The public revision of a post with the provenance ai_assisted or unknown has an approval. The approval is made before the revision becomes public. One exception: when a revision became public without an approval, a late approval of that exact revision satisfies this rule from the time of the late approval.”

The Basis given by the Baseline is “Our policy.” It also says this is one of the two conditions of the EU AI Act text exemption, referring to guidelines points 133 to 135. Read the published Open Blog Baseline for the precise wording and context before relying on this description.

Rule E19 adds:

“Each change to an approved revision of a post with the provenance ai_assisted or unknown makes a new revision, and the new revision needs its own approval. This is true for a change by AI and for a change by a human. The text that the reader gets is the text that was approved.”

The late-approval sentence is the stated exception in E18. It does not turn an earlier unapproved publication into an earlier approval. It says that approval applies from the time of the late approval.

The Open Blog Baseline is TrustGrowth’s own document. It was issued by no standards body, and it is not legal advice. Do not treat the Baseline as a universal definition or as a conclusion about your own obligations.

How open_blog 0.1.0 treats the approval

The published open_blog documentation describes open_blog 0.1.0 as an MIT-licensed Rails engine operated through Ruby, a JSON API, or MCP tools. It has no admin screen. The documentation says that every publish, edit, approval, and removal leaves an immutable record.

The described data model includes who wrote a post, who reviewed which revision, and whether facts were checked. Ruby operations compute a revision identifier from the content. An agent must show the exact text to a person and record only the approval that person gives.

That sequence is the important part. The agent does not ask for a vague approval of an evolving object. It presents the text. The person answers about that text. The system records that answer against the revision.

The implementation still has boundaries. An immutable record does not guarantee that the approval was careful or that the text is accurate. It does not establish reader trust, legal sufficiency, or any particular publishing result. It preserves an event for inspection; it does not settle the meaning or quality of the decision.

A pass of the gem's surface checks does not establish conformance.

The TrustGrowth blog does not conform to the Baseline today and has not moved to open_blog.

If you want to inspect the implementation rather than infer its behavior from a summary, read the published project documentation and the gem README. If you install it, verify the current version and mechanics against those sources before making workflow decisions.

What to inspect in your own workflow

Use the questions below for a review, not as a certification checklist. There is no pass threshold here. Your aim is to find out what your records can and cannot show.

Start with one recently published AI-assisted post. Retrieve the public text. Then locate the approval event and compare the text attached to it with the text readers received. Do not begin by asking whether the workflow is “approved.” Begin by asking what the record proves.

If an agent edited the post after a person reviewed it, inspect the edit boundary. A changed headline is still a change. A human correction is still a change. The question is not who made the edit; it is whether the public text is the same revision that received the approval.

A practical review sequence

1. Capture the public text. Save the exact revision readers can access, not only the draft title or URL.
2. Find the revision identifier. If none exists, record that limitation rather than reconstructing one from memory.
3. Locate the person’s decision. Separate approval from comments, assignment, fact-checking, or a general “ready” status.
4. Compare timestamps. Put approval and publication events in order.
5. Check later changes. Look for edits by both agents and humans after approval.
6. Preserve the event trail. Confirm that editing, publishing, approval, and removal are distinguishable.
7. Write down the unknowns. A review is more useful when it records what the system cannot establish.

This sequence is deliberately narrow. It does not evaluate the writing, verify every factual statement, or decide whether a process is legally sufficient. It tests whether the workflow can answer a specific provenance question about an exact public revision.

Method note

This is a concept and product-documentation article, not a study. It reports no adoption, legal, risk, trust, or other outcome. The sources are the public Open Blog Baseline, the open_blog documentation, and the gem README. Verify the current project pages before publication because implementation details and wording can change.

The question to carry forward

Approval is a question about one exact text, and the answer is a record. A publishing gate may tell you that a workflow step passed. It does not, by itself, tell you which revision a person approved or whether that revision is the one readers received.

Read the published open_blog documentation and Open Blog Baseline, then inspect one AI-assisted post in your own workflow: identify the exact public revision, the person who approved it, and the record that proves which text received that approval.

If you want to examine the implementation directly, read the documentation or install with bundle add open_blog then bin/rails generate open_blog:install.