The Proof Layer: Authority Anchors and the Atomic Library

E-E-A-T Is Misapplied Almost Everywhere

E-E-A-T, Experience, Expertise, Authoritativeness, Trustworthiness, is Google’s quality evaluation framework. It’s widely understood. And it’s almost universally misapplied.

This framework treats E-E-A-T differently.

Proof is the thing.
E-E-A-T are just labels Google uses to describe it.
Proof as a structured asset graph. Proof is something a business either has or doesn’t have.

The misapplication is consistent: treating E-E-A-T as a writing quality target. Add first-person language. Include author bios. Cite sources. Structure content to signal credibility. These are surface signals, and they can be performed without any underlying substance.

Proof can’t be written into existence. The underlying evidence, results achieved, processes documented, tools built, experience accumulated, either exists as an asset the business can draw from, or it doesn’t.

The Proof Layer is the component that makes that asset graph explicit, structured, and usable at content writing time and for strategy.

Authority Anchors: A Planning Frame of Reference

Authority Anchors are six concepts used at content planning and writing time to ask a specific question: how is the expertise being expressed in this piece of content actually being proven?

They’re not labels applied to published pages. Or a tracking taxonomy for a content audit. They’re a frame of reference, a structured way of ensuring that when a Search Intent Goal is being answered, the answer is grounded in genuine proof rather than asserted authority.

The practical question each anchor prompts: do I have the assets to back this up? If the content draws on Trust and Proof, does a named result with a measurable outcome exist to support it? If it draws on Process and Education, is the process documented from real implementation rather than assembled from general knowledge? If it draws on Results-in-Advance, does the tool or resource actually exist?

At small scale, this is an intuitive check, a writer who knows the business well enough will naturally draw on real proof or recognise its absence. At larger scale, the anchor framework gives content planners a consistent vocabulary for the same check across a team or a large content inventory.

A single piece of content typically draws on one to three anchors. The selection depends on the Search Intent Goal, the cluster framing, the maturity level, and, critically, what proof assets actually exist to support each anchor.

The Six Anchors

Anchor 1, Trust and Proof Proof

Specific, named, measurable outcomes.

• Client results,
• before/after data,
• performance records,
• revenue outcomes.

The anchor that requires the hardest evidence, and produces the strongest authority signal when the evidence is genuine.

The planning question: do I have a named result with a measurable outcome that directly supports what this content is claiming?

Anchor 2, Process and Education Authority

• documented methodology,
• showing how something actually works from real implementation.

Not a generic how-to assembled from secondary sources. The business’s own process, its own implementation records, its own technical knowledge.

The planning question: am I teaching this from genuine implementation depth, or from general knowledge anyone could have?

Anchor 3, Comparisons and Decision Support

• Trust built through honest decision-making frameworks,
• Helping the audience choose well, including in situations where the business’s own offer may not be the right fit.
• Comparison Tables, Calculators, Finder Quizzes (and how accessible or gated they are)

The authority signal here is the willingness to be genuinely useful rather than reflexively promotional.

The planning question: do I have real trade-off experience and market knowledge that justifies the positions I’m taking in this comparison?

Anchor 4, Thought Leadership Category

• authority through original frameworks,
• named methodologies, and
• earned positions.

The anchor that requires the most accumulated proof, the business must have done the work at depth before it can credibly name and define the approach.

The planning question: has the business earned the right to hold this position through demonstrated results, or is this an assertion without a foundation?

Anchor 5, Local and Community Authority Trust

Local and Community Authority Trust is built through geographic specificity, Proof that the business understands its local market from direct, documented experience.

• Named outcomes in specific locations,
• Community involvement that’s real and verifiable.

Anchor 5 carries a specific risk the others don’t. Location words are the easiest misuse. “regional Victorian business” costs nothing to write.

Anchor 5 is not created by mentioning locations. It is created by the proof assets behind those locations.

• Named clients,
• Specific local projects,
• Community involvement,
• Local Industry engagement
• Documented outcomes that verify local experience

The planning question here is stricter than the others: is the local specificity verifiable?

Geographic reference without a verifiable proof artefact underneath it isn’t local authority, it’s local keyword insertion. AI systems are increasingly good at telling the difference.

Anchor 6, Results-in-Advance

Friction reduction at the entry point of a service pathway.

• a working tool, a downloadable resource,
• a free audit,
• a diagnostic assessment.

A tangible deliverable that gives the audience an experience of the business’s value before any commitment is made.

The planning question: does the tool or resource actually exist, and does it genuinely deliver value rather than acting as a lead capture mechanism dressed as a resource?

Anchors 7 and 8: Underpinning Infrastructure

Anchors 7 and 8 operate differently from the six above.

They don’t surface through page content. They’re infrastructure-level checks, questions about whether the strategic and technical execution of the page and site is supporting the proof layer rather than undermining it.

Anchor 7, Core Service Areas

This anchor asks: the commercial pathway was assigned as a metadata field, but did the content, its structure, and its conversion elements actually handle it?

Did the page earn the commercial outcome it’s pointing toward, or does the CTA exist disconnected from the authority and proof built in the content above it?

Anchor 8, Technical Excellence

asks: Is the technical execution of the page and site delivering the standard the content deserves?

Its, not just “did we add alt text and schema”, but did we do it well, did it meet our strategy guidelines?
Image compression, Core Web Vitals, schema quality, accessibility.

The difference between ticking compliance boxes and genuinely executing the technical layer compliant with your own business content strategy – that makes the proof and content work as intended.

→ Anchors 7 and 8 are documented in detail on a separate page: Underpinning Anchors, Infrastructure, Conversion, and Technical Execution (in development)

The Atomic Proof Library

The Atomic Library is the structural model for managing proof assets as a relational catalogue, the database-backed layer that makes the anchor framework operational at scale.

The core thesis: proof assets aren’t static display items.

A client case study isn’t just a page on the website. It’s a structured record containing multiple distinct claims:

• a measurable outcome,
• a process observation,
• a geographic proof point,
• a tool or
• methodology reference.

Each claim can satisfy different anchors depending on how and where it’s expressed.

This needs an N:M relational model.

• One proof asset maps to multiple claims.
• One claim can be satisfied by multiple proof assets.

A single outcome, “80% AI voice share in 28 days, $500K to $1M revenue” documented in real time, can simultaneously back

• a Trust and Proof anchor (the specific result),
• a Thought Leadership anchor (the AI citation methodology that produced it), and a
• Local and Community anchor (the regional Victorian business context).

The same asset, expressed differently, satisfies different anchors in different pieces of content.

The Atomic Proof Node is the structural unit: a single, specific, verifiable claim expressed as a structured record.

The artefact is stored as a structured reference, a URL with a type attribute, perhaps a canonical source too – something that an agent can parse, validate, and convert to schema or use in strategy and operational workflows automatically.

This is dual-purpose infrastructure: AI visibility through machine-readable proof assets, and agentic workflows that can query, validate, and act on those assets autonomously.

What’s Currently Built

Reviews CPT (bw_reviews)

Structured customer review data with CSV import supported.

• rating,
• date,
• platform,
• verification URL,
• success outcome,
• customer detail, and
• featured flag
• project – as a relational link to a project CPT

Reviews can link to a canonical project record. This surfaced the project’s featured image in the review card. It can carry a direct link to the source Google review for external verification.

Short codes and Breakdance custom elements render both individual review cards and aggregated review displays, with review and aggregate review data feeding into the single page schema graph.

Not yet connected to a claims taxonomy; queryable as a source of truth.

Customer Success Stories CPT (projects),

Public post type with archive, supports full editor content. The primary vehicle for case study and portfolio pages.

Proof is captured but structured at page level, not at claim level.

ACF Field groups can (and should) be added to capture key data like location, customer name, success outcome etc.

EEAT Proof Report prototype

Working prototype. A live HTML report frontend that extracts proof claims from site content, identifies whether each claim demonstrates Experience or Expertise, maps associated service connections, and surfaces structural data gaps.

• This is not a page-level EEAT score: it’s a proof asset audit.
• Working prototype.
• Not yet integrated into the editorial workflow as a live operational tool.

Authority Anchor selection

A sub-framework and mental model used at content research and brief stage.

The anchors are a structured set of questions that force the writer to verify whether genuine proof assets exist before content is planned.

Currently a planning checkpoint, not a queryable analytical dimension or checklist to complete . The value is in the discipline the questions create, not in the record of which boxes were ticked.

NULL fields at scale.

Audits consistently reveal that critical fields such as TLDR summaries, excerpts, SEO meta, and content architecture fields are frequently unpopulated across broader content inventories.

Valuable proof points can fail to surface in AI website inventory workflows, not because the proof does not exist within the content, but because it was never structured into machine-readable fields, or because the site’s architecture obscures it from retrieval.
Page builders that store content outside the standard content field, JSON structures that require separate parsing, and content distributed across ACF fields can all create silent gaps between what exists on a page and what an agent actually reads.

SCOS addresses this directly. A dedicated function aggregates page content regardless of whether it is stored in Breakdance data, ACF fields, or the standard editor, and writes it as markdown to a custom key. This provides agents with a single, reliable content source per page.

Early testing of agentic workflows on scaled content sites revealed a related constraint. Loops were often limited to the first 500 words of content for token efficiency during initial passes, causing the majority of proof assets located further down the page to be missed.

The Architectural Principle That Resolves Both Problems

AI should read the full content at least once during the initial pass, generate the TLDR, populate the core content architecture fields, and define the Search Intent Goal.

Once those fields are populated, subsequent AI passes can use them to determine how much content needs to be read. Decisions can be informed by word count, internal and external link counts, and other precomputed signals, ensuring agents are not performing redundant work.

Field Population Could Be More Token Efficient

Claude and WP-CLI can loop through a database using brand voice and strategy documents stored in /wp-content/ai-knowledge/, or a local agency level AI knowledge base, to backfill fields via WP commands.

The remaining constraint is performing this process efficiently at scale. This is currently being addressed through a Python implementation. The gap is narrowing.

The Unsolved Problems

The tracking problem is where this component is most incomplete, and where the problem is genuinely hard, not just unbuilt.

Scale, complexity and market competiton likely make the answer to these problems different.

Claim deployment tracking. Programmatically determining which specific claims from a proof library are actively deployed across page content is difficult.

Without a reliable tracking loop, it’s hard to optimise coverage or catch over-reliance on a single high-profile proof asset while other service pillars remain unverified.

Claim cannibalization. The same proof asset used too heavily across too many pieces of content produces a different problem than content cannibalization, not two pages competing for the same query, but an authority architecture that rests on too narrow a proof base.

Identifying this requires knowing not just what proof exists, but how it’s distributed across the content inventory.

The Airtable Proof Library – dead end.

Early architecture mapped claims to external Airtable structures for cross-referencing and AI lookup during content creation.

It produced data duplication, sync lag, and administrative overhead that proved unsustainable under real agency constraints.

The deeper problem was structural: any manually-maintained claims list, external database or brand voice document has the same failure mode.

New proof gets published to the site and never makes it back into the claims source. Content keeps drawing on the same verified handful while newer outcomes sit unconnected.

Coverage narrows over time, not because the proof doesn’t exist, but because the pipeline between publishing proof and registering claims was never closed.

The lesson: the claims taxonomy needs to live somewhere with a registration loop that closes at publish time. Wwhether that’s natively in WordPress, or at an agency or business level in an agentic system with a proof-inventory loop that updates periodically. The location is less important than the loop.

Where This Is Heading

The right implementation depends on scale and context. (single-site operator vs agency vs 10 or 100 page content inventories).

A claims taxonomy could live natively in WordPress or as local file storage that an agentic workflow reads and writes to at publish time. The location matters less than “the loop must close”.

Manually maintained proof libraries are near impossible to keep updated.

New proof gets published, and doesn’t make it back into the claim storage. Coverage on recent and new success narrows while the site keeps drawing on the same, likely outdated ones. I know this because the Air table architecture proved completely unsustainable under real constraints – even with a vested interest in maintaining it beyond just tracking proof!

The human workflow must be lightweight.

Write content, publish the proof. That’s the ceiling for human input.

• an outcome image,
• a completed project,
• a verifiable review URL.

Everything else, claim and artefact discovery, proof coverage and gap detection, has to be agentic to work at all.

The Proof Library Agent workflow

1. Query the content inventory,
2. find what proof exists,
3. match claims to assets,
4. assess coverage,
5. flag broken or missing verification artefacts,
6. surface gaps,
7. propose resolutions,
8. wait for approval,
9. execute.

The “approve and execute” pattern only becomes possible when the claims layer is queryable.