How the AIO Audit Works

A complete technical walkthrough of the 5-stage pipeline that runs between URL submission and finished report.

When you submit a URL, ResourceAI does not ask an LLM “what do you think of this brand?” That answer is noise. Instead, we run a deterministic pipeline that measures the signals AI systems actually use when deciding which brands to cite, recommend, and surface.

The pipeline has five stages. Each stage feeds the next. The full run takes approximately 3 minutes in development and 8 minutes in production with all capabilities enabled. Cost per audit is roughly $0.003 in dev and $0.01 in production.

URL submitted
    |
    v
 ┌──────────────────┐
 │  STAGE 1: CRAWL  │  Playwright + Cheerio + HTTP checks
 └────────┬─────────┘
          v
 ┌──────────────────────┐
 │  STAGE 1.5: CLASSIFY │  Gemini Flash → brand, category, competitors
 └────────┬─────────────┘
          v
 ┌─────────────────────┐
 │  STAGE 2: MEASURE   │  17 modules in parallel → 15 capability scores
 └────────┬────────────┘
          v
 ┌──────────────────┐
 │  STAGE 3: JUDGE  │  10-step LLM pipeline → E-E-A-T, AIO sim, synthesis
 └────────┬─────────┘
          v
 ┌───────────────────────┐
 │  STAGE 4: SCORE/STORE │  Weighted average → grade → persist → cache
 └───────────────────────┘

Stage 1: Crawl

The pipeline starts with Playwright loading your site in a real Chromium browser. This matters because many sites render content client-side; scraping raw HTML would miss it. Playwright captures both desktop and mobile screenshots, which are stored alongside the audit record and exposed in the Receipts tab.

Cheerio then parses the rendered HTML and extracts every structured signal: title tag, meta description, all heading levels (H1 through H6), internal and external links, image alt text, JSON-LD blocks, canonical URL, Open Graph tags, and raw word count. These signals feed both the traditional SEO dimensions and several mechanism capabilities.

In parallel, a set of HTTP-level checks runs: HTTPS enforcement, robots.txt availability, sitemap.xml presence, AI bot access headers (whether the site blocks GPTBot, Google-Extended, or other AI crawlers), and Time to First Byte (TTFB). The crawler can process up to 1,000 pages per audit.

Stage 1.5: Classify

Before any measurement begins, a single Gemini Flash call classifies the site. The classifier returns: brand name, industry category, top 3 competitors, target audience, site type (SaaS, e-commerce, media, agency, etc.), page intent, and awareness level.

This classification populates the context object (ctx.detected) that every downstream module reads. Without it, capabilities like tokenizer tax or competitive decomposition would have to guess the brand name from the URL, which is unreliable. The classification result is cached on the context; there is no duplicate call. It also persists to the audits row as classifier_key, brand_name, and competitor_urls.

Stage 2: Measure

Seventeen measurement modules run simultaneously via Promise.allSettled. Each module returns a dimension score from 0 to 100. If a module fails (network timeout, API error), it degrades gracefully to a score of 50 rather than crashing the pipeline. This is where the hard signals live.

Two of the seventeen modules cover traditional SEO (technical and on-page). The other fifteen are the mechanism capabilities: tokenizer tax, entity resolution, retrieval pool similarity, token logprobs with bootstrap confidence intervals, PMI co-occurrence, seven-source layer analysis, aggregator presence, chunk gaps, hallucination tracking, loop thresholds, counterfactual prediction, query intent classification, perception analysis, competitive decomposition, and AI Overview comparison. Each capability has an independent flag in the database, so they can be enabled or disabled without affecting the rest of the pipeline.

The total signal count across all modules is 182 per page. Every signal is deterministic and reproducible; the same input will produce the same measurement. The only source of variance is LLM-derived signals, which use temperature 0 and fixed seeds where the API supports it.

Stage 3: Judge

The judge pipeline runs a sequence of 10 LLM calls that build on each other. It produces the qualitative analysis layer of the report: the E-E-A-T assessment, the content depth evaluation, the conversion walkthrough, and the AIO simulation.

The judge pipeline uses DeepSeek Chat as the primary model for Steps 2 through 9. DeepSeek is cost-effective and produces reliable structured JSON output at temperature 0. Gemini Flash handles Step 1 (classification). The premium tier adds a multi-model consensus step using Claude and GPT alongside DeepSeek.

Stage 3.5: Post-processors

After the judge pipeline completes, eight post-processors run. These modules handle tasks that depend on outputs from earlier stages: schema audit (reads crawl JSON-LD data), aggregator presence (runs DuckDuckGo searches), citation extraction (parses raw provider responses), hallucination logging (reads fact-archaeology output), loop threshold velocity (compares to prior audits), query intent classification, perception analysis, and counterfactual prediction (calls the LightGBM sidecar).

The competitive decomposition post-processor also runs here. It takes the scores from all 15 capabilities and breaks the difference between your brand and each competitor into a 6-component waterfall, showing exactly which capabilities drive the gap.

Stage 4: Score and Store

The scoring engine computes a weighted average across all dimensions. Weights sum to 1.0: traditional SEO accounts for 0.14, the judge pipeline for 0.20, and the 15 mechanism capabilities for 0.66. The result is an overall score (0 to 100) and a letter grade (A+ through F).

Issues are extracted from every module that flagged problems. Each issue is written to the audit_issues table with a severity level (critical, warning, info), a category, and a recommended fix. The judge output (E-E-A-T analysis, AIO simulation, synthesis) persists as structured JSONB in the audits row.

A cache entry is written with a 48-hour TTL. If the same URL is audited again within that window, the cached result is returned immediately. The full audit is reconstructable from the database. Every prompt sent to every model, every response received, every calculation, and every raw signal is stored and exposed through the Receipts tab.

Data Source Waterfall (v6.2)

Several capabilities depend on external data sources: entity resolution needs knowledge graph APIs, aggregator presence needs search engines, chunk gaps needs competitor page content, and the retrieval pool can optionally pull from Reddit and Hacker News.

The data source waterfall (introduced in v6.2) provides ordered stacks of sources for each data need. The dispatcher tries sources in order, free to paid, with five gates per attempt: environment key present, paid tier allowed, daily budget remaining, per-request budget remaining, and per-source quota plus circuit breaker. Every attempt (success or skip) writes a row to audit_source_calls so the fallback chain is fully traceable. When the waterfall is disabled, every consumer falls back to pre-v6.2 single-source logic with no breakage risk.