Skip to content

Anatomy of a Pass

The Agent Readiness Operator runs a single pipeline:

web page → audit → decide → fix / ship / escalate

You hand it a single thing — a URL, or pasted page source. That is the whole interface.

The One Rule

Every pass ends with a binding decision, never a question.

The user sends a URL or pastes page source. That is the entire interface. From that single input I run the operator end to end — audit, decide, fix, escalate, manifest — and return a complete result. The user never picks a specialist, never orders the fix queue, never approves each dimension. I make every routing call.

The audit-tool-gap guard runs first

Most fetch tools convert HTML to markdown before I see it, and that conversion strips <script type="application/ld+json"> — exactly where JSON-LD schema lives. So a markdown-converted fetch makes a page rich in schema look schema-free. That is a false negative, not a finding.

Before scoring Structured Data, I check:

  1. /llms.txt and /llms-full.txt — agent-native endpoints that survive markdown conversion and often reveal the entity data directly.
  2. The raw page source, not the markdown render — look for the literal application/ld+json script blocks.

If I cannot get raw source (markdown-only fetch, JS-rendered SPA), a low Structured Data read is unverifiable, not a confirmed gap → verify against raw source, or ESCALATE the verification.

Five specialist packets

When I apply a dimension-specialist I hand it a tight packet — its own slice, the source-availability flag (so it knows whether a low read is a finding or a false negative), and the goal:

PACKET → [N-dimension-name]
- URL:        <page url, or "pasted source" if no URL>
- Raw source: yes | no | stripped   (per §1 — "stripped" = markdown-only fetch, JSON-LD not visible)
- Signals:    <the observed signals relevant to THIS dimension only>
- Goal:       score this dimension /20 and return its SHIP/FIX/ESCALATE route + draft fix if FIX

The specialist does not need the other four dimensions' signals; it scores its own dimension and returns its route. I assemble the five results into one verdict.

Adversarial challenge gate

After all five specialists return their findings — and before a single line of output is emitted — the adversarial specialist challenges every finding. This is not a manual review step; it runs automatically on every pass, including all-SHIP passes.

The adversarial specialist receives each dimension's evidence packet and finding in isolation (no cross-dimension contamination), then checks four things per dimension: does the score fit the rubric band the evidence supports; does the route match the canonical decision table; do the artifact facts trace to the packet; and does each artifact pass the fix-acceptance rubric. It then runs one cross-dimension consistency check against the full assembled verdict.

It issues a binding CLEAR or CHALLENGE per dimension. Every CHALLENGE must be resolved — re-scored, re-routed, or corrected — before the pass proceeds. The adversarial specialist does not re-run after resolution.

This is the drift guard. It re-reads each rubric band and decision route with fresh context, independent of the scoring pass that preceded it. Score inflation, invented URLs in sameAs arrays, and decision-table bypasses are caught here before they reach output.

Full adversarial gate reference →

Two modes

AUDIT — automatic on any URL or pasted source

One pass produces, in order: a Signal Map (one paragraph per dimension) → a score table (five rows + total) → a band → a per-dimension decisionAND the drafted fixes for every FIX-tagged dimension, in the same pass. AUDIT does not stop at "you should fix X." It produces the fix.

FIX — generate and ship the artifacts

  • Drafting to a separate output needs no gate. Writing fixes to chat, or to proposed-fixes/ in Claude Code, is non-destructive — I just do it.
  • The only confirmation step is applying in-place over existing files in Claude Code (overwriting the live robots.txt, an existing page's <head>). That single gate is a safety checkpoint before an irreversible write: I copy each target to proposed-fixes/backup/ and emit the applied-changes manifest before any in-place write.

The fix queue is structural-first

Structured Data and Crawl Signal before Citability, Freshness, Entity Authority.

Content work built on a broken foundation compounds the problem. The priority routing rules govern the order:

  1. Rule 1 — Structured Data < 10 AND no /llms.txt → generate agent-native endpoints first.
  2. Rule 2 — Crawl Signal < 10 → correct robots.txt before anything else.

A locked robots.txt makes every other fix invisible to agents — so crawl is the harder block and runs first.