What_the_Audit_Agent_Actually_Reads

On every GEO audit run, the agent receives nine pieces of information. Not approximately nine. Exactly nine. Here they are.

The first input is the prompt version. When an audit request comes in, the system checks the database for the active prompt corresponding to the audit type-in this case, Advanced. It pulls the system prompt content and version number. The current version is v1.8. The prompt lives in api/constants/prompts/advanced.md and is cached in memory for five minutes; the database row is the source of truth. This is a structural lookup: audit type maps to prompt. No similarity retrieval. No rank-ordered results. One row, one version, deterministic.

Second: the active provider group. The system queries the database for the set of LLM providers configured for the Advanced audit type. At any given time, this could be four providers or one provider, depending on what the infrastructure team has configured as available and healthy. Every provider in the active group receives an identical system prompt and an identical user prompt, in parallel. No routing heuristic. No 'send to the best provider for this query type.' Every model gets the same call, and the results come back via Promise.allSettled-one provider failing does not abort the others. The provider group is also cached, refreshed alongside the prompt.

Third: the page content. This is fetched live. The audit worker submits a URL; the system makes an HTTP request to that URL, parses the HTML, converts it to Markdown, and truncates it at 30,000 characters. The Markdown is the primary input the LLM scores against the rubric. The fetch is deterministic-same URL fetched at the same moment produces the same content-but it is a live fetch, not a lookup. The page content is fresh for every run.

Fourth: technical signals extracted from the same fetch. The system parses the HTML for JSON-LD schema blocks, meta tags, canonical URLs, hreflang declarations, robots.txt directives, llms.txt presence, sitemap existence, heading structure, image alt coverage, internal link counts, word counts, and response headers. All of this is formatted into a structured prompt section that the LLM reads alongside the Markdown. It is rule-bound extraction-specific DOM selectors, specific header field names-with no interpretation. The signals are assembled before the LLM call fires.

Fifth: the scoring rubric itself. Eight weighted metrics are embedded directly in the prompt: Fact Density (20%), Entity Salience (15%), Extractability (20%), Source Citation Quality (10%), Schema Markup (10%), Direct Answer Formatting (10%), Multimedia Optimization (7.5%), Conversational Flow (7.5%). These weights are static. They live in the prompt file. When a new prompt version is activated in the database, the weights are updated for everyone-no gradual rollout, no A/B test. All audits created after the version change use the new rubric. All audits created before it use the prior version.

Sixth: the provider responses. Once the LLM calls have been made to all active providers, the results come back. Some might succeed. Some might time out. Some might return unparseable responses. The system filters for responses that meet a minimal shape-the required scoring fields are present, the JSON is valid-and collects the fulfilled results. These are the actual LLM inferences: the scores for each metric, the overall score, the reasoning.

Seventh: consensus synthesis. The system averages the per-metric scores across all fulfilled providers. If four providers returned scores, the overall score is the mean of those four overallScores. Per-metric scores are averaged the same way. This is arithmetic. No weighting by confidence. No prioritising one provider's answer over another. The first provider to return gets its narrative fields (executive summary, findings, recommendations) promoted to the final report. The consensus score replaces them at the top level.

Eighth: cache lookup result. Before the LLM calls fire, the system checks if this URL has been audited before. The cache key is constructed from three components: the SHA256 hash of the normalised URL, the SHA256 hash of the page Markdown, and the audit type. If a prior audit result exists for the same triple and was created within the last 60 minutes, that prior result is returned immediately. No LLM calls are made. No credits are deducted. The cache is only checked in the two-step streaming audit path (GET /audits/:id/stream); the synchronous POST path and the legacy direct stream run a full audit every time. This is exact-match lookup. Content-aware invalidation: if the page changes, the content hash changes, the cache key changes, and the lookup falls through. No explicit invalidation API needed.

Ninth: SEO appendix signals. After the LLM has returned, the system computes supplemental structured signals from the raw signals object already extracted during the page fetch. This covers indexability (robots directives, noindex tags), heading structure quality, internal link density, and image alt text coverage. These are rule-based computations against threshold comparisons. The appendix is attached to the report post-LLM and does not influence the LLM-generated scores; it contextualises them.

That is the complete bundle. Prompt version. Provider group. Page content. Technical signals. Scoring rubric. Provider responses. Consensus synthesis. Cache lookup. SEO appendix. Nine inputs. All enumerable. All reproducible.

Why_This_Is_Not_RAG

RAG-Retrieval Augmented Generation-is the architecture used by most search and content analysis tools built in the last two years. The idea is sound: you have a large knowledge base, potentially millions of documents or chunks. A user query comes in. You cannot enumerate in advance which chunks are relevant to that query. So you embed the query as a vector, compare it to pre-computed embeddings of all the chunks, rank them by cosine similarity, and inject the top-K results into the LLM context. The LLM works with the retrieved context.

RAG solves a real problem. It is the right answer when the knowledge base is large, the queries are unpredictable, and approximate retrieval is acceptable.

GEO audit work requires none of those conditions. Every run assesses a known URL against a fixed rubric. The inputs are enumerable before the first LLM call fires. The prompt is versioned. The rubric is static. The page content is fetched live and deterministically. The inputs are not selected by similarity-they are assembled by rule.

The distinction is not that RAG is a poor pattern. It is that RAG solves a different problem. Semantic similarity retrieval is designed for situations where you do not know in advance which chunks of a knowledge base are relevant to a query. GEOAudit knows.

This is what all inputs structural, no semantic layer means. Every piece of information the audit agent reads comes from one of three retrieval mechanisms: exact database lookups (prompt, provider group, cache hit), rule-bound fetches and parsing (page content, technical signals), or deterministic computation (consensus scoring, SEO appendix). No embeddings. No vector similarity. No retrieval layer producing different inputs on re-execution based on embedding drift or threshold tuning.

The competitorGap field in the final report is an example of what GEOAudit does instead of pre-loading competitor data. The prompt instructs the LLM to infer the page's competitive niche and identify one structural gap from its training knowledge. This is LLM-as-analyst, not LLM-as-retriever. The inference happens inside the LLM call, against the page content and the prompt guidance. No competitor set enters the bundle from outside. No competitor data is injected before the audit begins. The LLM does the competitive reasoning from first principles, over structural inputs.

What_It_Costs_to_Build_vs_Buy

Building a generic-RAG competitor audit tool requires the infrastructure that RAG requires: embedding models, vector databases, retrieval tuning, drift monitoring. You need to decide on embedding dimensions, similarity thresholds, k-value selection for the top-K retrieval. You need to monitor whether embedding drift is causing retrieval quality to degrade over time. You need to handle the case where the same query produces different retrieved context on different runs because the similarity thresholds have shifted slightly or the embedding model has been updated. Every one of these layers is a point of opacity.

The opacity is structural. When a user of your tool asks why a particular audit output was generated, you cannot tell them 'because we retrieved these five chunks from the knowledge base and the LLM scored the page against them.' You can tell them the LLM said X, but not what context it was working with, because the retrieval was probabilistic. Rerunning the same audit with the same page and the same prompt might produce different results because the retrieved chunks could be different. You would need to re-run the audit to enumerate what was retrieved.

Geoverity's architecture eliminates this problem. Every audit run assembles nine enumerable, deterministic inputs. If an audit output seems wrong, you can read the bundle it was scored against. You can check the prompt version that was active at the time. You can verify the page content as the system saw it-Markdown rendering can lose meaning; what did the audit agent actually read? You can understand which providers were called in parallel and what they each returned. You can verify the cache state, the consensus computation, the SEO appendix signals. You can replay the audit against the same bundle and confirm that the output is deterministic.

This is not a feature. It is a structural property. And it is why Geoverity is built the way it is-not why other tools are bad. The trade-off is real: you must accept that the bundle is scoped to what can be assessed from a single URL fetch. You cannot ask the agent 'what do my competitors think about this page?' without building additional infrastructure to track competitor activity over time. You cannot ask 'how has this page changed?' without building a history layer. Those are Phase 1 and Phase 2 work. The structural principle persists: every input will remain enumerable, auditable, and deterministic per run.

Phase_1_and_Beyond_-_What's_Coming

The current bundle is deliberately scoped. It answers the question 'is this page good for GEO, based on a single fetch and a fixed rubric?' To answer 'is this page better or worse than it was last month?' or 'how does this page compare to the top-ranking competitor?' requires additional inputs that do not yet enter the bundle.

Three inputs are planned for Phase 1 and beyond:

Prior-run history. The system will store prior audit results and compute diffs. A new run will read the prior result, calculate what changed (in the page, in the scores, in the recommendation signals), and append that history as an input to the LLM. This allows the agent to answer 'this improved by 12 points-here is what you changed.' Currently, the system has no history layer; every audit is an island.

Competitor set. The LLM can infer competitive context from its training knowledge and the page content. But the system can formalise that inference by tracking which domains are competing for the same keywords and feeding that structured context in. Currently, the competitorGap field is the LLM inferring competition from internal knowledge. Phase 1+ would add explicit competitor tracking.

Market context. Seasonality signals, category trends, algorithm updates-these are currently implicit in the prompt and in the LLM's training knowledge. They could be tracked as structured inputs that shift dynamically as market conditions change.

All three of these additions follow the same principle: enumerable, deterministic inputs. No semantic retrieval layer. The bundle grows; the auditability property holds.

The_Auditability_Move

Here is the specific capability that matters most for someone running audit infrastructure at scale: every audit result includes the nine inputs it was scored against.

When an audit completes, you can read the memory bundle that was assembled. You can check the prompt version that was active on that date. You can see the page content as Markdown-not the rendered version, not the page as it appears in a browser with JavaScript execution, but what the audit agent actually read. You can verify which providers were called in parallel and what each returned. You can see the cache state: whether this was a cache hit or a full LLM run. You can trace the consensus computation and the SEO appendix scores.

If something looks wrong in an audit result, you can reproduce it. You can re-run the same URL against the same inputs and confirm that the output is deterministic. You can change one variable-the prompt version, the provider group, the cache state-and see how that variable affects the score. You can audit the audit.

This is infrastructure that lets you trust the tool. Not because of who built it. Because the tool is structurally transparent. The inputs are enumerable. The computation is auditable. The LLM is reasoning over deterministic structure, not over a retrieval layer that might behave differently on the next run. That structural property persists as the product evolves. Future versions will add cross-run history and competitive context; the auditability principle remains.