Where the TrustGrowth blog fails the Baseline today

The TrustGrowth blog does not currently conform to our own Open Blog Baseline, and it has not moved to open_blog. We wrote the rules before our own blog met them.

The public Baseline page lists four current failures:

1. We have no public editorial policy (E16).
2. We have no public corrections policy (E8).
3. We have no statement explaining how AI is used to make posts (E17).
4. Our modified date follows the last save, not the last substantive change (E6).

This is a candid account of our current position. The Baseline is TrustGrowth’s own document. It was issued by no standards body, is not an industry standard, and is not legal advice. This post is not a certification or a legal assessment.

What the Baseline is, and what this post is not

The Open Blog Baseline version 0.6.1 was ratified on 2026-10-02. It contains 37 MUST rules and 9 SHOULD rules, each with a stated basis. Its text is licensed under CC BY 4.0.

The four failures in this post come from the public Baseline page and its rules E16, E8, E17, and E6. We are describing our blog’s current state against that public text. We are not quoting or summarising any unpublished conformance specification.

Nothing in this post sets a repair date. Nothing here depends on a hosting change. The question is narrower: does the TrustGrowth blog currently meet the four public rules named above?

Our answer is no.

Failure 1: no public editorial policy (E16)

The public rule says:

“The site has a public editorial policy. It says how posts are selected, written, reviewed, published and corrected.”

This is a MUST rule. Its stated basis is “Our policy.” The page also gives analogies to JTI 9.1 and IFCN commitment 4.

Our current state is straightforward: the TrustGrowth site has no public editorial policy.

That means a reader cannot find a linked public page explaining how our posts are selected, how they are written, how they are reviewed, how they are published, and how they are corrected. We may have internal practices, but internal practices are not the same thing as a public editorial policy.

What meeting E16 would look like

A reader would find a public page linked from the site. That page would explain the editorial process in practical terms, including:

• how topics and posts are selected;
• how posts are written;
• what review takes place before publication;
• how posts are published; and
• how corrections are handled.

The rule asks for a public explanation of the process. It does not ask readers to infer that process from individual articles.

Failure 2: no public corrections policy (E8)

The public rule says:

“The site has a public corrections policy, and it says how a reader reports an error.”

This is also a MUST rule. Its stated basis is “Our policy,” with analogies to IFCN commitment 5 and the Trust Project.

Our current state: the TrustGrowth site has no public corrections policy.

A reader therefore cannot find a public policy that explains how to report an error. That is the specific gap named by E8. We are not claiming that publishing a corrections policy would make content free of errors. The rule is about making the reporting route and corrections approach public.

What meeting E8 would look like

A reader would find a public corrections policy with a clear way to report an error. The page would tell the reader where to send the report or what other public route to use, and it would explain how corrections are handled.

The useful test is simple: can a reader locate the policy, understand what counts as an error report, and see how to submit one? At present, our blog does not provide that public route.

Failure 3: no statement of how AI is used (E17)

The public rule says:

“The site says how AI is used to make posts.”

E17 is a MUST rule. Its stated basis is “Our policy.” The Baseline describes this as our own transparency commitment, not a general legal requirement. The page also notes a recommendation from Google helpful content and analogies to JTI 10.6, the Paris Charter, and NewsGuard.

Our current state: the TrustGrowth site has no statement explaining how AI is used to make posts.

This is a disclosure gap, not a claim about the quality or performance of AI-assisted content. We are not saying that AI use is inherently good or bad. We are saying that the public blog does not currently explain how AI is used in the making of its posts.

What meeting E17 would look like

A reader would find a public statement that explains how AI is used to make posts. The wording would need to describe our process clearly enough for a reader to understand the role AI plays in creating published material.

The rule does not require us to claim that AI-assisted content performs better. It requires a public explanation of use. That explanation is currently absent.

Failure 4: the modified date follows the last save (E6)

The public rule says:

“The modified date of a post is the date on which its last substantive change became public. For a post with no such change, it is the publish date. No other event moves it. This is true for the date that the reader sees, if the post shows one, and for the date in the structured data and the sitemap.”

E6 is a MUST rule. Its stated basis is a recommendation from Google sitemap documentation and a Google blog post from 2019.

Our current state: on the TrustGrowth blog, the modified date follows the last save.

A last-save time and a substantive-change date are different things. A last-save time can move because a page is saved, even when the change would not alter how a reader understands the post. The Baseline takes a narrower approach.

For this purpose, a substantive change is a change to a published post that is likely to change how a reader understands it. A spelling correction is not a substantive change. A template change is not a substantive change. Under E6, neither should move the modified date.

What meeting E6 would look like

The modified date would move only when a substantive change becomes public. If a published post has no substantive change, its date would remain its publish date. The same principle would apply to the date shown to readers, the date in structured data, and the date in the sitemap.

The rule is about date accuracy and meaning. It does not establish an effect on rankings, AI citations, reader trust, traffic, or any other outcome. We are making no such claim.

What this post does and does not establish

This post lists four current failures against TrustGrowth’s own public document:

• no public editorial policy;
• no public corrections policy;
• no public statement of how AI is used to make posts; and
• a modified date that follows the last save rather than the last substantive change.

It does not establish a legal violation. It does not establish a failure against an industry standard. The Baseline is not an industry standard. It also does not establish any business effect. We are not claiming that these gaps change rankings, citations, traffic, conversions, or reader behaviour.

We are also giving no date for a repair. The current condition can change when the site changes, but this post does not promise when that will happen.

Do this next: a four-rule check for your blog

You can apply the public Baseline rules to your own blog without treating the result as a certification. For each row, mark meets the rule, does not meet the rule, or not checked.

Rule	Check	Record
E16	Can a reader find the editorial policy from the blog?	Record the URL.
E8	Can a reader find the corrections policy and the way to report an error?	Record the URL.
E17	Can a reader find a statement explaining how AI is used to make posts?	Record the URL.
E6	Does the modified date move only when a substantive change becomes public?	Record the page and what you saw.

For E6, compare the date behaviour with the rule’s definition. A substantive change is one likely to change how a reader understands the published post. A spelling correction or template change is not one. Do not mark the rule based only on whether a page displays a date; check what causes that date to move.

For E16, E8, and E17, test what a reader can find publicly. Do not count an unpublished internal process as a public policy or statement.

Method note

The four failures described here are the ones stated on the public Open Blog Baseline page, read against Baseline version 0.6.1. This is a statement of our current state and can change when the site changes. It is not based on a sample of posts, a score, or a re-check date.

Read the Open Blog Baseline and run the four checks on your own blog.