What does VEM stand for?

VEM stands for Vector Entity Modelling. In ThatWare's documented framework, VEM assesses the entity foundation behind AI visibility. It looks at six broad areas: brand clarity, content coverage, authority, entity relationships, AI readiness and query coverage.

What is the difference between AVM and VEM?

The easiest way to understand the difference is to separate outcome from foundation. AVM measures the observed AI visibility outcome. It looks at whether the brand appears in relevant answers, whether it receives citations, whether those citations are authoritative, whether the brand is represented consistently and whether it appears in strong or weak positions. VEM examines the entity foundation that can influence that outcome. It looks at whether the brand is clearly defined, whether important topics are covered, whether authoritative evidence exists, whether entity relationships are coherent, whether the site is machine-readable and whether the content covers the right query intents.

Is AVM an official score from ChatGPT, Claude, Perplexity or another AI platform?

No. AVM is a proprietary diagnostic methodology developed by ThatWare. It should not be presented as an official score issued or endorsed by OpenAI, Anthropic, xAI, Perplexity, Google or any other provider. This distinction is important because AI providers do not currently publish a universal standardized brand visibility score that applies across all models and interfaces. Different systems use different retrieval methods, models, tools and source environments. ThatWare's AVM framework creates a consistent way to sample provider behavior, normalize evidence and compare visibility over time. Its usefulness comes from repeatability and structured analysis, not from claiming universal authority.

How is an AVM score calculated?

The documented AVM methodology uses five core dimensions: Presence, Citation, Authority, Consistency and Position. These dimensions are combined through a deterministic scoring layer, followed by ordered adjustments that account for factors such as discovery across query types, strong authority and citation combinations, position distribution, low presence and repeated not-found outcomes.

Why is confidence separate from the five AVM dimensions?

Visibility quality and evidence sufficiency are not the same thing. Imagine that a brand appears strongly in three sampled queries. The visibility looks impressive, but the sample is too small to support broad conclusions. Now imagine another brand with moderate performance across a much wider set of queries. The second result may be more useful for strategic planning because it is supported by more evidence.

Does VEM use a vector database or embeddings?

The documented September 2026 implementation does not contain a vector database, embedding-generation API or numerical embedding-similarity pipeline as part of the VEM scoring architecture. Instead, it uses structured contextual inputs, provider-generated analysis and deterministic score aggregation. That means VEM should be described as a Vector Entity Modelling framework, not as a claim that the current system is performing database-level vector search.

What is AI citation probability?

AI citation probability is a strategic indicator that estimates how well a brand or source appears positioned to be cited within an AI answer environment. It should not be treated as a guaranteed probability or a promise that a provider will cite the brand a specific percentage of the time. The most useful way to improve citation potential is to strengthen the evidence ecosystem. Publish original research, create clear factual resources, earn relevant third-party coverage, make claims verifiable, maintain strong technical accessibility and establish topical authority.

What is the difference between AI visibility and traditional SEO visibility?

Traditional SEO visibility is usually associated with rankings, impressions, clicks and traffic from search engine results. AI visibility is associated with whether a brand is mentioned, cited, compared or recommended inside generated answers. The two can overlap, but they are not identical.

How does GEO relate to AVM and VEM?

GEO, or generative engine optimization, focuses on improving how information is discovered and represented inside generative answer systems. AVM can be used as a measurement layer for GEO because it evaluates observed visibility across sampled AI queries. VEM can be used as a readiness layer because it evaluates the entity, authority, content and machine-readable foundations that can influence generative visibility.

What is an AI visibility audit?

An AI visibility audit is a structured assessment of how a brand appears across selected AI search or answer environments. A comprehensive audit can include: · Query-set design. · Provider-specific testing. · AVM scoring. · Presence, citation, authority, consistency and position analysis. · Commercial and transactional visibility. · Competitor benchmarking. · Citation-source analysis. · VEM entity-readiness analysis. · Knowledge graph and brand-consistency review. · AI search readiness review. · Priority roadmap. The quality of the audit depends heavily on the query set. A useful audit should include the questions prospects actually ask, not only branded prompts designed to make the company look visible.

What should be included in an AVM and VEM audit?

A strong AVM and VEM audit should begin with scope. Define the brand, competitors, markets, languages, AI providers and query categories. The AVM portion should include the five visibility dimensions, query evidence, confidence or coverage context and competitor comparisons. Advanced AVM can add strategic interpretation around discoverability, trust, dominance and share of voice.

How can a business improve ChatGPT visibility?

There is no single switch for ChatGPT visibility, and the exact consumer experience can vary by model, interface, retrieval mode and user context. However, businesses can improve the underlying evidence that makes accurate AI representation more likely. Focus on: · Clear entity definitions. · Comprehensive service and product pages. · Consistent organization and leadership information. · Strong schema aligned with visible content. · Relevant third-party citations. · Original research and expert content. · Commercial comparison assets. · High-quality FAQs. · Crawlable technical documentation. · Digital PR and authoritative mentions. · Stable factual pages. Then measure a repeatable set of prompts instead of relying on isolated manual checks.

How can a business improve commercial AI visibility?

Commercial AI visibility improves when a brand gives both users and machines enough evidence to include it in a buying conversation. Create pages that answer questions such as: · Who is this service for? · What problems does it solve? · How is it different? · What is included? · What proof supports the claims? · How does it compare with alternatives? · What industries or company sizes are a good fit? · What does the engagement process look like? Support those pages with case studies, expert credentials, third-party validation and relevant authority signals.

How can a business improve transactional AI visibility?

Transactional visibility depends on making the path to action explicit. If a company offers an AI visibility assessment, the website should clearly explain how to request it, what the deliverable includes, who performs the analysis, what information is required and what happens after the audit. Useful transactional assets can include: · Request-audit pages. · Consultation pages. · Service scope pages. · Pricing guidance or scope factors. · Deliverable examples. · Process FAQs. · Contact and booking information. Transactional queries should use natural action language such as "get," "request," "book," "hire" or "schedule" where that reflects genuine user intent.

How often should a company run an AI visibility assessment?

There is no universal schedule, but monthly or quarterly formal assessments are practical for most active programs. Fast-moving sectors such as AI software, media and digital marketing may benefit from monthly tracking. More stable B2B categories may use quarterly assessments. Additional checks are useful after major launches, migrations, rebrands, PR campaigns or large content updates. The key is to preserve a stable core query set so that trend comparisons remain meaningful. If the entire query portfolio changes every month, score movement becomes difficult to interpret.

How can a company request an AVM and VEM audit?

A business considering an AVM and VEM audit should begin by defining the market it wants to measure. That usually includes the core brand, primary competitors, target countries or regions, priority services, important buyer intents and the AI providers most relevant to the audience. The audit process can then build a representative query portfolio, collect provider-specific evidence, calculate the AI visibility breakdown, assess the entity foundation and produce a prioritized roadmap.

SUPERCHARGE YOUR ONLINE VISIBILITY! CONTACT US AND LET’S ACHIEVE EXCELLENCE TOGETHER!

Intro

Search visibility is no longer confined to a list of ten blue links. A potential customer can now ask an AI system which provider to choose, request a shortlist of software platforms, compare agencies, find a specialist in a specific city, evaluate two competing products, or ask for the best solution for a complex business problem. The answer can be assembled from multiple sources, compressed into a few paragraphs, and delivered without the user ever visiting a traditional search results page.

That change creates a measurement problem. Conventional SEO metrics still matter, but they do not answer a new set of questions that every brand now has to confront. Is the brand actually mentioned when an AI system answers category-level questions? Is it cited in a meaningful way, or merely named in passing? Is the brand associated with the right topics, products, founders, markets and use cases? Does the answer place the company near the top of a recommendation set or at the bottom of a long list? Are the brand’s claims supported by authoritative sources? Does the entity remain consistent across AI systems and across different query types? Can machine systems understand the relationship between the company, its services, its people, its products and the problems it solves?

Decoding AI Visibility: The AVM (AI Visibility Metric) and VEM (Vector Entity Modelling) Framework

ThatWare’s AVM and VEM framework was developed to create a structured way to think about those questions.

AVM stands for AI Visibility Metric. It is a project-defined diagnostic framework that turns sampled AI query evidence into a visibility assessment. The methodology evaluates five core dimensions: presence, citation, authority, consistency and position. It then interprets the evidence through a broader context that includes query type, discovery strength, competitive performance and confidence in the available sample. AVM is not an official score from OpenAI, Anthropic, xAI, Perplexity or any other provider. It is a proprietary analytical method for understanding how a brand appears within sampled AI-generated or AI-assisted discovery environments.

VEM stands for Vector Entity Modelling. It evaluates the entity foundation that sits beneath AI visibility. Where AVM asks, “How visible is the brand in the sampled AI answer environment?” VEM asks, “How clearly, consistently and machine-readably is the brand represented as an entity?” The VEM model examines brand clarity, content coverage, authority, entity relationships, AI readiness and query coverage. It is designed to reveal whether a brand has the structural signals that make accurate retrieval, association, citation and recommendation easier for AI systems.

The two models are deliberately complementary. A company can have strong conventional organic rankings but weak AI visibility. It can also have reasonable AI mentions while suffering from a fragmented entity foundation that makes those mentions unstable. AVM measures the observable visibility outcome. VEM examines the underlying entity readiness that can influence whether that visibility becomes consistent, defensible and scalable.

The framework also includes Advanced AVM, which interprets base visibility evidence through strategic signals such as discoverability, trust, entity dominance, answer probability, volatility, memory, sentiment, market-share visibility and share of voice. Advanced VEM expands entity analysis into ten strategic areas, including entity ecosystem quality, knowledge graph strength, AI search readiness, brand-entity consistency, competitive entity gaps, query-intent coverage, semantic content strength, AI citation probability, GEO readiness and a strategic roadmap.

A further layer, Blended AI, recognizes that no single AI provider should automatically be treated as the complete market. In the documented September 2026 implementation, ThatWare’s full AVM and VEM pipeline covered OpenAI, xAI, Claude and Perplexity, while a SERP integration supported base AVM only. The Blended layer combines eligible saved results from multiple providers to produce a broader diagnostic view rather than pretending that one model’s output is a universal truth.

This guide explains the conceptual architecture in practical, public-facing terms. It focuses on what businesses, marketers, SEOs, analysts and decision-makers can learn from the methodology, how AVM and VEM differ from traditional rank tracking, how to interpret the signals responsibly, and how to translate the findings into a modern AI search optimization program.

Project Overview

AVM is the application’s calculated visibility score. It reduces a provider’s structured query evidence into presence, citations, authority, consistency and position, applies additional boosts/caps, and optionally blends in CSV link support. It is a project-defined diagnostic measure, not a provider-issued ranking certificate.

VEM evaluates the entity foundation around the same brand: brand clarity, content, authority, entity relationships, AI readiness and query coverage. Despite the word “Vector,” the inspected implementation does not contain a vector database, embedding-generation API or numerical embedding-similarity pipeline. It uses prompt context, structured AI outputs and deterministic score aggregation. Management should describe that implementation accurately rather than imply an unimplemented embedding architecture.

The intended workflow suits analysts, agencies and businesses assessing their own brand against competitors. The private frontend currently grants access through a shared access mechanism, not individual customer accounts. The administrator has a separate login and can manage providers and inspect usage analytics.

At the homepage, a customer supplies brand_name, topic, industry, country, language, a competitor list and optionally a CSV import. The first submission calls OpenAI specifically. Provider switching occurs on results.php; it is not a provider choice passed by the initial homepage form. The VEM form adds aliases, founders, products, a website URL, asset URLs, authority/entity references, AI-readiness files and query sets.

The operational sequence is user-directed, not an automatic background conveyor belt. Generating AVM does not necessarily generate every advanced module. Separate buttons/requests generate later modules; their prerequisites and cache validity are checked differently across providers. Reports are created from existing results and rendered HTML, not by asking an AI provider to generate a PDF.

Business Purpose and Interpretation

The business value is a repeatable workflow for comparing a brand with named competitors, identifying weak evidence or entity signals, and producing an actionable, shareable assessment. Advanced modules add executive interpretation, competitive gaps and roadmaps. CSV input provides an additional link-evidence channel rather than replacing AI analysis.

There are three important interpretation boundaries. First, a model-produced score such as answer_probability_score is not a calibrated probability measured across all real consumer answers. Second, a provider’s API/search behavior is not identical to that provider’s consumer user interface. Third, blending results improves coverage of the sampled sources but does not convert them into a universal market benchmark. The saved prompts, query records, model identifiers and algorithm version should accompany comparisons across time.

The system stores assessment inputs and outputs but has no discovered customer identity, account ownership or payment entitlement layer. Therefore it is closer to a private assessment platform with an administration console than an already-complete multi-tenant subscription SaaS. This distinction affects how management should scope commercial launch work.

The Search Visibility Problem Has Changed

For years, search performance could be discussed with a familiar vocabulary. Rankings, impressions, clicks, sessions, conversions, backlinks and share of search formed a practical operating system for organic growth. Those metrics remain valuable, but the discovery journey is becoming more fragmented.

A buyer may still search Google, open a result and visit a site. The same buyer may also ask an AI assistant to explain the category, compare vendors, summarize reviews, identify alternatives or create a shortlist. In that environment, the brand does not control the answer page. The AI system can summarize information from third-party sources, infer relationships from structured data, cite a publisher, mention a competitor, omit the brand entirely, or present a recommendation without providing the same kind of ranking position that SEO teams are accustomed to monitoring.

This creates four practical changes.

First, visibility becomes answer-based rather than page-based. A website can rank for a query while the brand remains absent from an AI-generated answer. Conversely, a brand can be cited or recommended because of third-party authority even when its own page is not the highest-ranking traditional result.

Second, entity clarity becomes more important. AI systems need to resolve who or what a brand is, what it does, where it operates, how it relates to its founders and products, which topics it is authoritative on, and whether multiple references describe the same entity consistently. Ambiguity creates friction.

Third, citation quality matters alongside mention frequency. A passing mention is not the same as a detailed explanation. A citation from a weak context is not the same as an authoritative source reinforcing the brand’s expertise. A recommendation that places the company first is not equivalent to a list where it appears last.

Fourth, search intent expands beyond informational questions. Commercial and transactional queries become especially important because they reveal whether an AI system is willing to move from explanation to recommendation. “What is generative engine optimization?” is valuable, but “Which AI search optimization agency should an enterprise shortlist?” is closer to business value. A robust measurement system needs to understand both.

Traditional SEO tools were not designed to answer all of these questions. They can report ranking positions, links, crawlability and traffic. They may increasingly add AI features, but the conceptual gap remains. The question is no longer simply, “Where does this URL rank?” The new question is, “How does this brand exist inside the answer environment, and what underlying entity signals make that presence stronger or weaker?”

AVM and VEM were designed around that gap.

What Is AVM (AI Visibility Metric)?

AVM, or AI Visibility Metric, is ThatWare’s project-defined method for turning sampled AI visibility evidence into a structured diagnostic score and strategic interpretation.

At its core, AVM evaluates whether a brand is present in relevant AI answers and, if present, how strong that visibility appears. The framework is built around five dimensions:

1. Presence: whether the brand appears across the sampled query set.

2. Citation: the degree to which the brand is supported or referenced through citation-like evidence.

3. Authority: the strength of the sources and authority signals associated with the brand’s appearance.

4. Consistency: how reliably the brand is represented across different queries and contexts.

5. Position: where the brand tends to appear within recommendation or mention structures.

These dimensions are combined through a deterministic scoring layer. The implementation also applies rule-based adjustments so that the final score reflects more than a simple average. For example, broad discovery across generic, commercial and informational queries can strengthen the interpretation of visibility, while low presence, repeated weak positioning or large numbers of not-found outcomes can suppress it. The purpose is to distinguish between a brand that appears consistently in meaningful discovery contexts and one that receives a few isolated branded mentions.

A separate confidence measure evaluates the completeness and strength of the available evidence. This distinction matters. Confidence is not another visibility dimension and it is not a statistical confidence interval. It is a code-defined coverage signal intended to tell analysts how much weight to place on the observed result.

AVM is best understood as a diagnostic lens rather than an absolute market score. It is influenced by the selected providers, query set, market, language, competitors, model behavior, source environment and the timing of the assessment. A score is therefore most useful when it is compared against a consistent baseline, repeated over time, or used alongside direct competitive evidence.

That makes AVM particularly useful for four business questions:

· Are we visible when prospects ask AI systems about our category?

· Are we visible for non-branded discovery queries, not just searches that already contain our name?

· How does our visibility compare with named competitors across the same query set?

· Which dimensions are suppressing our AI search presence, and what should we improve first?

AVM does not replace SEO. It extends measurement into an environment where answer generation, citations, entity interpretation and multi-source synthesis play a larger role.

Why AVM Is Not Traditional Rank Tracking

It is tempting to treat AI visibility as another ranking problem. That approach is too narrow.

Traditional rank tracking assumes a relatively stable ordered results page. A keyword is associated with a position, usually one through one hundred, and the objective is to move the target page upward. AI answers behave differently. They can mention several brands in prose, rank them implicitly, cite external sources, provide no explicit order, reformulate the user’s question, or return different results based on the provider’s retrieval and synthesis process.

AVM therefore measures brand-level answer visibility, not just URL-level SERP position.

Consider three simplified scenarios.

In the first scenario, Brand A ranks third organically for “enterprise AI SEO agency,” but an AI assistant recommends Brand B and Brand C without mentioning Brand A. Traditional SEO sees a strong ranking. AVM sees a visibility gap in the answer layer.

In the second scenario, Brand A is mentioned in six of ten sampled AI queries, but it appears near the bottom of every list and receives weak supporting citations. The raw presence rate looks encouraging, yet the quality of visibility is limited. AVM is designed to capture that difference through position, citation and authority signals.

In the third scenario, Brand A appears for branded queries but disappears for generic discovery questions such as “best AI search optimization agencies” or “how to choose an LLM visibility partner.” A simple mention count can look acceptable because branded queries are easy. AVM’s attention to query taxonomy makes it possible to distinguish branded confirmation from broader market discovery.

This is why AVM should not be reduced to a single dashboard number. The score is a summary, but the real value lies in the breakdown. Presence tells one story. Citation tells another. Authority adds a trust dimension. Consistency reveals stability. Position adds competitive context. Query type reveals whether the brand is being discovered or merely confirmed.

For serious decision-making, the score should always be accompanied by the evidence underneath it.

How the AVM Methodology Works

The AVM workflow can be understood as a sequence of evidence collection, normalization, scoring and interpretation.

Step 1: Define the Assessment Context

Every meaningful AI visibility assessment needs a scope. That scope typically includes the brand, topic or market, industry, country, language and a set of named competitors. The documented application also supports optional CSV-based link evidence that can provide an additional supporting channel.

The most important input is not the brand name. It is the query set.

A weak query set can produce a misleading visibility picture. If every question contains the brand name, the assessment mostly measures recognition, not discovery. A stronger query portfolio mixes multiple intent classes, including branded, informational, commercial, comparative and transactional prompts.

For example, an AI search optimization agency might test queries such as:

· What is AI search optimization?

· How do brands improve visibility in ChatGPT?

· Best AI search optimization agencies for enterprise companies

· AI SEO agency vs traditional SEO agency

· Which company offers AVM and VEM audits?

· AI visibility audit service for global brands

· Request an LLM visibility assessment

Together, these questions reveal more than a single keyword ever could.

Step 2: Collect Provider-Specific Evidence

The documented implementation maintains provider identity rather than pretending all AI systems behave the same way. In the September 2026 source snapshot, full AVM support existed across OpenAI, xAI, Claude and Perplexity. A SERP integration existed for base AVM only and was disabled in the supplied database snapshot.

The exact retrieval and response process differs by provider. That difference is important because each provider can have its own search, synthesis, schema, citation and validation behavior. The methodology therefore treats provider-specific outputs as evidence that must be normalized before comparison.

Step 3: Normalize Brand and Competitor Signals

Raw AI responses are not useful enough on their own. The system needs to identify which entity is being referenced, whether the mention is valid, where it appears, what supporting source evidence exists, and how the query should be classified.

Normalization is what makes cross-query and cross-provider scoring possible. Without it, analysts are left comparing inconsistent prose.

Step 4: Score the Five Core Dimensions

AVM then translates normalized evidence into the five core dimensions of presence, citation, authority, consistency and position.

The methodology intentionally separates these concepts because visibility can fail in different ways. A brand may have high presence but poor authority. It may have strong authority but low consistency. It may be cited frequently but appear in weak positions. A single raw mention count cannot diagnose those differences.

Step 5: Apply Contextual Adjustments

The base calculation is not the complete final score. The documented implementation uses ordered adjustments that reward broader discovery and strong authority/citation combinations while penalizing weak presence, poor position distribution and high not-found rates.

The practical principle is simple: not all mentions are equal.

A brand that appears across generic and commercial discovery queries should not be treated the same as a brand that appears only when the user already knows its name. A company that repeatedly appears near the top of recommendation structures should not be scored like a company that is only occasionally listed at the bottom. A model that finds the brand but cannot support it with strong evidence should not receive the same interpretation as a brand surrounded by authoritative references.

Step 6: Add Optional Supporting Evidence

The system can optionally incorporate structured CSV link evidence as a support layer. This does not replace AI analysis. It operates as an additional evidence channel that can influence parts of the visibility interpretation.

For a public-facing strategy, the key lesson is that off-page authority and citation ecosystems still matter. AI search does not make links, mentions, PR or third-party references irrelevant. It changes how those signals may be interpreted and combined.

Step 7: Compare the Brand With Competitors

AVM becomes more actionable when it is comparative. A score of 62 means little without context. A 62 can be strong in a weak category, average in a competitive market, or poor if the leading competitors are consistently above 80.

Competitive analysis should therefore answer:

· Which competitors appear more often?

· Which competitors receive stronger citations?

· Which companies dominate commercial queries?

· Which brands own specific topic clusters?

· Which competitors appear consistently across multiple providers?

· Where does the target brand have a discoverability or authority gap?

Step 8: Interpret the Evidence Strategically

Base AVM creates the foundation. Advanced AVM turns that foundation into a strategic narrative that a marketing or executive team can use. The objective is not to celebrate a score. The objective is to understand why the score exists and how to change the underlying evidence.

AVM Performance Summary:
ThatWare achieved a strong Blended AI Visibility Metric (AVM) score of 77.08/100, resulting in a “Better” performance status. The analysis shows approximately 77% AI visibility across blended AI platforms, reflecting solid brand presence, citation strength, authority, consistency, positioning, and supporting SEO signals.

Provider Breakdown Summary

ThatWare demonstrates strong overall AI visibility across multiple providers. xAI Grok leads with an AVM score of 100, followed by Perplexity AI (78.46), Claude AI (72.14), and OpenAI (59.57).

The overall Presence score of 86.87 and Confidence score of 80.00 indicate excellent brand discoverability and reliable visibility signals. Consistency (68.84) is also performing well, while Citation (51.46), Authority (59.09), and Position (64.13) represent the primary areas for further improvement.

Key focus: Strengthen authoritative third-party citations, brand references, trusted source mentions, and positioning within AI-generated answers.

Breakdown & Competitor Comparison

ThatWare records a strong AVM score of 77.08, supported by excellent Presence (86.87) and strong Consistency (68.84). The main opportunities for improvement remain Citation (51.46), Authority (59.09), and Position (64.13).

In the competitor comparison, ThatWare performs ahead of SEOValley and PageTraffic across all measured metrics. Techmagnate currently records stronger scores, particularly in Citation, Authority, Consistency, and Position.

Key takeaway: ThatWare already has strong AI discoverability; improving third-party citations, authoritative mentions, and placement within AI-generated responses should help close the remaining visibility gap.

Competitor AVM Overview

ThatWare achieves a strong AVM score of 77.08, placing it substantially above SEOValley (49.33) and PageTraffic (56.40) in the current comparison. Techmagnate leads with 84.65, leaving a relatively narrow 7.57-point gap between Techmagnate and ThatWare.

Key takeaway: ThatWare demonstrates strong competitive AI visibility, with further gains in citations, authority signals, and AI answer positioning offering the clearest opportunity to close the remaining gap.

Query Test Summary

ThatWare is mentioned in 5 of the 6 tested queries, indicating strong visibility across the selected AI-search scenarios. The direct branded query achieves a top position, while several service and competitor-related queries appear in the middle of generated responses.

The results also show strong consistency (62.53–76.54) across mentioned queries. However, the broad non-branded query “AI SEO, AEO agency, GEO agency, Advance SEO, LLM SEO services in India” does not currently mention ThatWare.

Key focus: Improve visibility for non-branded commercial queries, strengthen third-party citations, and move existing middle-position mentions toward top-position AI recommendations.

The Five Core AVM Dimensions

1. Presence: Are You Actually in the Answer?

Presence is the most fundamental AI visibility question. If a brand does not appear, it cannot be cited, recommended or compared.

Yet presence is more nuanced than a binary yes-or-no field. Analysts should examine where presence occurs. A company that appears only in branded prompts may have awareness but weak discovery. A company that appears in generic category prompts has stronger evidence that the AI system connects the entity to the problem space.

This is why a high-quality AVM program should segment presence across query types. Informational presence answers whether the brand is associated with educational concepts. Commercial presence reveals whether the brand enters vendor shortlists. Transactional presence shows whether the brand appears when the user’s language signals readiness to act.

Presence gaps often point to one of several underlying problems:

· The brand lacks authoritative third-party references.

· The content does not cover the entity-topic relationship clearly enough.

· The company is strong in branded demand but weak in category-level discovery.

· Important services or products are not represented consistently across the web.

· The site does not provide enough machine-readable context.

· Competitors have stronger citation ecosystems around the same topics.

Improving presence therefore requires more than publishing more pages. The goal is to strengthen the evidence that allows a machine system to associate the brand with the category, problem and audience.

2. Citation: Is the Brand Supported by Evidence?

A brand mention has more value when it is grounded in source evidence. Citation can indicate that the AI system found material it considered useful enough to support its answer.

For marketers, citation analysis should go beyond counting links. The real questions are:

· Which domains are being cited?

· Are those domains authoritative within the relevant category?

· Does the citation support the brand directly or only mention it indirectly?

· Does the source reinforce expertise, product capability, trust or reputation?

· Are the same citations appearing repeatedly across providers?

· Are competitors benefiting from sources where the target brand is absent?

A strong AI citation optimization strategy therefore includes owned content, but it also includes digital PR, expert commentary, high-quality industry coverage, authoritative directories, relevant publications, partner ecosystems, research, case studies, documentation and structured factual pages.

Citation gaps are often where SEO, PR and entity strategy converge.

3. Authority: How Trustworthy Is the Evidence Around the Brand?

Authority is not simply domain authority in the traditional link-metric sense. In an AI visibility context, the more useful question is whether the sources and contextual signals around a brand make the entity credible for the topic being discussed.

A brand can be widely mentioned without being authoritative. Another can have fewer mentions but appear inside stronger evidence contexts. That distinction matters when an AI system is deciding whether to recommend a company, present it as an expert, or cite it as a source.

Authority is strengthened when a brand is consistently associated with high-quality expertise signals. These can include recognized subject matter experts, original research, detailed technical documentation, first-party data, reputable external coverage, institutional partnerships, verified organizational information and clear evidence of real-world capability.

An AI entity optimization program should therefore ask, “What would a machine system find if it tried to verify this claim independently?”

If a company says it is an enterprise AI search leader, does the web contain evidence that supports that description? If it claims experience across global markets, are there case studies, client examples, leadership profiles, service pages and external references that form a coherent evidence network?

Authority is the bridge between marketing claims and machine confidence.

4. Consistency: Does the Brand Tell the Same Story Everywhere?

Consistency is one of the most underestimated factors in AI search readiness.

Brands often create contradictory entity signals without realizing it. A company name appears in several forms. Service descriptions vary wildly across profiles. Leadership information is outdated. Headquarters differ between pages. Product names change. A founder biography uses one set of credentials on the website and another on external platforms. Schema markup does not match visible content. Old pages remain indexed with obsolete positioning.

Humans can often infer that these references belong to the same company. Machines must resolve the ambiguity.

Consistency does not mean every page should repeat identical text. It means the core facts and entity relationships should align. The organization, its people, products, locations, services and topical expertise should form a stable knowledge structure.

A VEM assessment is especially useful here because it evaluates the entity foundation behind visibility. AVM may reveal unstable mentions. VEM can help identify whether inconsistent entity representation is contributing to that instability.

5. Position: Where Does the Brand Sit in the Recommendation Structure?

In traditional SEO, position is explicit. In AI answers, position can be implicit, but it still matters.

If a model recommends five agencies and the brand is first, that creates a different commercial opportunity than appearing fifth. If the brand is mentioned only after the user asks for more options, the visibility quality is weaker. If competitors repeatedly appear earlier in summaries or comparisons, they may be occupying a stronger cognitive position in the answer.

Position analysis should therefore examine patterns, not isolated answers. A single top placement can be noise. Repeated top placement across commercial and comparative queries is much more meaningful.

The most important question is not, “Did we appear?” It is, “How often did we appear in a strong decision-making position?”

Confidence Is a Separate Signal, Not a Sixth AVM Dimension

One of the most important distinctions in the underlying methodology is that confidence is calculated separately from the five core AVM dimensions.

This prevents analysts from confusing visibility quality with evidence sufficiency.

A brand can have a high-looking score from a very small sample. That does not automatically make the result reliable. Conversely, a moderate score supported by a broad and consistent query set may provide a much stronger foundation for decision-making.

The AVM confidence concept is best interpreted as a coverage indicator. It considers the amount and quality of available evidence, including elements such as the number of valid observations and the strength of core dimensions. When optional CSV evidence is used, completeness can also influence the confidence layer.

For business users, this leads to a simple reporting rule: never present an AVM score without the evidence context that produced it.

A strong dashboard should show the score, confidence, query coverage, provider coverage, competitor context and assessment date together.

Query Taxonomy: Why Branded Visibility Is Not Enough

A brand can look highly visible if every prompt contains its name. That is not the same as market discovery.

A robust AI visibility audit should include multiple query classes.

Branded queries test recognition and factual consistency. Examples include “What does ThatWare do?” or “What is ThatWare’s AVM framework?”

Informational queries test whether the brand is associated with educational topics. Examples include “How does AI visibility measurement work?” or “What signals influence LLM citations?”

Commercial queries test whether the brand enters consideration sets. Examples include “best AI search optimization agency” or “AI visibility audit services for enterprise brands.”

Comparative queries reveal how the brand performs when buyers evaluate alternatives. Examples include “AEO agency vs GEO agency” or “traditional SEO vs LLM visibility optimization.”

Transactional queries test whether the brand appears when the user is closer to action. Examples include “request an AI visibility audit,” “hire an AI SEO agency,” or “get a ChatGPT visibility assessment.”

A company that performs well only on branded prompts has recognition. A company that performs across informational, commercial and transactional prompts has a stronger pathway from awareness to demand.

That distinction should influence both content strategy and AVM interpretation.

What Is Advanced AVM?

Base AVM answers a foundational question: how visible is the brand within the sampled AI discovery environment? Advanced AVM asks a more strategic question: what does that visibility mean for market perception, competitive position and future growth?

The documented Advanced AVM layer interprets base evidence through a broader set of strategic metrics. These include discoverability, trust, entity dominance, answer probability, volatility, memory, sentiment, market-share visibility and share of voice. It also produces additional views of query-intent dominance, citation depth, executive analysis, competitor gaps and a roadmap.

These metrics should not be confused with universal scientific measurements. They are structured outputs inside a proprietary diagnostic system. Their value comes from consistency, comparison and actionability.

Advanced AVM Intelligence Summary

ThatWare demonstrates strong AI Discoverability (78) and solid Answer Probability (71), indicating good potential to be found and referenced within AI-generated responses. AI Memory (69) and Entity Dominance (67) also suggest a relatively established entity presence.

The primary improvement areas are AI Trust (58), Volatility Stability (54), and especially AI Market Share Visibility (22). AI Share of Voice (61) shows a reasonable competitive presence but leaves room for expansion.

Key focus: Strengthen trusted third-party citations, authoritative entity signals, consistent brand references, and broader non-branded visibility to improve AI trust, stability, and market share presence.

Query Intent Dominance Summary

ThatWare shows its strongest AI visibility for Informational (82) and Navigational (74) queries, indicating strong brand recognition and educational content coverage. Commercial intent (68) and Comparative intent (61) show moderate performance, while Transactional intent (49) is the largest opportunity for improvement.

Key focus: Build stronger commercial, comparison, and conversion-focused content, supported by case studies, testimonials, service proof, pricing/value information, FAQs, and authoritative third-party citations to improve visibility for high-intent AI searches.

Advanced AVM Competitor Summary

ThatWare demonstrates strong competitive AI performance, particularly in AI Discoverability, AI Memory, Entity Dominance, and Entity Sentiment. Its overall advanced visibility profile is significantly stronger than SEOValley and remains competitive with Techmagnate and PageTraffic across several metrics.

The biggest opportunity is AI Market Share Visibility, where ThatWare trails the stronger competitors. AI Trust, Answer Probability, and Volatility Stability also provide clear areas for improvement.

Key focus: Expand authoritative third-party mentions, citations, comparison coverage, and high-intent content to strengthen market share visibility, trust, and overall AI presence.

Discoverability

Discoverability measures whether the brand can be surfaced when the user is not already asking for it by name. This is one of the most commercially important AI visibility concepts.

A brand with high branded recognition but low discoverability is dependent on existing awareness. A brand with stronger discoverability is more likely to enter conversations earlier, when a prospect is still defining the problem, learning the category or building a vendor shortlist.

Improving discoverability typically requires broader topic coverage, stronger category associations, better third-party validation, more consistent entity relationships and content that answers the kinds of questions buyers ask before they know which company to choose.

Trust

Trust reflects the quality and reliability of the evidence surrounding a brand. In practice, trust is influenced by the consistency of claims, source authority, factual support and the depth of information available to an AI system.

A trust gap often appears when marketing copy is stronger than the supporting evidence. The company may claim leadership, expertise or global capability, but the web does not provide enough independent verification.

The solution is not to make louder claims. It is to make the evidence stronger.

Entity Dominance

Entity dominance looks at how strongly a brand occupies a topic or category relative to competitors. It is a useful way to think about whether the company is merely present or whether it has become a recurring reference point.

Dominance is not created by repeating the brand name. It emerges when the entity is consistently connected to the right topics, services, products, markets, people and supporting sources.

Answer Probability

Answer probability is a strategic score within the methodology, not a statistically calibrated probability that predicts every real-world AI answer.

That distinction is essential. AI systems are dynamic. Their consumer interfaces may differ from their APIs. Retrieval can change. Model versions can change. Personalization and context can change. The metric is therefore best used as an internal comparative signal rather than a promise that a brand will be shown a specific percentage of the time.

Volatility

AI visibility can change even when a website has not changed. Source availability, model behavior, retrieval systems and competitive content can all shift. Volatility helps analysts identify how stable or unstable the observed visibility is.

A brand with high visibility and high volatility may need a different strategy from a brand with moderate but highly stable visibility. The first needs resilience. The second may need expansion.

Memory

Memory, in this context, reflects the persistence or recurrence of brand associations across the sampled analysis. It should not be interpreted as a claim about a provider’s private memory architecture. The practical question is whether the brand is repeatedly connected to the same category, topics and strengths.

Sentiment

Sentiment examines the tone or quality of how the brand is framed. A mention can be positive, neutral, comparative or cautionary. For decision-oriented queries, that difference matters.

The strategic use of sentiment is not to chase superficial positivity. It is to understand the evidence that shapes how the brand is described.

These concepts help compare the brand’s observed presence with competitors inside the sampled AI environment. They are not a census of the entire market. They are comparative visibility indicators tied to the assessment scope.

That makes them especially useful when the same query set is rerun over time. A brand can track whether it is gaining share of answer, improving commercial visibility or reducing a competitor’s lead in key query clusters.

What Is VEM (Vector Entity Modelling)?

AVM measures the visible outcome. VEM examines the entity foundation behind that outcome.

VEM stands for Vector Entity Modelling. In the documented implementation, VEM evaluates six major areas: brand, content, authority, entity relationships, AI readiness and query coverage.

The word “vector” can easily create confusion. In this framework, VEM should not be described as if it were a standalone vector database, embedding-generation system or numerical embedding-similarity pipeline. The inspected implementation uses structured prompt context, normalized AI outputs and deterministic scoring. The term refers to modelling the directional relationships and contextual structure around a brand entity, not to claiming an unimplemented vector-store architecture.

That clarification matters because technical credibility is part of AI search credibility. A strong methodology should explain what it does without borrowing terminology from adjacent technologies in a misleading way.

VEM starts from a simple observation: AI systems do not understand brands only through keywords. They understand relationships.

A company is related to its founders, products, services, customers, locations, industries, case studies, partners, certifications, topics, research, social profiles, review platforms and third-party references. Those relationships form an entity ecosystem.

When the ecosystem is clear, consistent and richly supported, machine systems have an easier time resolving the entity. When it is fragmented, contradictory or thin, visibility can become unstable.

A VEM audit therefore asks questions such as:

· Is the organization clearly defined?

· Are aliases and brand variations connected correctly?

· Are founders and leadership consistently associated with the company?

· Are products and services described consistently across owned and external sources?

· Does the website provide machine-readable information that reinforces visible content?

· Are there strong authoritative references supporting the entity?

· Does the brand cover the query intents relevant to its market?

· Do the site’s content and structured data reinforce the same knowledge relationships?

VEM is not just a technical SEO audit. It is an entity-readiness assessment designed for the AI search environment.

VEM Score Summary

ThatWare achieves an OpenAI Vector Entity Modelling (VEM) score of 61.35/100, indicating a developing entity foundation with established but not yet dominant AI entity signals.

The strongest area is Entity Intelligence (66), followed by AI Readiness (63) and Brand Intelligence (62). Content Intelligence (58) and particularly Query Intelligence (55) present the clearest opportunities for improvement.

Key focus: Strengthen entity-topic relationships, structured entity signals, topical content depth, third-party authority, and non-branded query coverage to improve how clearly AI systems understand, retrieve, and associate ThatWare with its core services.

VEM Competitor Intelligence Summary

ThatWare shows a solid competitive VEM foundation, outperforming SEOValley across the visible intelligence metrics. Its strongest area is Entity Intelligence (66), supported by Brand Intelligence (62) and Authority Intelligence (60).

Techmagnate and PageTraffic currently show stronger Brand and Content Intelligence, while the authority gap is relatively small.

Key focus: Strengthen brand/entity associations, topical content depth, authoritative third-party validation, and broader query coverage to close the VEM intelligence gap with the stronger competitors.

VEM Competitor Visibility Summary

ThatWare demonstrates a solid VEM profile, clearly outperforming SEOValley across the measured pillars. Its strongest area is Entity Intelligence (66), while Brand, Authority, and AI Readiness also show a stable foundation.

Techmagnate and PageTraffic currently demonstrate stronger overall VEM visibility, particularly in Brand and Content Intelligence.

Key focus: Increase content depth, brand authority, entity associations, third-party validation, and AI-focused topical coverage to close the visibility gap with the leading competitors.

advanced VEM competitor visibility graph

Why Entity Modelling Matters in AI Search

Search engines have been moving toward entity understanding for years. AI systems accelerate the importance of that shift because they synthesize information rather than simply returning a list of documents.

A document can match a keyword without the system fully understanding the organization behind it. A recommendation task is different. To confidently recommend a brand, an AI system benefits from a richer understanding of who the company is, what it does, whether it is authoritative, how it relates to the user’s intent and whether external evidence supports the connection.

This is where entity modelling becomes strategically important.

Imagine two companies offering the same service.

Company A has a technically optimized service page, but its external profiles are inconsistent. Its founder information is outdated. Its schema is incomplete. Its product names vary across pages. Third-party references use different positioning statements. The company has limited original research and few authoritative mentions.

Company B has similarly strong on-page SEO, but its organization schema, service pages, leadership pages, case studies, PR coverage, directory profiles, social profiles and third-party references all reinforce the same entity relationships. The brand is repeatedly associated with the same category and expertise.

Traditional SEO may see both as competitive. An entity-oriented AI system may have a much easier time resolving Company B.

VEM is designed to make that difference visible.

The Six Pillars of VEM

1. Brand Clarity

Brand clarity asks whether the company can be identified consistently as one coherent entity.

This begins with obvious elements such as the organization name, primary domain, location, contact details and leadership. It extends to aliases, historic names, abbreviations, product brands and service identities.

A brand clarity audit should examine:

· Organization name consistency across the website and major profiles.

· Founder and executive references.

· Primary location and service-area information.

· Brand descriptions and category labels.

· Product and service naming conventions.

· Links between the main brand and sub-brands.

· Consistency between visible content and structured data.

The objective is not to make every page identical. The objective is to make the core entity unmistakable.

For AI search, this matters because ambiguity can dilute association strength. If different sources describe the same company in incompatible ways, the machine system has to work harder to resolve the entity.

2. Content Coverage

Content coverage measures whether the brand has enough relevant information to support the topics, use cases and questions that matter in its market.

Many SEO programs focus on keyword coverage without asking whether the content builds a coherent entity narrative. VEM reframes the issue. The question becomes: does the content explain the brand’s expertise deeply enough for both users and machines to understand the relationship?

Strong content coverage often includes:

· Core service and product pages.

· Problem-based solution pages.

· Industry or use-case pages.

· Detailed FAQs.

· Comparison content.

· Technical documentation.

· Case studies.

· Research and original data.

· Leadership or expert content.

· Glossaries and definitions.

· Location or market-specific pages where relevant.

Content quality matters more than sheer quantity. Hundreds of thin pages do not automatically create entity strength. A smaller set of deeply connected, well-supported assets can be more valuable.

3. Authority

The VEM authority pillar examines whether the entity is supported by credible external and internal evidence.

Authority can be strengthened by relevant third-party coverage, expert citations, industry recognition, trusted directories, customer references, partner relationships, research, awards with clear provenance, institutional affiliations and quality backlinks.

For AI search, authority should be evaluated contextually. A mention from a highly relevant niche publication may be more valuable for a specific topic than a generic high-authority domain with weak topical relevance.

Authority also includes first-party evidence. A company that publishes detailed research, transparent methodologies, technical documentation or verifiable case studies gives AI systems more material to work with.

4. Entity Relationships

Entity relationships are the center of the VEM model.

This pillar evaluates whether the brand is connected clearly to the people, products, services, topics, locations and organizations around it.

A useful entity graph might include relationships such as:

· Organization -> Founder

· Organization -> Service

· Organization -> Product

· Organization -> Location

· Organization -> Industry

· Organization -> Case Study

· Organization -> Partner

· Organization -> Research Publication

· Service -> Problem Solved

· Service -> Target Audience

· Product -> Feature

· Product -> Use Case

· Expert -> Topic

The goal is not to create a complicated graph for its own sake. The goal is to make relationships explicit enough that both search engines and AI systems can interpret them consistently.

Structured data can help, but schema alone is not sufficient. The relationships also need to be visible in the content and supported across the wider web.

5. AI Readiness

AI readiness evaluates whether the brand’s digital environment is prepared for machine discovery, parsing and interpretation.

The documented VEM input structure includes references to assets such as website URLs, blogs, service pages, schema, sitemaps and AI-readiness files. It can also accept references to machine-readable resources such as ai.txt, llms.txt, semantic sitemaps, entity schema and endpoint documentation.

Not every AI provider uses every proposed file format, and organizations should avoid treating emerging conventions as universal standards. The broader principle is more durable: make important information explicit, structured, crawlable and consistent.

AI readiness can include:

· Clean technical crawlability.

· Accurate canonicalization.

· Structured data aligned with visible content.

· Clear organization and person entities.

· XML and semantic sitemaps.

· Accessible documentation.

· Stable URLs for important factual assets.

· Machine-readable files where strategically relevant.

· Strong internal linking between entity-related pages.

· Consistent metadata and page intent.

A technically inaccessible or semantically confusing site creates unnecessary friction for retrieval systems.

6. Query Coverage

Query coverage measures whether the entity is represented across the intents that matter to the business.

This is where VEM connects directly with AVM. A brand may have a strong entity foundation but still fail to cover important commercial or transactional intents. Conversely, it may have many keyword-targeted pages without a coherent entity model.

A strong query map includes:

· Informational questions.

· Category discovery queries.

· Commercial investigation.

· Comparisons.

· Transactional actions.

· Branded validation.

· Objection handling.

· Problem-based searches.

· Use-case questions.

· Location-specific demand where applicable.

The objective is not to stuff every phrase into one page. It is to build a content and entity architecture that gives each intent a clear home.

What Is Advanced VEM?

Advanced VEM extends the six-pillar foundation into a ten-part strategic entity intelligence model. It is designed to move beyond a single readiness score and show where the entity ecosystem is strong, weak or underdeveloped.

The documented Advanced VEM framework includes ten analysis areas.

The 10 Advanced VEM Intelligence Layers

Advanced VEM extends the six-pillar entity foundation into a ten-layer strategic intelligence model. These layers evaluate not only whether the entity foundation is present, but whether it is coherent, competitive, citable and prepared for AI-mediated discovery.

1. Entity Ecosystem Analysis

This section evaluates the overall network around the brand. It looks at whether the organization, people, products, services and supporting references form a coherent system.

A mature entity ecosystem should answer basic questions without contradiction. Who owns the brand? What does it sell? Who are the key experts? Which locations matter? Which industries does it serve? What evidence supports those claims?

Weaknesses in the ecosystem often show up as duplication, orphaned pages, inconsistent profile information, outdated sub-brands or unconnected expert content.

2. Knowledge Graph Strength

Knowledge graph strength examines how clearly the brand’s important relationships can be represented as structured knowledge.

This does not require a company to operate its own large-scale knowledge graph. It means the brand’s digital footprint should make entity relationships explicit and machine-readable.

A strong knowledge graph posture can be supported by structured data, consistent entity naming, internal linking, authoritative external references and clear relationships between the organization and its products, services and people.

3. AI Search Readiness

AI search readiness evaluates whether the entity’s content, technical environment and supporting evidence are suitable for modern retrieval and synthesis systems.

This includes crawlability, structured information, authoritative content, stable factual pages, semantic relationships and the availability of resources that help machines interpret the brand correctly.

The practical goal is not to optimize for one crawler. It is to reduce ambiguity across the ecosystem.

4. Brand-Entity Consistency

Brand-entity consistency measures whether the organization presents the same essential identity across owned and external sources.

This section should review name variations, descriptions, locations, leadership, service names, product names, credentials and business categories. Inconsistency may not always cause a direct ranking problem, but it can weaken machine confidence and create contradictory summaries.

5. Competitive Entity Gap Analysis

Competitive entity gaps reveal where rival brands have stronger machine-readable or authoritative relationships.

For example, a competitor may have better association with a high-value industry, more third-party citations around a specific service, stronger expert entities, richer case-study evidence or clearer product positioning.

This analysis is strategically useful because it converts a vague statement such as “competitors are stronger in AI” into specific evidence gaps that can be addressed.

6. Query-Intent Coverage Analysis

Advanced VEM examines whether the entity architecture supports the full funnel of user intent.

A company may have dozens of educational articles but no strong commercial proof pages. Another may have excellent service pages but little educational content that explains the category. A third may rank for awareness queries but lack the comparisons and buyer guides that AI systems use when constructing recommendations.

Query-intent coverage makes those structural gaps visible.

7. Semantic Content Strength

Semantic strength evaluates whether content covers concepts, relationships and supporting subtopics deeply enough to establish topical meaning.

This is different from repeating a primary keyword. A semantically strong page explains the topic, defines entities, answers related questions, connects concepts, demonstrates expertise and links to supporting evidence.

For an AVM/VEM page, semantic strength may include clear explanations of AI visibility, citations, authority, entity modelling, LLM visibility, AI search readiness, knowledge graphs, GEO, AEO and commercial query coverage.

8. AI Citation Probability

AI citation probability is a strategic indicator inside the framework, not a guaranteed prediction of provider behavior.

The useful question is whether the brand produces or attracts the kinds of sources that AI systems are likely to rely on. Citation probability can be improved by making claims verifiable, publishing original evidence, earning relevant external coverage and structuring content so that important facts are clear and extractable.

9. GEO Readiness

GEO, or generative engine optimization, focuses on improving the probability that a brand’s information is discoverable, understandable and useful in generative answer environments.

GEO readiness in Advanced VEM therefore overlaps with content authority, entity clarity, citation ecosystems, machine-readable structure and query coverage.

A mature GEO strategy is not a replacement for SEO. It extends SEO principles into answer synthesis and entity understanding.

10. Strategic Roadmap

The final Advanced VEM layer converts findings into prioritized action.

A useful roadmap should separate quick wins from structural work. It should also distinguish between owned-site changes, off-page authority building, technical improvements, entity consistency work, content development and measurement.

The roadmap is where analysis becomes operational. Without it, a sophisticated score remains an interesting report rather than a growth system.

Advanced VEM Summary

ThatWare records an Advanced VEM Score of 59.90/100, showing an established entity foundation with several areas requiring further optimization. The strongest signal is Brand Entity Consistency (66), followed by Entity Ecosystem Analysis (64) and AI Search Readiness (63).

The main improvement opportunities are GEO Readiness (54), Query Intent Coverage (55), Competitive Entity Gap (56), and Semantic Content Strength (58).

Key focus: Expand semantic topic coverage, strengthen the knowledge graph and entity relationships, improve non-branded query coverage, and build more authoritative third-party citations to increase AI citation probability and GEO readiness.

Advanced VEM Competitor Summary

ThatWare achieves an Advanced VEM score of 59.90, performing ahead of SEOValley (52.29) but below Techmagnate (68.43) and PageTraffic (67.14).

ThatWare shows solid performance in Brand Entity Consistency (66), Entity Ecosystem (64), and Knowledge Graph Strength (62). It also records AI Search Readiness of 63 in this analysis.

Key focus: Strengthen the entity ecosystem, knowledge graph connections, semantic content coverage, query-intent visibility, and third-party authority signals to close the Advanced VEM gap with the leading competitors.

advanced vem competitor entity comparison

Advanced VEM Competitor Visibility Summary

ThatWare shows a balanced Advanced VEM profile, with particularly solid performance in Brand Consistency, Entity Ecosystem, AI Search Readiness, and Knowledge Graph Strength.

Compared with competitors, ThatWare performs well above SEOValley across most core entity signals, while Techmagnate and PageTraffic currently maintain stronger overall Advanced VEM visibility.

Key focus: Improve query-intent coverage, semantic content strength, citation probability, GEO readiness, and competitive entity signals to narrow the gap with the leading competitors.

AVM vs VEM vs Advanced AVM vs Advanced VEM

Module	Primary Question	Core Focus	Typical Output
AVM	How visible is the brand in sampled AI discovery?	Presence, citation, authority, consistency, position	Visibility score, breakdown, query evidence, competitor comparison
Advanced AVM	What does the visibility pattern mean strategically?	Discoverability, trust, dominance, answer probability, volatility, memory, sentiment, share of voice	Strategic interpretation, competitive gaps, executive insights, roadmap
VEM	How strong is the entity foundation behind visibility?	Brand, content, authority, entity relationships, AI readiness, query coverage	Entity readiness score, recommendations, competitor observations
Advanced VEM	Where are the deeper entity and GEO opportunities?	Knowledge graph, entity ecosystem, semantic strength, AI citation probability, GEO readiness	Ten-part analysis, risks, opportunities, strategic roadmap

The simplest way to understand the relationship is this:

AVM measures the observable AI visibility outcome. VEM examines the entity foundation that can make that outcome stronger, clearer and more durable.

Advanced AVM interprets visibility. Advanced VEM interprets entity readiness.

Together, the four modules provide a broader view than any one score can offer.

Blended Multi-Provider AI Visibility

One of the most important ideas in the AVM/VEM architecture is the Blended layer.

AI search is not a single system. Different providers use different models, retrieval methods, source preferences, interfaces and synthesis behaviors. A brand that performs strongly in one environment may be weaker in another. Treating one provider as the complete truth creates a measurement blind spot.

The documented Blended architecture addresses that problem by combining eligible saved results from multiple providers. It does not call a mysterious fifth AI model. It aggregates existing provider-specific evidence and normalizes the contribution of eligible sources.

In the September 2026 technical snapshot, the full analytical pipeline covered OpenAI, xAI, Claude and Perplexity. The Blended layer could combine valid saved outputs from those providers when the required prerequisites were satisfied. At least two valid sources were required for a blended stage. Missing or invalid sources were skipped rather than fabricated.

That design reflects an important methodological principle: multi-provider coverage is more useful when it preserves disagreement instead of hiding it.

Suppose a brand performs strongly in OpenAI-based analysis but weakly in Claude and Perplexity. A simple average can be useful, but the disagreement itself is also informative. It may indicate that the brand’s authority ecosystem is concentrated in sources favored by one retrieval system. It may reveal inconsistent entity coverage. It may expose a category where the company is well known in one information ecosystem but not another.

A serious AI visibility program should therefore report both blended performance and provider-level variance.

This creates several useful management views:

· Overall blended visibility.

· Provider-by-provider AVM scores.

· Provider disagreement on the same query cluster.

· Competitor strength by provider.

· Citation-source overlap.

· Query categories where the brand is universally strong.

· Query categories where visibility depends on one provider.

· Entity signals that appear stable across systems.

The objective is not to eliminate provider differences. The objective is to understand them.

Provider-Specific Measurement and the Importance of Scope

A public AVM/VEM report should always identify the scope of the assessment. Provider identity, model context, query set, language, country and assessment date all influence the result.

The documented system reflects this by storing provider identity and separating provider-specific outputs. That is good analytical practice because it prevents one provider’s payload from being silently relabeled as another provider’s result.

For business users, the most important lesson is that AI visibility is a snapshot of sampled behavior, not a permanent universal ranking.

Provider interfaces also matter. The behavior of an API or search endpoint is not necessarily identical to the consumer product that users see. Features such as personalization, conversation history, retrieval configuration and interface-level orchestration can change the answer.

This does not make provider testing useless. It means the results should be interpreted correctly.

A defensible statement sounds like this:

“In the sampled assessment conducted on these providers, using this query set and market context, the brand showed stronger citation authority on Provider A and weaker commercial discoverability on Provider B.”

An indefensible statement sounds like this:

“The brand has a permanent 78% chance of appearing in every AI answer.”

AVM and VEM are strongest when they are used as repeatable diagnostics with clearly defined boundaries.

How AVM and VEM Work Across AI Search, AEO, GEO and LLM SEO

The growth of AI search has produced a crowded vocabulary. SEO, AEO, GEO, LLM optimization, AI SEO, AI search optimization and answer-engine optimization are often discussed as if they were competing disciplines.

In practice, they overlap.

SEO remains the foundation for discoverability through crawlable, indexable, useful content and strong authority signals.

AEO, or answer engine optimization, focuses on making information easy to extract, understand and present as a direct answer.

GEO, or generative engine optimization, focuses on improving how a brand and its information are represented inside generative answers.

LLM visibility optimization focuses on the way large language model systems retrieve, interpret, cite and recommend brands and information.

AVM and VEM do not require a company to choose one label. They provide measurement layers that can sit above the strategy.

AVM can help show whether an AEO, GEO or LLM visibility program is improving observed brand presence. VEM can show whether the entity and content foundation is becoming stronger.

This is useful because marketing teams often optimize before they have a baseline. They publish more content, add schema, create an llms.txt file, write more FAQs and increase digital PR. Those activities may be sensible, but without a measurement framework it is difficult to know which changes are influencing the answer environment.

A mature program therefore follows a cycle:

1. Measure current AVM and VEM performance.

2. Identify the weakest dimensions and query clusters.

3. Map those gaps to technical, content, authority or entity actions.

4. Implement changes.

5. Reassess the same baseline query set.

6. Add new queries only after preserving the historical comparison set.

7. Track provider-specific and blended changes over time.

That turns AI search optimization from a collection of tactics into a measurable operating system.

Commercial, Transactional and Informational Query Intelligence

A major weakness in many AI visibility programs is overreliance on informational queries.

Informational visibility matters because it establishes topical relevance and educational authority. However, companies do not invest in AI search visibility only to be defined correctly. They want to be considered, compared and selected.

That means a serious AVM/VEM program should deliberately cover three major intent groups: knowledge-based, commercial and transactional.

Knowledge-Based Queries: Build Topic Association

Knowledge-based queries usually begin with questions such as what, why, how, when or which factors. They test whether the brand is connected with the educational concepts that define its category.

For an AI search optimization company, useful knowledge queries might include:

· What is AI visibility?

· What is an AI Visibility Metric?

· What is Vector Entity Modelling?

· How does AI citation optimization work?

· What is the difference between GEO and SEO?

· How do LLMs choose sources?

· What is AI search readiness?

· What is knowledge graph strength?

· How can a brand improve ChatGPT visibility?

· What affects AI share of voice?

These queries support early-stage discovery. They are also important for semantic content development because they reveal the concepts a brand should explain clearly.

To improve knowledge-based visibility, create content that is definitional, evidence-based and structurally clear. Use concise answers near the beginning of sections, then expand with detail. Connect related concepts through internal links. Use experts and original research where possible. Keep terminology consistent across the site.

Commercial Queries: Enter the Consideration Set

Commercial queries show that the user is evaluating options. These are among the most strategically important prompts in an AI visibility audit.

Examples include:

· Best AI visibility audit services

· Top AI search visibility agency

· AI visibility optimization agency for enterprise brands

· AVM audit services

· VEM audit services

· LLM visibility optimization services

· AI entity optimization services

· ChatGPT visibility optimization company

· Generative engine optimization services

· Answer engine optimization services

· Best GEO agency for global brands

· AI search readiness consulting

Commercial queries should be tested by industry, company size, geography and use case when those dimensions matter to the business.

To improve commercial visibility, a brand usually needs more than educational content. It needs proof.

Strong commercial assets include:

· Detailed service pages.

· Comparison pages.

· Case studies.

· Industry-specific proof.

· Methodology pages.

· Pricing or engagement-model guidance where appropriate.

· Testimonials and verifiable client evidence.

· Clear expert credentials.

· Third-party reviews and coverage.

· Strong “why choose us” evidence without unsupported superlatives.

AI systems cannot recommend evidence that does not exist.

Transactional Queries: Make the Path to Action Explicit

Transactional queries indicate higher intent. The user is not simply learning or comparing. The user may be ready to request, buy, book, hire or contact.

Examples include:

· Get AI visibility audit

· Request AVM VEM audit

· Book AI search readiness assessment

· AI visibility assessment for enterprise website

· Request LLM visibility audit

· Get ChatGPT visibility audit

· AI citation audit service

· GEO readiness audit

· AI brand visibility report

· Hire AI visibility optimization agency

Transactional visibility is frequently weak because many brands publish extensive thought leadership but provide little machine-readable evidence of how to engage.

A transactional page should make the action obvious. It should describe the deliverable, who it is for, what is included, how the process works and what happens next. It should also reduce uncertainty. If a service is bespoke, explain the consultation process. If pricing varies, explain the factors that influence scope. If the deliverable includes an audit, show a sample structure without exposing confidential data.

Why Intent Mix Matters to AVM

The AVM scoring logic gives importance to discovery beyond branded queries. In practical terms, this means a brand should not celebrate visibility that depends on users already knowing its name.

A balanced query set allows teams to see the full path:

Knowledge -> Consideration -> Comparison -> Transaction -> Branded Validation

When a brand is strong at every stage, AI visibility becomes commercially meaningful.

How to Re-Optimize a Page Around AVM and VEM Keywords Without Keyword Stuffing

The safest way to integrate the commercial, transactional and knowledge-based keyword clusters is to assign each cluster to a clear section purpose.

The H1 and opening paragraphs should prioritize the core entity terms: AI Visibility Metric, Vector Entity Modelling, AVM, VEM, AI visibility score and AI search visibility.

The explanatory sections should cover informational phrases such as what is AVM in SEO, what is VEM in AI SEO, how AVM score works, how VEM score works, AI search readiness, AI citation probability, knowledge graph strength and LLM brand visibility.

The service-oriented sections should introduce commercial phrases such as AI visibility audit services, AVM audit services, VEM audit services, AI search visibility services, AI entity optimization services, LLM visibility optimization services and generative engine optimization services.

The final CTA and FAQ sections should naturally cover transactional phrases such as request AVM VEM audit, get AI visibility audit, AI visibility assessment, AI citation audit, GEO readiness audit and AI brand visibility report.

The objective is semantic completeness, not repetition. If a keyword feels awkward in a sentence, the sentence should be rewritten or the keyword should be assigned to a more appropriate section.

A good AI-era content strategy should sound useful to a human before it sounds optimized to a crawler.

AI Search Readiness: Technical and Machine-Readable Foundations

AI search readiness is broader than a single file or schema type.

The VEM methodology considers the availability of website and asset references, authority/entity references, query sets and machine-readable resources. In the documented implementation, VEM inputs can include resources such as blog pages, service pages, schema references, sitemaps, ai.txt, llms.txt, semantic sitemaps, entity schema and endpoint context.

These assets should be treated as components of a larger information architecture, not magic switches.

Crawlability Still Comes First

If important content cannot be crawled or rendered reliably, advanced AI files cannot compensate for the problem. Technical SEO fundamentals remain essential:

· Correct status codes.

· Stable canonical URLs.

· Sensible robots directives.

· Accessible internal links.

· Clean XML sitemaps.

· Fast, functional templates.

· Avoidance of accidental noindex rules.

· Server-rendered access to important content where appropriate.

Structured Data Should Match Visible Content

Schema is most useful when it reinforces facts that a user can also see. Organization, Person, Service, Product, Article, FAQ and other relevant types can help clarify relationships, but only if the markup is accurate.

Do not use structured data to invent expertise that the page does not demonstrate.

Entity Pages Need Stable Facts

Important organizational facts should have clear, durable homes. Leadership pages, company information, service definitions, product details and methodology pages should not move constantly or contradict one another.

Machine-Readable Files Need Governance

Emerging AI-focused files can be useful for organizing information, but they should be versioned, reviewed and kept consistent with the website. An outdated llms.txt file or semantic sitemap can create more confusion than value.

AI readiness is therefore a governance problem as much as a technical problem.

Knowledge Graph Strength and Brand-Entity Consistency

A brand’s knowledge graph is not limited to formal schema markup. It is the web of relationships that can be inferred from all available evidence.

For ThatWare, a simplified entity model might connect the organization with AI search optimization, AVM, VEM, AEO, GEO, semantic SEO, LLM visibility, leadership, research, case studies and specific service capabilities. Each relationship should be supported by content and external evidence.

The strongest entity models usually share several characteristics:

1. Stable naming. The same organization and product names are used consistently.

2. Clear ownership. Founders, executives and brands are connected accurately.

3. Distinct concepts. Proprietary frameworks are defined once and reinforced consistently.

4. Authoritative support. Important claims are backed by evidence.

5. Semantic depth. Core topics are explained comprehensively.

6. Internal coherence. Related pages link logically to one another.

7. External corroboration. Third-party sources confirm important facts.

This is one reason the AVM/VEM naming issue matters so much. If one page defines VEM as “Visibility Engagement Metric” and another defines it as “Vector Entity Modelling,” the brand creates a contradiction around its own proprietary framework. A human may recognize the error. An AI system may treat the two phrases as separate concepts or reproduce the wrong expansion.

Brand-entity consistency is therefore not cosmetic. It is part of machine trust.

Competitor Benchmarking in the AI Answer Environment

AI visibility is inherently relative.

A company can improve its own score while competitors improve faster. A brand can dominate informational queries while a rival captures commercial recommendations. Another competitor may be weaker overall but own a valuable niche topic.

A useful AVM/VEM competitor analysis should therefore separate several dimensions.

Presence Gap

Which competitor appears more often across the same query set?

Commercial Discovery Gap

Which competitor is more frequently surfaced in “best,” “top,” “recommended,” “agency,” “platform,” “solution” and “provider” queries?

Citation Gap

Which competitor is backed by stronger or more frequent citations?

Authority Gap

Which brand has better supporting evidence across trusted industry sources?

Entity Gap

Which competitor has clearer relationships between its organization, people, products, services and topics?

Content Gap

Which competitor covers important buyer questions more comprehensively?

GEO Readiness Gap

Which competitor is easier for generative systems to interpret and cite?

The output should be a prioritized gap map, not a list of everything a competitor does.

If a competitor has stronger commercial visibility because it publishes transparent comparison pages and industry case studies, that is actionable. If it has more social posts but those posts do not appear in relevant evidence, that may not deserve priority.

Technical Architecture and Operational Deep Dive

The AVM and VEM methodology is supported by a working application architecture, provider integrations, deterministic scoring services, repositories, report snapshots and operational controls. The following sections document the implementation layer so the framework can be understood not only as a marketing concept, but as a measurable system with defined data flows, provider boundaries, reporting behavior, risks and maintenance requirements.

This technical layer is especially useful for engineering, product, SEO research, AI search, analytics and governance teams that need to understand how an assessment is created, stored, compared, shared and maintained over time.

Actual Technology Stack

Layer	Implemented technology	Evidence / qualification
Pages	PHP-rendered HTML; inline and external CSS	index.php, results.php, admin/*.php, public report scripts
Browser logic	Vanilla JavaScript, Fetch API, FormData, DOM APIs, canvas capture	assets/js/app.js, results.js, vem.js, snapshot scripts
Charts	Chart.js loaded from a CDN	results.php:27; dependency URL is not version-pinned
jQuery / UI framework	No jQuery integration identified in first-party source	Do not add jQuery or Bootstrap by assumption
Server	Core PHP; manual includes; procedural endpoints and OO classes	api/, core/, services/, repositories/
SQL access	PDO, prepared statements, MySQL-compatible SQL	core/Database.php, repository classes
Database export	MariaDB 10.6.28; database thatwareai_avm_score_v3_admin	SQL header; live version not independently verified
Export environment	phpMyAdmin 5.2.3 and PHP 8.4.25	Describes exporter, not necessarily web workers
Locked PHP dependency floor	PHP 8.2 or newer	composer.lock; verify extensions in target runtime
Active PDF engine	Dompdf 3.1.5	Lockfile and three active export handlers
Other installed PDF tooling	Browsershot 5.4.0, Puppeteer 25.2.1	Retained; not selected by active export handlers
Supporting PHP packages	php-font-lib 1.0.2, php-svg-lib 1.0.2, masterminds/html5 2.10.1, sabberworm/php-css-parser 9.4.0, symfony/process 7.4.13	composer.lock
External assessment services	OpenAI Responses, xAI Responses, Anthropic Messages, Perplexity Search/Sonar, SerpAPI	Provider services and stored configuration
Payment, mail and vector services	No gateway, email-delivery API or vector store identified	Does not describe services outside this project

Server extensions to verify include PDO MySQL, cURL, JSON, mbstring, DOM/XML and extensions required by Dompdf and image processing. The offline syntax runtime was PHP 8.4.23 and Node 22.16.0; those are audit-environment versions, not asserted production versions.

System Architecture and Dependency Boundaries

The executable boundary is the PHP file requested by the browser. Page scripts render the interface; api/*.php scripts validate and dispatch; services perform provider requests, normalization, scoring and report building; repositories encapsulate much, but not all, SQL access. Some API/public scripts still issue SQL directly. Frontend state is managed by cooperating JavaScript files, not a single compiled application bundle.

· Private application pages

· index.php –app.js–> api/run_openai.php

· |

· OpenAIProviderService -> AVM scorer

· |

· results.php <——— RunRepository

· |

· +–results.js–> api/run_provider.php

· | -> selected provider OR saved-result blend

· +–results.js–> api/generate_advanced_insights.php

· | -> stage-specific service

· +–vem.js—–> api/run_vem.php / run_advanced_vem.php

· +–blended-vem-interface.js–> aggregate VEM endpoints

· +–snapshot scripts–> snapshot services/repositories

· |

· public token links

· |

· HTML renderer / Dompdf export

The module dependency graph is not one strict linear chain. Individual Advanced AVM consumes base AVM context. Individual VEM consumes run data, submitted entity inputs and available base/advanced context. Advanced VEM requires a successful parent VEM. Full snapshots require all four modules from the same provider and a matching Advanced VEM parent. Blended stages add prerequisites for current blended parents and at least two valid individual-stage sources.

Authentication, provider identity and customer ownership are different concerns. PrivateAccessGate controls shared frontend access; ApiSecurity adds request rules; ProviderIdentity prevents mixing provider identities; none implements a per-customer run ownership boundary. Admin authentication is independent.

Actual Folder Structure

· avm-score-v3/

· .htaccess

· index.php private input page

· results.php private multi-module results page

· share-avm-report.php token-based AVM snapshot page

· vem-report.php public VEM wrapper

· full-report.php public full-report page

· admin/

· api/ metrics, CSV export and rollup job

· assets/ admin stylesheet

· config/ core/ DB configuration, sessions and auth

· repositories/ services/ provider/admin/usage/pricing support

· login.php logout.php dashboard.php providers.php

· token-analytics.php usage-logs.php

· api/ generation, state, CSV and sharing

· assets/

· css/ private/public/PDF styles

· js/ form, results, provider state, snapshots

· config/ DB, application, private access, costs

· core/ DB, response, identity and guards

· database/ migration and verification SQL

· repositories/ run, module, context and report SQL

· services/ providers, prompts, scoring, reports

· public/ token reports and PDF export handlers

· scripts/ retained Chrome/Puppeteer tooling

· storage/ uploads, debug/runtime and report files

· vendor/ Composer-installed libraries

· node_modules/ npm-installed libraries

· composer.json composer.lock

· package.json package-lock.json

The archive also contains dated backups and runtime artifacts. These are included in the inventory manifest but not treated as active entry points merely because they are in the ZIP. The first-party file register and archive manifest identify exact paths and should inform a clean deployment allowlist.

There is no separate ajax/, controllers/, models/ or views/ directory in this structure. The AJAX endpoints are the actual api/ scripts. A conventional framework tree should not be substituted for the source structure.

File-by-File Architecture: Primary Navigation Map

Q: What is an AI Visibility Metric?

An AI Visibility Metric, or AVM in ThatWare's methodology, is a structured way to evaluate how a brand appears across a defined set of AI-assisted discovery queries. Instead of relying only on traditional search rankings, the framework examines whether the brand is present, how often it is cited, the authority of the surrounding evidence, how consistently the entity is represented and where it tends to appear in recommendation or answer structures.

Q: What is Advanced AVM?

Advanced AVM is the strategic interpretation layer built on top of base AVM evidence. While base AVM focuses on core visibility dimensions, Advanced AVM analyzes broader concepts such as discoverability, trust, entity dominance, answer probability, volatility, memory, sentiment, market-share visibility and share of voice.

Q: What is Advanced VEM?

Advanced VEM extends the base entity-readiness assessment into ten strategic areas: entity ecosystem analysis, knowledge graph strength, AI search readiness, brand-entity consistency, competitive entity gaps, query-intent coverage, semantic content strength, AI citation probability, GEO readiness and a strategic roadmap.

Q: What is AI search readiness?

AI search readiness describes how prepared a brand's digital ecosystem is for discovery, interpretation, retrieval and citation by modern AI-assisted systems. It includes technical foundations such as crawlability, canonicalization, structured data, sitemaps and stable URLs. It also includes content clarity, entity relationships, external authority, consistent facts and coverage of the queries buyers actually ask.

File / group	Responsibility	Called by / downstream dependencies
index.php	Private input page and CSV controls	Loads app.js; checks private gate
results.php	Results, provider tabs and VEM input shell	Provider context, results, VEM and snapshot scripts
api/run_openai.php	Initial run creation and OpenAI AVM	Homepage; normalization, factory, scorer, RunRepository
api/run_provider.php	Additional provider/base blend on existing run	results.js; provider services and shared persistence
api/generate_advanced_insights.php	Advanced AVM dispatcher	Provider-specific AdvancedInsight services
api/run_vem.php	Individual VEM dispatcher and OpenAI implementation	Dedicated modern services; shared parser/repository
api/run_advanced_vem.php	Individual Advanced VEM dispatcher	Parent VEM, advanced services/repository
api/run_blended_vem.php, run_blended_advanced_vem.php	Aggregate-only VEM endpoints	Blended services; no external provider call
repositories/RunRepository.php	Run lifecycle, provider output, queries and progress	runs, provider result/query tables
services/AVMScorerService.php	AVM dimensions, modifiers and confidence	Normalized query evidence; no SQL
services/SeoCsvScorerService.php	Link CSV support scoring	Parsed links; no live authority API
services/VEMScorerService.php	Six-pillar weighted VEM total	VEM parser
services/AdvancedVEMParserService.php	Ten-section normalization and mean	Advanced generation/reconciliation
repositories/ReportSnapshotRepository.php	Snapshot/link/PDF metadata	Modern AVM sharing and PDF audit
services/VemSnapshotService.php, FullReportSnapshotService.php	Validate lineage, sanitize and freeze reports	Snapshot endpoints and public retrieval
services/AvmDompdfExportService.php	Active AVM PDF wrapper	public/export-avm-pdf.php
services/FullReportPdfBuilderService.php	Full-report PDF HTML	public/export-full-report-pdf.php
admin/providers.php	Provider configuration editor	Auth, CSRF, ProviderRepository
admin/services/PricingService.php	Stored pricing/cost estimates	Usage tracking and budget evaluation

The Reference Atlas extends this map to all 233 first-party files, including actual classes/functions, source locations, direct SQL operations, includes and inferred callers. “No direct SQL” does not mean “no database effect”: services operate through repositories. Inferred callers are distinguished from confirmed browser/endpoint execution paths.

Frontend Architecture

1 Input and initial execution

index.php:806-974 owns the form. assets/js/app.js validates fields, handles competitor controls and CSV drag/drop/upload, builds FormData and sends initial generation. CSV upload is a separate request; its returned import ID is attached to the later run. The initial request goes to api/run_openai.php, not run_provider.php.

The loading display is substantially client-simulated. startSmartProgress() advances visual stages while the synchronous server request remains outstanding. startProgressPolling(runId) exists, but initial submission starts it only after receiving the generation response containing run_id (app.js:1191-1192). That polling is not evidence of a queued initial task or live initial API progress.

2 Provider result state

results.php:391-416 publishes RUN_ID, defaults to OpenAI, and loads scripts in an important order: provider context, blended capability, results, VEM loader, VEM logic, blended VEM interface, VEM snapshot and full snapshot. results.js loads metadata/provider buttons, requests a provider result, renders scores/tables/charts and restores or generates Advanced AVM.

provider-context.js emits provider-changing/changed events. results.js uses request sequence/promise controls to avoid an old request painting a newly selected tab. vem.js stores provider-scoped state and clears/restores it on provider changes. Blended has a separate interface that intercepts relevant actions rather than treating aggregate generation as another external AI request.

3 UI-to-server action map

User action	Browser owner	Endpoint	Backend / response
Download template	Form / app.js	api/download_csv_template.php	Four-column link template
Upload CSV	app.js:505	api/upload_csv.php	Validation, score summary, import ID
First AVM	app.js:1131-1159	api/run_openai.php	Create run, OpenAI, save, return result
Provider buttons	results.js:287-298	api/get_providers.php	Enabled rows plus virtual Blended
Switch/generate provider	results.js:653-692	api/run_provider.php	Cached/new result or local blend
Restore Advanced AVM	results.js:3484	api/get_advanced_insights.php	Stored provider-scoped insights
Generate Advanced AVM	results.js:3539-3618	api/generate_advanced_insights.php	Insight payload / cached flag / error
Restore VEM	vem.js:253-273	api/get_vem_state.php	VEM/Advanced VEM state
Individual VEM	vem.js:535-576	api/run_vem.php	Input, provider call, six-pillar result
Individual Advanced VEM	vem.js:775	api/run_advanced_vem.php	Parent-linked ten-section analysis
Blended VEM	blended-vem-interface.js:593-633	api/run_blended_vem.php	Aggregate saved individual VEM
Blended Advanced VEM	blended-vem-interface.js:710-747	api/run_blended_advanced_vem.php	Aggregate saved advanced results
AVM public report	results.js:5693-5726	api/create_avm_public_share.php	Save capture, return token URL
VEM public report	vem-public-snapshot.js:1880-2000	api/create_vem_public_share.php	Validate lineage and freeze content
Full public report	full-report-public-snapshot.js:1939-2009	api/create_full_report_public_share.php	Validate four modules and freeze
PDF export	Public controls	public/export-*-pdf.php	Token validation, Dompdf, download

4 Rendering and presentation fallbacks

results.js controls AVM breakdowns, gauge, competitor chart, query rows, CSV support, recommendations and advanced metrics. vem.js controls six-pillar VEM, Advanced VEM sections, competitor analysis and roadmaps. Missing narrative/competitor/roadmap fields can receive frontend-derived fallback content (results.js:3952-4627, vem.js:2183). Such content is not fresh independent AI evidence.

Snapshot scripts copy the current provider’s data and rendered sections, convert canvas charts to images and expose share controls after successful capture. Report integrity therefore depends on server data and browser state. Error messages may come from server message fields; legacy routes expose more raw detail than modern guarded routes. Copy/social links distribute bearer URLs, not authenticated invitations.

Backend Architecture

Four practical layers are present, with exceptions: entry scripts; orchestration/services; repositories; infrastructure/helpers. This is a description of observed responsibilities, not a claim of perfect layering. api/run_vem.php, api/run_advanced_vem.php, public handlers and some admin APIs still contain substantial orchestration or direct SQL.

core/Database.php uses config/database.php. Admin has its own admin/core/Database.php and admin/config/database.php. Both define a Database class in their respective application context; careless cross-inclusion can cause class/configuration conflicts. Usage logging bridges into admin support through existing include patterns. Preserve or deliberately unify that boundary rather than arbitrarily loading both trees.

InputNormalizeService and InputHashService normalize inputs and derive reuse fingerprints. ProviderRequestPolicyService, runtime classes and provider context repositories enforce model/endpoint/deadline/source rules. Response::json() standardizes many responses; ApiSecurity provides guards and reference-tagged logging for newer endpoints.

The homepage path creates/updates the run and saves several records separately. The modern provider path can save a result and its query rows together through RunRepository::saveProviderResultWithQueriesAndMeta. There is no single transaction spanning a paid remote request and the entire run. Holding a DB transaction over a slow remote request would be undesirable; instead, partial states and ambiguous remote outcomes require explicit handling.

Database Architecture

A run is the assessment container, with results separated by provider_key. Base outputs are in avm_v3_provider_results; query evidence in avm_v3_provider_queries; Advanced AVM in avm_v3_advanced_insights; VEM input/output in avm_v3_vem_inputs / avm_v3_vem_results; Advanced VEM in avm_v3_advanced_vem_results.

Configuration and accounting are separate. avm_api_providers selects runtime credentials/models/flags/weights/timeouts. avm_v3_provider_models and avm_v3_model_pricing support usage/pricing metadata. Their existence does not mean every generation selects its model from those tables: services primarily consume provider rows and environment overrides.

Reports use snapshot, public-link and PDF metadata tables alongside a separate legacy public-share table. This is not one unified report model. Snapshot columns named avm_json and advanced_avm_json also carry VEM data for the VEM report type; decode them according to report_type.

The export mixes Latin-1 and UTF-8 definitions. JSON-like values often use LONGTEXT; selected columns have JSON-validity checks. Do not assume universal native JSON or universal UTF-8. Many relationships are logical only, and identifier types differ: run IDs are signed INT while many child references are unsigned BIGINT. Adding FKs requires a type audit.

Observed data: 604 runs have 526 completed, 74 pending and 4 failed rows. There are 347 base provider results, 81 Advanced AVM records, 112 VEM results and 27 Advanced VEM results. Counts are export observations, not unique paying customers or proof of current health. Targeted non-null reference checks found no unresolved references; the verification ledger defines their limited coverage.

Database Tables

The Reference Atlas preserves every column definition, type, nullable/default rule, index and ALTER statement. Tables below use id as primary key; the atlas gives actual type/signedness/auto-increment details.

Table	Rows	Purpose / main consumers
avm_admin_users	1	Admin identity/hash/status; AdminRepository/Auth
avm_api_logs	172	Legacy request/token/cost ledger
avm_api_providers	5	Credentials, endpoints/models, flags/weights/timeouts
avm_v3_admin_audit_logs	0	Provisioned audit schema; no populated audit trail
avm_v3_advanced_insights	81	Advanced AVM; unique run/provider; legacy share fields
avm_v3_advanced_vem_results	27	Parent-linked Advanced VEM; unique run/provider
avm_v3_api_routes	0	Provisioned model routing; not current dispatcher
avm_v3_api_usage_logs	371	Status/latency/tokens/search counts/pricing/cost
avm_v3_csv_domain_scores	4	Parsed link-score rows and breakdown JSON
avm_v3_csv_imports	51	Upload progress, validation and summary
avm_v3_model_pricing	4	Versioned price components/cost-source policy
avm_v3_pdf_exports	85	Generated PDF metadata and snapshot/link IDs
avm_v3_provider_balance_snapshots	0	Provisioned balance schema; no live sync established
avm_v3_provider_budgets	0	Optional provider cost hard-stop periods
avm_v3_provider_cache	0	Generic cache schema; active reuse mainly uses results
avm_v3_provider_models	4	Usage/model metadata; incomplete provider coverage
avm_v3_provider_queries	8,148	Entity/query mentions, position, citation and authority
avm_v3_provider_results	347	Base scores, raw/normalized output and metadata
avm_v3_public_report_links	253	Modern bearer tokens, snapshot/report identity/validity
avm_v3_public_shares	21	Separate legacy/live-data share links
avm_v3_report_snapshots	71	Frozen HTML/PDF HTML/JSON/hash/context
avm_v3_runs	604	Brand/topic/market/competitors and progress
avm_v3_site_visits	0	Visitor schema; no active tracker caller identified
avm_v3_usage_rollups_daily	0	Daily aggregates; rollup script exists
avm_v3_vem_inputs	185	Entity/readiness inputs and source hashes
avm_v3_vem_results	112	Six pillars, final VEM, narrative and parent input

No customer/account, plan, subscription, payment or invoice table exists in this SQL. Do not repurpose avm_admin_users as the customer table without an explicit access-model change; a separate minimal customer extension is safer.

Database Relationships

1 Enforced foreign keys

Child	Parent	On delete
avm_v3_advanced_vem_results.vem_result_id	avm_v3_vem_results.id	CASCADE
avm_v3_api_routes.model_id	avm_v3_provider_models.id	CASCADE
avm_v3_api_usage_logs.model_id	avm_v3_provider_models.id	SET NULL
avm_v3_api_usage_logs.pricing_id	avm_v3_model_pricing.id	SET NULL
avm_v3_model_pricing.model_id	avm_v3_provider_models.id	CASCADE
avm_v3_csv_domain_scores.import_id	avm_v3_csv_imports.id	CASCADE
avm_v3_vem_results.vem_input_id	avm_v3_vem_inputs.id	CASCADE

2 Application relationships

· avm_v3_runs

· ..< avm_v3_provider_results ..< avm_v3_provider_queries

· ..< avm_v3_advanced_insights (run_id + provider_key)

· ..< avm_v3_vem_inputs

· –< avm_v3_vem_results

· –< avm_v3_advanced_vem_results

· ..< avm_v3_report_snapshots ..< avm_v3_public_report_links

· ..< avm_v3_pdf_exports >.. public_report_links

· ..< avm_v3_public_shares (separate sharing system)

· ..> avm_v3_csv_imports –< avm_v3_csv_domain_scores

· avm_api_providers

· ..< avm_v3_provider_models –< avm_v3_model_pricing

· –< avm_v3_api_usage_logs >– model_pricing

· ..< avm_v3_api_usage_logs

· ..< provider_budgets / balance_snapshots / daily rollups

· –< = enforced FK as listed; ..< / ..> = application linkage

Run-to-CSV linkage follows the selected import ID on the run, with compatibility fallbacks in some readers. A field named run_id is not automatically an FK. Provider keys are application identities, not enforced references to the provider configuration table. Before adding constraints, reconcile types/charsets, define retention/deletion behavior, detect orphans and deploy migrations outside request execution.

AI Provider Architecture

1 Snapshot configuration versus execution

Key	Enabled	Weight	Stored model	Stored API URL
openai	Yes	1.00	gpt-5.4-mini	https://api.openai.com/v1/responses
xai	Yes	0.90	grok-4.5	https://api.x.ai/v1/responses
claude	Yes	0.95	claude-sonnet-4-6	https://api.anthropic.com/v1/messages
perplexity	Yes	1.15	sonar-pro	https://api.perplexity.ai/v1/sonar
serp	No	1.20	google	https://serpapi.com/search.json
blended	Virtual	Source weights	No model	No external endpoint

These are exact uploaded values, not independently verified vendor availability. Perplexity base AVM actually calls /search and records executed mode perplexity-search, rather than using Sonar completion. Downstream code uses the configured /v1/sonar; it was not silently replaced with a more familiar endpoint or live-tested.

All stored providers have timeout 120 and maximum output tokens 12,000, but stage implementations override/clamp them. All have stored status healthy; SERP is disabled through is_enabled=0. These flags are not continuous health monitoring.

2 Selection and isolation

Root ProviderRepository filters enabled rows by is_enabled=1 and status not disabled, ordering by weight. ProviderFactoryService::make() instantiates external providers. ProviderCapabilityService distinguishes four full-stage AI providers, base-only SERP and aggregate-only Blended.

A separate ProviderFactoryService::getEnabledProviders() query orders by priority, which is absent from avm_api_providers; its exception path returns an empty list. The active list endpoint uses the repository instead. This is an alternative-path compatibility issue, not proof that current buttons all fail.

Isolation uses provider_key, ProviderIdentity, browser provider state and modern context hashes/parent IDs. It is not uniform: OpenAI’s generic Advanced AVM context loader retrieves all provider results for the run, unlike dedicated xAI/Claude/Perplexity context repositories. Cached/disabled-provider behavior must therefore be evaluated per route.

Complete AI API Integration Details

1 Shared flow and contracts

Browser -> local PHP validation -> effective provider configuration -> vendor payload -> HTTP response -> envelope/text extraction -> structured validation/evidence audit -> common scoring -> repository persistence -> provider-stamped local JSON -> UI. A successful HTTP response alone does not establish valid analysis. Modern validators check canonical entities, required fields and source evidence.

Payloads below describe implemented shapes, not runnable requests with secrets. Provider raw/debug responses can contain private inputs and must be treated as sensitive. The Endpoint Register supplies exact local input keys and function/source anchors.

2 OpenAI

services/OpenAIProviderService.php::analyze:29 loads enabled OpenAI configuration and sends Bearer-authenticated Responses requests. Base payload: model, instructions, prompt-string input, tools:[{type:’web_search’,search_context_size:’medium’}], max_output_tokens:6000. It extracts output_text or output text segments, parses JSON and normalizes the AVM shape. One invalid-JSON repair call is available without repeating research search.

HttpClientService uses a 5-second connect timeout, configured total timeout, TLS verification, gzip/HTTP2 and redirect following. It is not the newer provider retry client. Base OpenAI writes legacy and modern usage ledgers; do not sum them as independent spend.

Advanced AVM uses AdvancedInsightService::generate:25: completed cache unless forced, mark processing, load context, prompt, call, parse/repair, save. Payload uses two role messages in input, text.format.type=’json_object’ and output cap 8,000; no web search. Direct cURL in postOpenAI:218 uses connect 20 seconds and total 180. One model-assisted repair is allowed. Errors can expose the underlying message. Its generic context includes all provider results and schema-adaptive queries, weaker isolation than modern dedicated context repositories.

OpenAI VEM/Advanced VEM are inside api/run_vem.php / api/run_advanced_vem.php, not an invented OpenAI VEM class. They send prompt messages to Responses with JSON-object formatting, no search tool and no explicit stage output-token cap in those payloads. VEM saves input and uses the common parser/scorer. Advanced VEM requires successful OpenAI VEM and stores its parent ID. The active VEM prompt receives an empty CSV-row array, although existing base context may already reflect CSV support.

Accounting gap: modern logging is not wired consistently through the three OpenAI downstream stages. All 174 OpenAI modern usage rows in the dump are base avm_score, despite saved downstream outputs. That ledger is not complete subscription metering.

3 xAI / Grok

Files: XAIProviderService, XAIProviderRuntime, XAIHttpClientService, XAIAvmSchemaService, dedicated downstream services/context repositories, XAIUsageLoggerService, XAIBudgetGuardService (all under services/ except repositories).

XAI_API_KEY overrides the stored key; model/endpoint hooks include XAI_MODEL and XAI_RESPONSES_ENDPOINT. Runtime validates approved HTTPS host/path and Grok-4-family configuration; additional allowed hosts are explicit. Authentication is Bearer. Base Responses uses strict JSON schema and web search, low reasoning, store:false, stage/model/schema cache keys and bounded output/tool counts. Tool calls derive from entity count and clamp 12-36; base output clamps 4,000-30,000. Validation checks entity coverage, minimum query rows and search/citation evidence.

Advanced AVM/VEM/Advanced VEM use role-based input and text.format:{type:’json_schema’,name,schema,strict:true} over saved context, without new web research tools. Entity-dependent downstream caps are approximately 5,000-7,200 for Advanced AVM, 3,800-5,600 for VEM and 5,000-7,200 for Advanced VEM, subject to provider ceilings.

The client retries selected transient network failures and HTTP 408/429/500/502/503/504, honors Retry-After where possible and enforces an overall deadline. Default retries are bounded; downstream calls can request fewer. Runtime request timeout clamps 45-300 seconds; overall policy defaults around 210 seconds unless overridden. Locks and source/input hashes reduce duplicate/stale work. Advanced AVM’s early completed-cache shortcut is less strict than Claude/Perplexity source-first validation and needs testing after base regeneration.

All four stages log modern usage and apply optional provider budgets. Provider-reported cost is preferred where configured, otherwise stored pricing estimates apply. These are provider budgets, not customer limits.

4 Claude / Anthropic

Files include ClaudeProviderService, ClaudeProviderRuntime, ClaudeHttpClientService, ClaudeSseMessageAccumulator, research/synthesis prompt/schema/validator/evidence-audit classes, downstream services, usage logger and budget guard.

Keys prefer CLAUDE_API_KEY / ANTHROPIC_API_KEY; general/stage model overrides precede stored settings. Approved Anthropic Messages HTTPS requests use x-api-key and anthropic-version (default 2023-06-01). Stored model is claude-sonnet-4-6.

Base AVM has research then structured synthesis. Research uses Messages web search with server-side streaming and bounded continuation handling for pause_turn/output limits. Default search-tool version is web_search_20250305, with recognized configurable alternatives and compatibility fallbacks. Synthesis produces canonical entity/query output; ClaudeAvmEvidenceAuditService reconciles domains/ranks and can downgrade unsupported mentions before common scoring.

SSE is accumulated in PHP; the browser gets final JSON, not a live token stream. The client avoids blind retries after tool activity where a disconnect could hide billable completed work. Runtime has request/overall/idle-SSE deadlines; effort defaults low unless permitted overrides change it.

Advanced AVM has structured core plus narrative assembly without another search phase. VEM is a structured context-based call. Current Advanced VEM is a one-pass typed-output fast path, with schema-compatibility and compact/output-limit retries, not an older multi-phase design found in comments/backups. ClaudeAdvancedVemService:130-248 records one logical phase plus attempt counts. Canonical reconciliation can fill missing material from parent context; it is not fresh independent evidence.

All stages are instrumented. Prompt caching and combined token/search counts are normalized by provider-specific loggers; they should not be assumed identical to OpenAI usage fields.

5 Perplexity

Files: PerplexityProviderService, runtime/client, evidence auditor/validators, dedicated downstream prompts/schemas/services/context repositories, usage logger and budget guard. PERPLEXITY_API_KEY overrides stored credentials; endpoint/model/output/time/search hooks are indexed in the atlas. Authentication is Bearer; runtime distinguishes approved Search and Sonar endpoints.

Base AVM builds canonical queries, deduplicates tasks and executes them sequentially at https://api.perplexity.ai/search. Payload: query, max_results, search_context_size, optional search_language_filter:[code], optional country (PerplexityProviderService:244-262). Response requires a results array; an empty list is valid non-presence evidence. Server-side auditing converts ranked results into query signals. Executed mode is perplexity-search; stored sonar-pro remains for downstream configuration.

Advanced AVM/VEM/Advanced VEM call the configured https://api.perplexity.ai/v1/sonar. Payload: model, role-based messages, max_tokens, temperature:0.05, top_p:0.9, stream:false, disable_search:true, JSON-schema response_format. Unsupported formatting can fall back to schema instructions while search remains disabled. Parse choices[0].message.content, validate/reconcile and persist same-provider context.

Stage/entity caps: Advanced AVM approximately 6,500-10,000; VEM 4,300-7,600; Advanced VEM 5,600-10,000, subject to ceilings. Retries default 2, capped 3. Request/overall settings clamp to runtime bounds, and the HTTP client has its own single-call overall cap; these controls are not interchangeable.

Cost caveat: no Perplexity model/pricing row exists in the dump. All 57 usage rows have null model_id; 40 base Search rows show zero final cost. Zero means missing/unpriced accounting, not proof of free Search. Some downstream provider-reported costs exist. The rollup’s model constraint can omit unmodelled usage.

6 SERP / SerpAPI

SERPProviderService::analyze:7 sends GET requests to the configured SerpAPI URL with engine=google, q, api_key, num=10, hl and gl. Five patterns per entity cover branded topical, best companies, top service providers, comparison with the main brand and how-to-choose queries. Execution is sequential. organic_results titles/snippets/links/ranks become normalized visibility evidence before common scoring.

Only base AVM is supported. The export disables SERP and has no saved SERP result/modern usage rows. Do not assume advanced/VEM support, modern cost logging or budget enforcement. The key appears in GET parameters, so URL logs are sensitive.

7 Local output contracts

Base persistence contains provider identity, five dimensions, final score, normalized/raw JSON, queries, status and metadata. Advanced AVM exposes advanced_insights; VEM exposes parsed pillars/narrative and source identifiers; Advanced VEM exposes sections linked to a parent VEM. The vendor envelope is not the frontend contract. Do not relabel one provider while retaining another provider’s payload.

CSV Import and AVM Support

1 Actual format and upload

The active template generated below the old commented block in api/download_csv_template.php is AVM_SEO_Link_Data_Template.csv. Exact columns:

PR_links,Guest_Post_links,Backlinks,Citation_Links

This is not the older numeric PR/DA/PA/traffic format implied by retained fields/history. Domain is not a required template column. Cells contain URLs; pipes are recommended, with other separators/whitespace accepted. Empty/NA-like markers are removed. URLs are normalized/validated and duplicates removed case-insensitively.

api/upload_csv.php accepts seo_csv, validates upload status, extension, nonempty size and maximum 10 MB, assigns a random filename under storage/csv-imports/ and invokes CsvSeoImportService. No modern private API guard is applied to this route. Account ownership and storage/request quotas are required before commercial access.

2 Parsing and score calculation

CsvSeoImportService::processFilePath normalizes header aliases, requires all four categories, reads rows, records errors and removes duplicate row signatures. SeoCsvScorerService uses weights PR .30, guest .25, backlinks .25, citations .20; count caps 10/25/150/75:

normalized = clamp(100 * log10(count+1) / log10(cap+1), 0, 100)

Available-category weights are renormalized. Authority support uses local domain-tier rules, not a Moz/Ahrefs/live authority API. Diversity is 45% unique-domain ratio plus 55% logarithmic unique-domain coverage with a 30-domain reference cap. Final row score is 75% category base, 15% local domain authority and 10% diversity. Import summaries additionally use aggregate counts/completeness and different caps; row and import formulas are distinct.

Confirmed defect: global deduplication follows initial row scoring. Counts/domains can change without recalculating the stored score. An offline fixture reduced a row from 2 links to 1 while its score stayed 47.39. Recompute after final deduplication in a future fix; no code was changed here.

3 Schema compatibility

CsvSeoImportService:212-222 passes file_name/file_path; insertDynamic:658 filters names against schema but does not translate them. The SQL instead requires original_filename and provides optional stored_filename. Strict SQL mode can reject the missing required filename; permissive mode can lose metadata. Actual web-connection SQL mode was not established. File movement precedes DB persistence, so errors can leave orphan uploads.

CsvSeoContextService reads breakdown_json, while the supplied row table stores score_breakdown_json, potentially losing detailed breakdown context. Historical completed imports do not prove current source/schema compatibility. A zero-valid-row edge case also returns a success envelope while the import status is failed; consumers must inspect status and valid-row count.

4 AVM impact

CsvAvmScoreBlendService computes 80% AI AVM + 20% CSV support when available. It also adjusts citation 85/15, authority 80/20, consistency 92/8 and confidence 90/10 against corresponding CSV support. Presence and position remain unchanged. This is post-score support, not replacement query evidence.

CSV labels differ from base: <=5 Invisible; <=20 Very Poor; <=30 Poor; <=40 Emerging; <=50 Developing; <=60 Average; <=70 Good; <=80 Better; <=90 Excellent; otherwise Dominant. Display and report logic must preserve the saved algorithm/label until deliberately unified.

Reports and Snapshot Data

Three active comprehensive snapshot types exist: AVM includes base and Advanced AVM; VEM includes VEM and Advanced VEM; Full includes all four. Four analytical modules do not imply four separate modern PDF engines.

Report	Creation	Required sources	Public/storage path
avm_full	create_avm_public_share.php; results capture	Successful same-provider AVM + Advanced AVM; current blend where relevant	snapshot/link tables; share-avm-report.php
vem_full	create_vem_public_share.php; VemSnapshotService	VEM + Advanced VEM with matching parent ID	snapshot/link tables; root VEM wrapper -> public/vem-report.php
full_report	create_full_report_public_share.php; FullReportSnapshotService	All four, same provider, current parent/blend	snapshot/link tables; full-report.php
Legacy live share	create_public_share_link.php	vem or full_report availability	public_shares; public/share-report.php
Legacy advanced link	create_advanced_share_link.php	Advanced record/public fields	Incompatible with modern AVM token contract

Capture includes public HTML, PDF HTML, structured JSON, provider/run identity and source references. VEM/full sanitize and validate substantive sections. Full capture retains explicit module/CSV context; unresolved source rows are not treated as verified data.

Snapshots preserve creation-time content. Legacy public_shares instead reads live records, so regeneration can alter an existing legacy report. Migration/deprecation must distinguish those semantics.

PDF Generation

All three selected exports use Dompdf, not retained browser automation.

Export	Builder	Runtime behavior
public/export-avm-pdf.php	AvmDompdfExportService + AvmPdfReportBuilderService	A4, DejaVu Sans, HTML5/font subsetting, project chroot, remote resources enabled; output directory must already be writable
public/export-vem-pdf.php	VemAdvancedReportRenderer + VemPremiumPdfRenderer	A4, 1 GB / 300-second limits; remote/JS/PHP disabled; creates output/temp/font dirs; random suffix
public/export-full-report-pdf.php	FullReportPdfBuilderService	Similar limits/security; minimum HTML/PDF size checks; random suffix; request-triggered old full-PDF cleanup

Handlers validate token/type/provider/run, retrieve snapshot, build PDF HTML, save avm_v3_pdf_exports metadata and stream an attachment. VEM/full verify versioned snapshot hashes; modern AVM does not apply equivalent content-hash verification despite storing a hash.

AVM filenames use provider/run/time without the random suffix used elsewhere, creating potential same-second collisions. AVM metadata can point to denied storage URLs although streamed download works. These are separate concurrency/metadata issues.

services/PdfExportService.php, scripts/export-avm-pdf.sh and scripts/puppeteer-pdf.js are not selected by active exports. The retained generic service disables TLS verification for HTML fetch, a dormant risk rather than current VEM/full behavior. The shell script has a hosting-specific Chrome path and is not portable deployment configuration.

Requires verification: actual worker limits, permissions, fonts, images, long-report pagination and simultaneous exports. Syntax checks do not establish PDF rendering correctness.

results.php?run_id=… is private. A modern public link uses a bearer token to retrieve a snapshot without the shared private gate. Anyone with an active token can view it; public sharing is URL possession, not a recipient login.

Modern creation uses 32 random bytes encoded as 64 hex characters. Handlers validate shape and query avm_v3_public_report_links with active/expiry/report-type conditions, then validate snapshot/run/provider. Null expiry is common; expiry support does not mean automatic expiration. AVM creation deactivates earlier same-run/provider/type links in its transaction; preserve each report service’s behavior rather than assuming universal rotation.

VEM/full have versioned integrity checks. Hashes detect changes under their canonicalization; they do not prove client HTML originally matched every server score. Server-rendered critical numeric claims remain a recommended improvement. VEM/full prefer authoritative stored JSON, with legacy compatibility fallbacks.

Confirmed sanitizer weakness: AVM accepts large captured HTML/JSON and minimum-length/provider checks, but the public regex sanitizer retains event attributes and javascript: links. A pure-function test confirmed retention without executing a browser exploit. The page supplies no compensating CSP. VEM/full use dedicated DOM sanitizers and stricter headers; their runtime still requires testing.

Legacy inconsistencies: create_advanced_share_link.php creates 48 hex characters in advanced_insights but links to modern share-avm-report.php, which expects a 64-128-character snapshot token. create_vem_share_link.php points to absent public/share-vem-report.php and is OpenAI-oriented. Both creators lack the modern guard and should not be reused for paid reporting.

Modern copy/social controls follow successful link creation; they add no permission. No dedicated admin revocation UI was identified, though active flags/deactivation methods exist. Avoid logging bearer tokens or sharing private report contents in general tickets.

Admin Panel

Path	Purpose / actions	Main data
admin/login.php	CSRF-protected sign-in, password verification, session regeneration	avm_admin_users
admin/logout.php	Clear session/cookie and redirect	Admin session
admin/dashboard.php	Overview and metrics interface	Metrics API/provider/usage data
admin/providers.php	Edit endpoint/model/key/flags/weight/limits/timeouts/output	avm_api_providers
admin/token-analytics.php	Token/cost/provider/model analytics	Modern usage and pricing/model metadata
admin/usage-logs.php	Filtered request inspection	Modern usage/provider/model tables
admin/api/dashboard_metrics.php	JSON metrics	Usage/provider/visit-related tables
admin/api/export_usage_csv.php	Authenticated filtered usage export	Modern usage with provider/model joins
admin/api/jobs/rollup_usage_daily.php	Rebuild recent daily aggregates	usage logs -> usage_rollups_daily

Provider editing validates URL/key format and numeric bounds, protects changes with CSRF, and retains the existing key when replacement is blank. Enable/status controls affect generation lookups, not deletion of stored results or exclusion from Blended.

admin/services/PricingService.php applies stored input/cached/output/reasoning/search/request/tool rate components where supplied. Four pricing rows are configuration snapshots, not verified current vendor tariffs. Perplexity coverage is missing; legacy config/provider_costs.php is a separate rate source.

No customer signup/management, subscriptions/payments, full run CRUD, report-management console, routing editor or live balance-sync UI was identified. Empty provisioned tables do not establish those features. VisitTrackerService has no active caller in the index and the visit table is empty.

The rollup script allows CLI and requires admin authentication on web requests, but has no dedicated web method/CSRF write guard. No cron registration is supplied. Its aggregate search count uses distinct runs and is not equivalent to vendor-billed search calls; model-null records also require attention.

Authentication and Authorization

1 Implemented protection

Admin login uses a prepared email lookup, active-account check, password_verify, CSRF token and session-ID regeneration. Helpers enable cookie-only/strict sessions, HttpOnly, SameSite=Lax and Secure when HTTPS is detected. Protected pages use Auth::check() for an admin user ID. The database stores password hashes, not a documented plaintext password.

PrivateAccessGate consumes config/private_access.php. Valid configured URL access issues an HMAC-protected cookie with expiry and user-agent binding, then redirects to remove the parameter. Supplied lifetime is one day despite an older thirty-day comment. A legacy fixed-signature compatibility branch precedes newer expiry logic and warrants retirement review.

ApiSecurity::protectJson() applies private-cookie, method and content-length checks plus no-cache/noindex/nosniff. Modern unsafe actions check Origin/Referer with Fetch-Metadata/X-Requested-With fallbacks. This is not customer authorization or a universal rate limiter.

2 Coverage gaps

The active api/run_openai.php lacks the newer guard. So do upload_csv.php, csv_import_status.php, run_avm.php, create_advanced_share_link.php and create_vem_share_link.php. Template download can intentionally remain public. Whether an external WAF/server blocks these routes is Not identifiable from the provided project files. No live exposure test was performed.

There is no customer account ID/ownership check on runs/imports and no customer RBAC. Shared gate access plus a run/import ID is not ownership. Provider checks protect correct provider attribution, not cross-customer confidentiality.

No application-level admin MFA, login throttling, enforced idle expiry or general request-rate limiting was identified. Stored auth timestamps do not enforce expiry by themselves. Logout is a state-changing page request; hardening it is secondary to paid-generation and report-creation boundaries.

Error Handling and Diagnostics

Failure	Actual handling	Limitation / investigation
Invalid modern request	Private/method/origin/body checks, JSON 4xx	Uneven legacy/initial coverage
Invalid run/provider	Normalization and lookup	No customer ownership
Missing key / invalid model	Runtime/service exception before call	Modern host/model checks stronger
Timeout / rate limit	Provider-specific retries/deadlines/errors	Generic OpenAI transport differs; failed can still be billable
Invalid JSON/schema	Parser/validator failure, selected repair/fallback	Common Advanced VEM can accept zero defaults
Stale/incomplete source	Modern hashes/parent IDs/capabilities	Generic OpenAI advanced context less isolated
DB failure	Exceptions, logs and newer reference-tagged JSON	Partial state/raw errors in older routes
CSV failure	Validation arrays/status/progress/error	Mapping mismatch and success/status inconsistency
Insufficient Blended sources	Skip ineligible, require at least two	No automatic fresh provider calls
Snapshot failure	Module/lineage/content/token checks	Depends on current provider/capture completeness
PDF failure	Exception/reference logs	Permissions/resources/fonts require runtime testing
Admin auth failure	Generic login failure or redirect	No discovered brute-force controls

ApiSecurity::logException() records a short reference plus exception class/message/file/line. Provider debug/raw logs also exist. Support should collect reference, run ID, provider, stage, time, HTTP status and source IDs, excluding keys/tokens/full private prompts.

A timeout is ambiguous: the provider may have processed/billed a request before the response was lost. Do not equate failed with unbilled or automatically issue unlimited free retries. The project lacks a complete durable cross-stage operation/reconciliation ledger.

Performance Architecture

Generation is synchronous PHP; browser Fetch does not create a background queue. Perplexity Search and SERP perform multiple queries sequentially. Claude research/synthesis and downstream core/narrative calls add phases. External calls dominate latency over local score arithmetic.

Modern saved-result hashes, named locks and browser in-flight controls reduce duplication. Older/OpenAI paths do not uniformly share these controls. avm_v3_provider_cache is not the main reuse mechanism. Slow calls occupy PHP workers, and proxy deadlines can expire before provider deadlines unless configured together.

Historical positive response_ms samples include failed/time-out records and possibly older implementations. They are request timings, not customer-journey benchmarks; P95 is nearest-rank.

Provider	Samples	Median	P95	Maximum
OpenAI	174	13.01 s	19.02 s	120.01 s
xAI	78	45.03 s	69.06 s	101.10 s
Claude	62	97.48 s	120.48 s	131.70 s
Perplexity	57	22.23 s	33.63 s	41.03 s

Sensitive areas: repeated schema/DESCRIBE/context lookups; large raw/full JSON and duplicate snapshot HTML; long histories; unbounded admin export; large unbundled scripts (results.js 6,758 lines, vem.js 3,740); repeated charts/DOM construction; base64 chart captures; large snapshot requests; and PDF requests allowing 1 GB/300 seconds. Query plans, production cardinalities and concurrent export load were not benchmarked.

Recommended targeted improvements: end-to-end timing, consistent cache/lock policy, per-request metadata caching, explicit retention, versioned/minified assets and concurrent PDF tests. Add indexes after measuring predicates/plans. A durable queue can wrap existing orchestration later; it is not an implemented dependency. Request-triggered PDF cleanup is not a reliable scheduled retention system.

Security Analysis and Findings

This is source-supported analysis, not a claim of a compromised live site. Severity reflects potential impact if the route/data is reachable; deployment exploitability remains to be verified.

ID / priority	Classification and finding	Evidence / recommendation
S01 High	Potential risk: paid initial OpenAI route lacks private JSON guard	api/run_openai.php; authorize before every external call
S02 High	Confirmed function weakness: AVM sanitizer retains unsafe attributes/schemes	share-avm-report.php:109; allowlisted DOM sanitizer, canonical values, CSP; review old snapshots
S03 High before SaaS	Implemented limitation: no customer ownership	Schema/run/import lookups; server-side account scope
S04 High	Potential exposure: secrets, backups and runtime artifacts packaged with app	Config/provider rows/archive; rotate secrets and clean deployment
S05 Medium	Protection incomplete: admin CSRF/modern origin checks bypassed by older routes	Endpoint guard map; central early guard
S06 Medium	Potential risk: no discovered admin throttle/MFA/idle expiry; legacy cookie path	Auth/private gate; add controls and retire compatibility
S07 Medium	Potential risk: bearer links commonly do not expire	Link repositories; define expiry/revocation/log policy
S08 Medium	Potential risk: captured HTML can differ from canonical scores	Snapshot contracts; server-render critical values/source identity
S09 Medium	Potential risk: AVM PDF remote fetch; retained generic PDF disables TLS verification	Export services; restrict origins and remove insecure dormant path before reuse
S10 Medium	Potential risk: uploads/storage exhaustion/orphan files	Upload/import; ownership, quotas, cleanup and retention
S11 Medium	Potential risk: raw private input/response/error exposure	Provider logs/legacy errors; redact/restrict/retain deliberately
S12 Medium	Potential risk: usage CSV has no formula neutralization	admin/api/export_usage_csv.php:146-147; escape dangerous leading spreadsheet characters
S13 Medium	Potential risk: incomplete metering/non-atomic budgets	Usage/budget classes; operation ledger/reservations
S14 Low-Medium	Potential risk: web rollup writer lacks method/CSRF beyond auth	Rollup script; CLI-only or protected POST
S15 Verify	Deployment-dependent: .htaccess deny/header effectiveness	Confirm server overrides and config/backup/log denial
S16 Protection	Prepared SQL/constrained internal identifiers in reviewed paths	No supported SQL-injection finding; not proof of absence
S17 Protection	Modern identity/lineage/random-token/VEM-full sanitizer controls	Preserve during refactoring; do not replace with UI-only checks

The sanitizer check inspected returned markup, not live script execution. The DOM sanitizer runtime check was skipped locally, so no runtime pass is claimed. Dependency advisory scanning was not performed; installed versions alone do not establish vulnerabilities.

Payment / Subscription Integration Architecture – Recommended Only

1 Preserve the analytical engine

Add billing and ownership around request orchestration, not inside AVM/VEM formulas. Keep provider services, result tables, identity checks and report builders. Add customer authentication and server-side entitlement/usage validation before new runs, paid stages, forced regeneration, uploads or paid exports. Admin identity remains separate.

Shared private access is not a paying customer identity. A coherent minimum is account, plan, subscription, financial transaction ledger, durable webhook receipts and usage reservations: six proposed tables in section 30. No payment functionality is implemented by this documentation.

2 Exact existing integration boundaries

Existing boundary	Proposed behavior
index.php, results.php	Customer session/account-aware reads; separate internal preview policy
api/run_openai.php	Account auth, entitlement, usage reservation, owned run, finalization
api/run_provider.php	Load by run ID + account; distinguish cache, force and local blend
api/generate_advanced_insights.php	Stage entitlement/reservation before paid call
Individual/Blended VEM endpoints	Parent ownership, feature limits, source/version-aware operation ID
Upload/status endpoints	Owned CSV imports, size/storage quotas and isolated status
Modern snapshot creation	Verify all source ownership; apply share/export plan rules
Public token GET handlers	Explicit bearer-access retention policy; not customer-cookie billing auth
All provider loggers	Stable operation ID across attempts, repairs and ambiguous failures
Admin analytics	Account/plan/operation views, separate from admin user identity

Proposed new files, not existing files: core/CustomerAuth.php, services/EntitlementService.php, services/UsageReservationService.php, services/PaymentGatewayService.php, repositories/BillingRepository.php, api/billing/create_checkout.php, api/billing/webhook.php and a CLI reconciler. A gateway interface keeps payment-vendor details outside analysis services.

3 Checkout and entitlement flow

· Account chooses plan

· -> server reads authoritative price/currency/limits/version

· -> server creates gateway checkout with idempotency key

· -> customer completes hosted payment

· -> browser return page displays pending/confirmed status

· -> signed gateway webhook arrives

· -> verify raw signature; durably record/deduplicate

· -> reconcile authoritative gateway state

· -> atomically update subscription/entitlement period

· -> subsequent AVM/VEM request checks account + quota

Never unlock solely from a browser success redirect or client-supplied amount/currency/paid flag. Prefer hosted payment collection; store gateway references/status, not card credentials. Gateway availability, taxes, recurring mandates and commercial selection require a separate business/legal decision and are not inferred from this code.

Official Stripe documentation requires unchanged raw-body signature verification with the endpoint secret. Razorpay documents raw-body HMAC-SHA256, duplicate event IDs and non-guaranteed ordering. These are future integration requirements, not existing behavior (references P1-P3 below).

4 Webhook reliability and security

Use a dedicated HTTPS endpoint without the frontend private-cookie/origin requirement; gateways do not possess browser sessions. Instead verify vendor signature, body bounds, expected merchant/environment and durable receipt. Keep test/live and webhook secrets separate.

A unique event ID prevents duplicate side effects. Recorded-but-unprocessed is not fulfilled: retain processing/attempt/error state and retry safely. When acknowledging before slow processing, durably store work first; otherwise finish the short idempotent transaction before acknowledging. Never acknowledge the only in-memory copy.

Handle late/out-of-order events with allowed transitions and current gateway-object retrieval when necessary. An old failure must not overwrite a later confirmed paid state. Bind gateway IDs to local purchase/subscription IDs, not email alone. Store gateway event time, receipt time and processing time separately in UTC.

5 Quotas, concurrency and cost

Plan features should distinguish provider base AVM, Advanced AVM, VEM, Advanced VEM, force regeneration, CSV storage and optional exports. Decide explicitly whether cached reads or local Blended calculations consume credits. Blended consumes no new external AI request and should not be recorded as one.

Before chargeable work, open a short transaction, lock the subscription/account quota boundary, count reserved plus finalized units in the window, reject exhaustion and insert an idempotent reservation. Commit before the remote call. Finalize known outcomes; reconcile ambiguous/billable timeouts instead of blindly releasing credits. Expired reservations must not be released while their work may still be in flight.

One operation ID can cover multiple paid attempts/repairs and connect customer credits to actual provider costs. First complete OpenAI downstream logging and Perplexity Search/model/pricing coverage. Provider-wide budgets cannot substitute for account quotas. Customer credit policy and internal dollar cost can differ but must be independently auditable.

6 Lifecycle and access policy

Store subscription status plus explicit entitlement/grace end. Check every protected action, not just login. A recommended scheduled reconciler complements request-time expiry; access correctness must not depend on a cron tick.

Confirmed initial/renewal payment extends access according to gateway data and purchased plan version. Failed payment should restrict new work under an explicit grace policy, not erase reports. Stripe distinguishes incomplete, active, past-due, unpaid and cancelled; active alone does not mean every historical invoice is settled (P2).

End-of-period cancellation should preserve paid access until expiry. Immediate cancellation/refund is a business policy. Record partial/full refunds as separate ledger entries linked to the original charge; track cumulative refunds and unused-credit treatment. Do not automatically erase source data or reverse incurred AI costs. Define whether existing public links survive cancellation separately.

· External references checked 19 September 2026:

· P1: Stripe, Resolve webhook signature verification errors: https://docs.stripe.com/webhooks/signature (raw body, signature and secret).

· P2: Stripe, Using webhooks with subscriptions: https://docs.stripe.com/billing/subscriptions/webhooks (subscription/payment lifecycle).

· P3: Razorpay, Validate and Test Webhooks: https://razorpay.com/docs/webhooks/validate-test/ (HMAC, duplicate IDs, ordering).

Recommended Payment Database Changes – Not Implemented

These names fit the existing prefix but do not exist in the supplied schema. Six tables suffice for an initial single-customer-account model. Organization memberships, invoices, taxes or normalized feature tables can follow explicit requirements rather than being added automatically.

Proposed table	Minimum fields/keys	Responsibility
avm_v3_accounts	BIGINT UNSIGNED PK; unique normalized email; password hash/external identity; status; timestamps	Customer ownership, not admin identity
avm_v3_plans	PK; unique code+version; name; integer minor-unit amount; CHAR(3) currency; interval; entitlements JSON; active; gateway plan reference	Versioned commercial offering
avm_v3_subscriptions	PK; account/plan FKs; gateway+unique external ID; normalized/original state; period/entitlement/grace dates; cancel flag; entitlement snapshot; reconciliation time	Access state and quota serialization boundary
avm_v3_payment_transactions	PK; account/subscription FKs; gateway/unique external transaction+type; charge/refund/adjustment; parent FK; minor-unit amount/currency/status; purchase idempotency key; times	Unified financial ledger, not duplicate payments/transactions tables
avm_v3_payment_webhook_events	PK; unique gateway/environment/event ID; type/object ID; payload hash/protected data; received/processed; status/attempt/error	Durable receipt/deduplication/reconciliation
avm_v3_usage_operations	PK/UUID; account/subscription; existing run ID with matching signed INT type; provider/stage/source hash; idempotency key; window; reserved/finalized units; status/times/outcome	Concurrency-safe quota and provider-attempt correlation

Match existing key types before adding FKs. New tables should consistently use InnoDB/utf8mb4, indexed references and UTC; choose JSON syntax for the actual MariaDB version. This is a design specification, not executable migration SQL.

Add nullable account_id to existing avm_v3_runs and avm_v3_csv_imports, index, backfill through an authorized ownership decision, then require it for new customer work. Do not infer ownership from brand, visitor IP or UA. Add nullable usage_operation_id to avm_v3_api_usage_logs; leave historical unknown ownership explicit. Reports can inherit ownership through run rather than duplicating account fields everywhere.

· NEW accounts –< subscriptions >– plans

· | |

· +–< payment_transactions –< refunds/adjustments

· +–< usage_operations ..> EXISTING runs

· | |

· +–< EXISTING api_usage_logs

· +.. results / VEM / snapshots

· NEW webhook_events ..> gateway objects / subscriptions

· EXISTING csv_imports ..> NEW accounts

Unique IDs should be scoped to gateway/environment; index usage by account/window/stage/status. Purchased plan versions or entitlement snapshots must remain stable. Add retry scheduling fields only when a durable retry mechanism exists.

Migration sequence: nullable schema, verified backfill, authenticated ownership, shadow metering, cost reconciliation, concurrent reservation tests, then enforced subscriptions and closure of legacy bypasses. An audited internal-admin override is preferable to leaving a public paid route unguarded.

Deployment Architecture

Paths indicate deployment under /avm-score-v3/ on thatware.ai, with direct PHP scripts and an admin/ subtree. Configuration, services, dependencies and runtime storage are in the archive. Exact document root, vhost, PHP-FPM pool, proxy/CDN/WAF, process manager, backup schedule and CI/CD are Not identifiable from the provided project files.

Root .htaccess denies storage URLs and adds a few headers. Its effectiveness depends on Apache-compatible processing/overrides; other servers need equivalent rules. It does not establish comprehensive denial of backups, SQL, logs, config, vendor or node_modules.

A retained shell script has a host-specific Chrome path, evidence of an alternative export setup, not an active Dompdf requirement. Node/Puppeteer is needed only if that path is intentionally supported. Active PDFs require appropriate PHP extensions, fonts and writable directories.

Recommended release procedure: isolated staging; restricted non-production secrets; locked Composer install; PHP/extension validation; sanitized/migrated separate database; configure both DB entry points and access; restrict writable storage; verify server denial rules; approved-cost provider/report smoke tests; deploy a reviewed allowlist with rollback. Do not deploy the entire backup/log-rich ZIP as a clean release.

Configuration Management

Location	Actual role	Handling
config/database.php	Application PDO credentials	Sensitive, securely deployed
admin/config/database.php	Admin PDO credentials	Deliberately synchronize environments
config/private_access.php	Access values, cookie/signing/lifetime	Sensitive; rotate and review legacy mode
config/app.php	Application settings/constants	Verify base paths for staging
config/provider_costs.php	Legacy cost rates	Separate from modern versioned pricing
avm_api_providers	Runtime provider secrets/settings	Restricted DB/admin access
provider_models / model_pricing	Accounting metadata	Complete coverage and effective prices
Provider runtime classes	Env overrides, allowed hosts and limits	Exact names/locations in atlas
AVM_PUBLIC_BASE_URL	Canonical origin/base URL where consumed	Trusted configured value behind proxies
Composer/npm lockfiles	Dependency versions	Reproducible reviewed updates

No universal env loader or secret manager is established. Values come from PHP arrays, DB rows and getenv() with provider-specific precedence. Document effective deployment settings separately without publishing secrets. Weights, enabled/status and pricing-model flags have different purposes. Output settings may be overridden by stage caps; stored daily/monthly limits are not demonstrated customer quota enforcement.

Developer Maintenance Guide

Add a provider

Start with ProviderFactoryService, ProviderCapabilityService, ProviderIdentity, root ProviderRepository, api/get_providers.php and run_provider.php. Follow modern provider patterns: runtime/host validation, HTTP client, prompts/schema, validation/evidence audit, usage logger, budget guard, stage services and source-context repositories. Add provider configuration and model/pricing metadata separately. A DB provider row alone is insufficient.

Update advanced/VEM dispatch, restoration, frontend labels/capabilities and public/PDF provider normalization. Blended inclusion needs explicit source-list/fingerprint/coverage changes. Verify same-provider parentage, cache invalidation and failure/retry behavior for every supported stage. Never copy another provider’s identity or keys into the new implementation.

Modify AVM, scoring or CSV

Inspect AVMScorerService, CsvAvmScoreBlendService, SeoCsvScorerService, RecommendationService, ResultFormatterService, provider evidence auditors and results.js display/fallback math. Change algorithm/fingerprint versions to avoid reusing old scores under new formulas. Add fixtures for zero evidence, low-presence caps, discovery boosts, citation absence, competitor order and final CSV deduplication. Unify labels only as an explicit product change.

Modify VEM / Advanced VEM

Inspect common prompt builders/parsers/scorer, provider-specific prompts/schemas/services and context repositories. Update vem.js, state restoration, snapshot canonicalizers and PDF renderers together. Preserve six-pillar weighting versus ten-section mean, provider identity and vem_result_id parentage.

Add a report

Define a new explicit report type/version. Follow modern VEM/full patterns: server prerequisites/lineage, canonical structured payload, allowlisted sanitizer, integrity version/hash, secure token lookup, snapshot transaction, public renderer, PDF builder and export audit. Define the server contract before UI capture. Do not revive broken legacy share creators as shortcuts.

Modify admin / frontend / payment

Admin changes use admin/core/Auth.php/Helpers for session and CSRF, parameterized repository SQL and existing filters. Providers and pricing are separate tables. An audit feature needs real audit writes, not only a table. New write APIs require method/CSRF controls.

Input/CSV: index.php/app.js. Base/advanced: results.php/results.js. VEM: vem.js. Provider transitions: provider-context.js and Blended scripts. Public capture: report-specific snapshot scripts. Preserve script ordering and stale-response/abort controls.

Payment must enforce account/entitlement/reservation at every server action in section 29, not just the homepage or UI. Keep customer scope, provider scope and public-token scope distinct.

Developer Onboarding Guide

Step	Objective	Files / tables
1	Establish exact release and protect secrets	Manifest, lockfiles, schema-only extract, configuration locations
2	Separate private access and admin auth	PrivateAccessGate, ApiSecurity, admin Auth/Helpers; admin_users
3	Trace initial run	index/app/run_openai/RunRepository; runs/results/queries
4	Understand provider/runtime selection	ProviderRepository/Factory/Capability/runtime; providers/models/pricing
5	Reproduce a sanitized score	AVMScorer, evidence auditors, CSV blend
6	Trace provider switching	results/provider-context JS and run_provider
7	Trace Advanced AVM	Dedicated services/prompts/context; advanced_insights
8	Trace VEM inputs and pillars	vem.js/run_vem/VEMRepository; inputs/results
9	Trace Advanced VEM parentage	Advanced services/parser; advanced_vem_results/FK
10	Understand Blended as aggregation	BlendedSourceRepository/BlendScorer/BlendedVemState
11	Review CSV incompatibilities before uploads	Import/context/scorer; CSV tables
12	Separate modern and legacy sharing	Snapshots/links versus public_shares
13	Trace active PDF exports	Three Dompdf paths, CSS and pdf_exports
14	Reconcile stage usage/cost	Loggers/PricingService/budgets; modern/legacy ledgers
15	Review findings and staging tests	Security, performance, verification ledger
16	Design payment boundaries	Account/entitlement/reservation plan in 29-30

First run the supplied pure-function harness, which uses no credentials, DB or network. Then trace a sanitized run through related records read-only. Perform provider smoke tests only in staging with explicit cost approval.

Troubleshooting Guide

Symptom	Source-supported checks	Safe response
Initial generation not access-controlled	run_openai guard gap	Mock-test then close boundary
Alternative provider list empty	Factory priority column absent	Align repository/schema contract
Model/endpoint rejected	Effective env/runtime versus admin row	Compare actual precedence/allowlist
Perplexity base cost zero	Search mode and missing pricing/model	Complete metering; not free-service assumption
OpenAI downstream costs missing	Logger integration gap	Instrument all stages/repairs
Advanced result stale/wrong source	Parent IDs/hash/provider/cached shortcut	Regenerate correct parents, preserve old snapshots
VEM disappears on tab switch	Script order/provider events/state response	Trace state before rewriting renderers
Visible Blended fails	<2 valid sources or stale parents	Complete eligible individual stages
Disabled source still blended	Source query omits enabled filter	Decide policy, version fingerprint change
CSV fails but file remains	Filename mismatch/strict mode	Align mapping and failure cleanup
CSV score/count mismatch	Deduplication after scoring	Recompute after final link set
Public VEM/full incomplete	Missing modules/parent/provider mismatch	Complete same-provider lineage before capture
Legacy share fails	Token mismatch/missing target file	Use modern snapshot path; plan migration
PDF works but stored URL fails	AVM storage URL blocked	Authorized handler URL, not direct storage
PDF resource errors	DOM/fonts/images/size/time/permissions	Long sanitized fixture and concurrency tests
Rollup omits data	No schedule/model-null/metric semantics	Reconcile raw ledger first

Do not mask failures with hardcoded scores, copied OpenAI payloads under other providers, bypassed parent checks or disabled sanitization. A visually complete report can still be substantively wrong.

Non-Technical Glossary

Term	Meaning
AVM	Project-defined score of sampled brand visibility
Advanced AVM	Strategic interpretation of base visibility evidence
VEM	Vector Entity Modelling: entity/readiness analysis, not an identified vector store
Advanced VEM	Ten-section analysis built on a successful VEM
AI provider	External model/search service supplying evidence or interpretation
Blended	Local combination of saved multi-provider results
API	Defined program-to-program request interface
Endpoint	Specific URL/PHP handler receiving a request
AJAX / Fetch	Browser requests that update without full-page submission
Frontend	Browser forms, charts, controls and reports
Backend	PHP processing, provider calls, validation and storage
PHP	Server programming language used here
Database / table	Persistent structured storage / a group of related records
Primary key	Unique record identifier
Foreign key	Database-enforced reference to another record
Logical relationship	Code-used relationship without an enforced DB constraint
Run	One brand/topic/competitor assessment container
Session	Login state, used here mainly for admin authentication
Access token	Secret granting defined access; report links are bearer tokens
API key	Secret credential for provider calls, not a share token
JSON	Structured API and saved-result data format
CSV	Text table used for categorized link imports
Snapshot	Preserved report version with data and rendered content
Hash / fingerprint	Digest used to compare input/content versions; not encryption
Webhook	Gateway-initiated payment event; future integration
Subscription	Time-bound paid access/limits; future functionality
Payment gateway	Service collecting payments and sending payment events
Idempotency	Repeating a logical operation does not duplicate side effects
Quota reservation	Allocate usage before work to prevent concurrent overspend
Cron job	Scheduled server command; rollup script exists, schedule unknown
PDO	PHP database interface used for prepared SQL
Cache	Reuse saved output when its inputs/sources remain valid
Lineage	Exact parent input/result behind a later analysis
CSRF	Another site induces an unwanted action using browser access
XSS	Untrusted content executes as page script

Complete Data Flow

Input: brand/topic/industry/country/language/competitors; optional CSV import; result-page provider; later entity/reference form. Website/domain is primarily a VEM input, not an invented homepage domain field.

Processing: normalize identity/input -> effective provider configuration -> capability/source/cache checks -> provider/search call where required -> envelope/structured parse -> evidence audit -> deterministic totals/CSV support -> source IDs/status/raw-normalized persistence -> provider-stamped response. Blended replaces external calls with saved-source aggregation.

Output: AVM score/dimensions/confidence/queries/competitors; Advanced AVM strategy; six VEM pillars; ten Advanced VEM sections; charts/tables/roadmaps; snapshot HTML; PDF binary/audit; public token. Browser fallback content needs origin/version context so it is not confused with provider evidence.

· Input -> pending/staged run -> external call

· -> valid output -> result + queries -> completed display

· -> transport/parse failure -> failed/partial state + logs

· Base -> Advanced AVM processing -> completed/failed

· VEM input -> VEM result -> parent-linked Advanced VEM

· Current same-provider modules -> snapshot -> active token

· Token -> verified/rendered report -> PDF export metadata

Status vocabularies differ by table: success, completed, processing, pending and failed are not interchangeable. Validate each module’s status and parentage, not just run existence. The atlas preserves exact status definitions.

Complete File-to-Database Mapping

The atlas gives the exhaustive direct-reference matrix and per-file SQL/function anchors. This overview emphasizes execution responsibility; services often use repositories rather than issuing SQL directly.

File/class	Reads	Writes / effect
RunRepository	runs/provider results/queries	Run lifecycle and provider/query persistence
Root ProviderRepository	providers	Selection/configuration reads
AdvancedInsightRepository	run/base/query/CSV/advanced	Processing/completed/failed Advanced AVM
Dedicated advanced context repositories	Same-provider source/CSV	Context validation; separate writer repository
VEMRepository	VEM input/result/state	VEM input/output
AdvancedVEMRepository	advanced_vem_results	Parent-linked upsert
Dedicated VEM context repositories	run/provider/advanced/VEM/CSV	Hash/lineage context, not separate provider tables
BlendedSourceRepository	weights and all source module families	Source reads; standard repos persist blends
CsvSeoImportService/CsvImportRepository	schema/import state/rows	CSV imports and scores
CsvSeoContextService	run/import/score rows	Analytical support context
ReportSnapshotRepository	snapshot/link/run context	Snapshots/links/deactivation/PDF metadata
VemSnapshotRepository	VEM/advanced/run/snapshots	VEM snapshot/link records
PublicShareRepository/generic endpoint	run/module/public_shares	Legacy live-data tokens
TokenUsageService	legacy cost config	avm_api_logs
Modern logger/tracker/UsageRepository	provider/model/pricing/budget	modern usage; selected metadata setup paths
Admin ProviderRepository	providers	Configuration updates
Admin AdminRepository	admin_users	Lookup; creation helper, not public signup
Admin metrics/export	usage/provider/model/visit	Read output
Rollup job	modern usage	daily rollups
Legacy AVMRepository/run_avm	avm_runs/avm_queries/avm_competitor_scores	Legacy tables absent from supplied SQL

Names abbreviated here refer to exact prefixed tables in section 11 and the atlas. Dynamic SQL requires manual annotations beyond regex extraction. “No direct SQL found” is not a declaration of no downstream DB effect.

Complete API-to-Database Mapping

Provider	AVM	Advanced AVM	VEM / Advanced VEM	Data / accounting
OpenAI	Implemented	Implemented	Both implemented	Shared tables; base legacy+modern usage; downstream gap
xAI	Implemented	Implemented	Both implemented	Shared keys xai; modern all-stage usage/budgets
Claude	Implemented	Implemented	Both implemented	Shared keys claude; aggregated phases/attempts
Perplexity	Search evidence	Sonar, no search	Sonar, no search	Shared keys; missing model/pricing coverage
SERP	Implemented, disabled	Unsupported	Unsupported	Base shared tables; no saved usage/results here
Blended	Local aggregate	Local aggregate	Local aggregates	Shared keys blended; no new external AI cost

Exact analysis tables: avm_v3_runs, avm_v3_provider_results, avm_v3_provider_queries, avm_v3_advanced_insights, avm_v3_vem_inputs, avm_v3_vem_results, avm_v3_advanced_vem_results. CSV uses avm_v3_csv_imports / avm_v3_csv_domain_scores. Accounting uses avm_v3_api_usage_logs, avm_v3_provider_models, avm_v3_model_pricing and optional avm_v3_provider_budgets. Sharing/PDFs use snapshot/link/export tables independently of external APIs.

There are no separate tables such as claude_results. Isolation uses keys/context/validation, not separate databases.

Final Architecture Diagram

· CUSTOMER / ANALYST ADMINISTRATOR

· | |

· shared private gate password/session/CSRF

· | |

· index.php -> app.js admin pages/APIs

· | |

· run_openai.php [guard gap] config/usage/pricing

· | |

· +————- CORE PHP —————-+

· | | |

· results.php + JS validation/identity PDO repositories

· provider UI runtimes/locks/hashes and direct SQL

· | | |

· | OpenAI Responses |

· | xAI Responses MariaDB

· | Claude Messages run/results/query

· | Perplexity Search/Sonar VEM/CSV/advanced

· | SERP (base only, disabled) usage/config

· | | |

· +—- local AVM/VEM scoring ————-+

· +—- Advanced AVM / Advanced VEM |

· +—- Blended saved-source aggregation -+

· |

· browser data/HTML/chart capture

· |

· private snapshot creation + provider/lineage checks

· |

· report_snapshots -> public_report_links (bearer token)

· |

· +–> AVM / VEM / full public HTML

· +–> Dompdf -> attachment + pdf_exports

· Separate: public_shares -> live public/share-report.php

· Retained: legacy creators/run_avm/browser-PDF scripts

· Proposed: accounts -> entitlements -> usage -> payment events

The guard gap and separate legacy paths are deliberately visible rather than presenting a uniformly protected architecture not supported by the source.

Technical Recommendations and Acceptance Criteria

Priority 0: targeted launch blockers

Protect all paid/action routes; establish customer ownership; replace the AVM sanitizer and canonicalize critical report values; remove deployment artifacts/rotate shared secrets; align CSV filename/breakdown mappings and score after deduplication; instrument all billable stages and correctly identify/price Perplexity Search. None requires framework migration.

Acceptance tests must show unauthenticated/other-account requests cannot trigger paid work or access private imports; unsafe HTML attributes/schemes are removed; CSV metadata saves under target SQL mode; deduplicated scores match counts; and every provider attempt has traceable usage, including repair/uncertain outcomes.

Priority 1: consistency

Unify lineage/cache rules, particularly generic OpenAI Advanced AVM; decide disabled-source Blended policy; version algorithms and reconcile rating ladders; deprecate broken share routes with compatibility planning; define token expiry/revocation; neutralize spreadsheet formulas; add admin throttle/idle expiry and write-job guards. Audit tables need actual writers before being advertised as an audit feature.

Acceptance: forced parent regeneration invalidates appropriate descendants only; stale responses cannot paint another tab; mismatched Advanced VEM cannot publish; insufficient blends fail without fabricated values; public/PDF values match the intended canonical snapshot.

Priority 2: operations and scale

Introduce sanitized fixtures, review/automated tests, dependency scanning, migrations, secret management, structured logs, retention and restore drills. Benchmark sequential workloads and concurrent PDFs before parallelism/queues. A future durable queue should wrap existing service contracts, not duplicate modules.

Acceptance includes recoverable ambiguous calls, deterministic snapshot rebuilding, database/report-file restore verification, bounded storage, and dashboard metrics matching SQL definitions. Enforce billing only after shadow metering reconciles reliably.

The AI Visibility Optimization Playbook

Once AVM and VEM identify the gaps, the next step is execution. The following playbook organizes the work into six connected areas: measurement, content, entity architecture, authority, technical readiness and conversion.

Phase 1: Establish a Baseline Before Optimizing

Do not begin by changing everything at once.

Start with a baseline assessment across a fixed query set. Include a mix of branded, informational, commercial, comparative and transactional queries. Select a realistic competitor set. Record the provider and market context. Save the query-level evidence.

The baseline serves two purposes. It tells you where the brand is weak, and it gives you something stable to compare after implementation.

A practical baseline should answer:

· What is the current AVM score by provider?

· What are the five dimension scores?

· What is the evidence coverage or confidence level?

· Which queries produce no brand presence?

· Which competitors dominate commercial prompts?

· Which sources are repeatedly cited?

· Which VEM pillars are weakest?

· Where are the largest entity inconsistencies?

· Which content or authority gaps appear repeatedly?

Phase 2: Fix Naming, Entity and Factual Consistency

Before adding more content, resolve contradictions.

Create a single source of truth for:

· Official organization name.

· Primary brand description.

· Service taxonomy.

· Product names.

· Founder and leadership details.

· Locations and service areas.

· Proprietary framework names.

· Credentials and awards.

· Key factual claims.

Then update the website, schema, major profiles and authoritative third-party listings.

This step is often less glamorous than publishing new content, but it can have a disproportionate impact on VEM because it reduces ambiguity.

Phase 3: Build Topic and Intent Coverage

Map the market into topic clusters rather than isolated keywords.

For an AI search optimization business, a cluster might include:

Core concept: AI search visibility.

Supporting concepts: AI visibility score, LLM visibility, ChatGPT visibility, AI citation optimization, AEO, GEO, entity optimization, AI search readiness, knowledge graph strength, semantic SEO, AI share of voice.

Commercial assets: AI visibility audit services, LLM visibility optimization services, AVM audit services, VEM audit services, AI entity optimization services.

Transactional assets: request an AI visibility assessment, get an AVM VEM audit, book an AI search readiness consultation.

Each cluster should have a clear canonical page and supporting content. Avoid creating multiple thin pages that compete for the same concept.

Phase 4: Strengthen Citation and Authority Ecosystems

AI citation optimization requires a broader view than link building.

Ask where AI systems are finding evidence about the category and which sources they trust enough to cite. Then develop a strategy to earn relevant presence within that ecosystem.

This may include:

· Digital PR around original data.

· Expert commentary in industry publications.

· Research reports.

· High-quality guest contributions.

· Partner and association profiles.

· Customer case studies.

· Product review coverage.

· Relevant directories.

· Academic or institutional collaboration where appropriate.

· Podcast, webinar and conference references that produce crawlable supporting content.

The goal is not volume. The goal is authoritative, relevant corroboration.

Phase 5: Improve Machine Readability and Technical Access

Technical readiness should make the entity easier to discover and interpret.

Review:

· Robots directives.

· XML sitemaps.

· Canonicalization.

· Structured data.

· Organization and person schema.

· Service and product relationships.

· Internal linking.

· Page rendering.

· Duplicate content.

· URL stability.

· Semantic HTML.

· Important factual page accessibility.

· AI-oriented files used by the organization.

Technical work should support the content and entity model, not exist as a separate checklist.

Phase 6: Build Commercial Proof

A brand can be educationally visible without being commercially recommendable.

Create assets that help an AI system and a human buyer understand why the company belongs in a shortlist:

· Detailed service descriptions.

· Clear differentiation.

· Case studies with measurable outcomes.

· Industry experience.

· Methodology explanations.

· Comparison pages.

· FAQs that address buying concerns.

· Transparent process descriptions.

· Expert profiles.

· Evidence of scale or specialization.

Avoid unsupported claims such as “world’s best” unless they are verifiable. AI systems can only work with the evidence available to them.

Phase 7: Strengthen the Transactional Layer

The site should explain how a user moves from interest to action.

For an AI visibility audit, explain:

· What the audit includes.

· Which AI providers are assessed.

· Whether competitor benchmarking is included.

· How query sets are selected.

· What deliverables are provided.

· How long the engagement typically takes.

· What inputs are required.

· What happens after the audit.

This information improves human conversion and gives AI systems clearer transactional context.

Phase 8: Reassess and Compare

After a meaningful implementation window, rerun the original baseline before adding new queries.

Compare:

· AVM score movement.

· Dimension changes.

· Provider-specific changes.

· Commercial query visibility.

· Transactional visibility.

· Citation-source changes.

· Competitor gap movement.

· VEM pillar improvements.

· Advanced VEM gap closure.

The purpose is not to chase short-term fluctuations. The purpose is to identify durable directional improvement.

ThatWare Case Study / Current Assessment Findings

The current ThatWare AVM/VEM draft provides a useful example of why an AI visibility framework needs both methodology accuracy and intent coverage. The page already contains substantial educational depth, but the re-optimization review identified several areas where technical precision and buyer-intent coverage can be strengthened at the same time.

The first issue is terminology consistency. AVM should be standardized as AI Visibility Metric, while VEM should be standardized as Vector Entity Modelling. Earlier language that treated VEM as an engagement metric creates a conceptual conflict with the actual six-pillar entity-readiness model. For an AI system, inconsistent terminology is not merely a copy-editing problem. It can weaken entity interpretation because the same acronym is being associated with two different meanings on the same information asset.

The second issue is methodology clarity. The AVM framework uses five core score dimensions: Presence, Citation, Authority, Consistency and Position. Confidence is important, but it is a separate coverage and evidence-strength measure rather than a sixth base dimension. Correcting that distinction improves both technical credibility and answerability when users ask how an AVM score works.

The third issue is commercial intent. The existing draft identified weaker transactional visibility, including a 38% transactional visibility finding. That does not mean the educational content is weak. It means the page has more evidence for explaining the methodology than for helping a buyer move from understanding the methodology to evaluating and requesting the service. The corrective strategy is therefore not to remove informational depth. It is to add commercial proof and transactional pathways around it.

Current finding	What it means	AVM/VEM implication	Re-optimization action
VEM naming is inconsistent in the older draft	The acronym can resolve to more than one concept	Weakens brand/entity consistency	Standardize VEM as Vector Entity Modelling throughout the page and supporting assets
AVM was described with six core dimensions in places	Confidence was mixed into the base dimensions	Creates methodology ambiguity	Present five core AVM dimensions and explain Confidence separately
Transactional visibility was identified at 38%	The page is stronger at education than conversion-oriented discovery	Limits high-intent query coverage	Add audit, assessment, pricing-context, comparison, service and CTA language naturally
Blended multi-provider methodology was under-explained	Readers may assume one AI system represents the whole market	Reduces differentiation and multi-provider context	Add a dedicated Blended AI section and provider-scope explanation
Advanced VEM depth was not clearly structured	The ten-layer model was harder to understand	Weakens knowledge-graph and GEO education	Present the ten Advanced VEM intelligence layers explicitly
Commercial proof needs more structure	Methodology alone does not answer buyer-risk questions	Reduces trust at evaluation stage	Add case studies, methodology boundaries, reporting outputs, roadmaps and audit deliverables

The practical lesson is that AI visibility optimization needs three layers working together. The first is measurement accuracy, which means the framework must be defined consistently. The second is entity and evidence quality, which gives AI systems enough reliable context to understand and support the brand. The third is intent architecture, which ensures the page can answer informational, commercial and transactional questions without forcing all three purposes into one paragraph.

For ThatWare, the strongest re-optimization path is therefore to keep the deep methodology, make the AVM/VEM definitions technically exact, expose the six VEM pillars and ten Advanced VEM layers clearly, explain Blended multi-provider visibility, and then strengthen the commercial route into an AVM + VEM audit. This creates a page that can function simultaneously as a research asset, a methodology reference, an AI-search knowledge source and a conversion page.

90-Day, 6-Month and 12-Month Roadmap

The roadmap below converts AVM and VEM findings into a staged implementation program. It separates immediate measurement and consistency work from medium-term authority building and longer-term category ownership.

A 90-Day AVM and VEM Optimization Roadmap

Days 1 to 30: Baseline, Consistency and Technical Foundations

The first month should focus on measurement and structural correctness.

Week 1: Baseline Measurement

Create the assessment scope. Select providers, markets and competitors. Build a query set that includes informational, commercial and transactional intent. Record current AVM and VEM findings.

Week 2: Entity Consistency Audit

Review organization naming, founder information, locations, product/service names, proprietary terms and structured data. Correct contradictions across the site and high-value external profiles.

Week 3: Technical AI Readiness

Audit crawlability, canonicalization, sitemaps, schema, internal linking and important machine-readable assets. Confirm that core service and entity pages are accessible and stable.

Week 4: Content and Intent Mapping

Map every priority query cluster to an existing or planned page. Identify cannibalization, missing commercial assets and missing transactional pages.

The objective of the first 30 days is not maximum content production. It is a reliable foundation.

Days 31 to 60: Content, Authority and Commercial Expansion

The second month should focus on closing visible gaps.

Weeks 5 and 6: Upgrade Core Pages

Rewrite high-value service and methodology pages so they define entities clearly, answer buyer questions and include stronger evidence. Add comparison sections, case-study references, FAQs and internal links.

Week 7: Build Authority Assets

Develop research, data, expert commentary, case studies or technical resources that can earn external citations. Begin outreach to relevant publications and partners.

Week 8: Create Commercial and Transactional Assets

Publish or improve pages for high-intent queries such as AI visibility audit services, AVM audit services, VEM audit services, AI search readiness consulting and LLM visibility assessment.

The goal of days 31 to 60 is to strengthen both the content graph and the evidence graph.

Days 61 to 90: Validation, Provider Gaps and Conversion

The third month should test whether the work is influencing the answer environment.

Week 9: Interim Reassessment

Rerun the original baseline query set. Identify which dimensions improved and which providers remain weak.

Week 10: Provider-Specific Gap Work

If a brand performs well in one provider but poorly in another, analyze the source and entity differences. Strengthen the sources or relationships most relevant to the weaker provider.

Week 11: Conversion Refinement

Improve calls to action, audit descriptions, consultation pages and proof elements. Make the transactional path easy for both users and machines to understand.

Week 12: Executive Reporting and Next-Quarter Plan

Summarize score movement, evidence changes, new citations, competitor gap movement and the next set of priorities.

A 90-day program should produce a measurable shift in readiness and evidence quality even if every visibility metric has not yet moved dramatically.

A 6-Month and 12-Month Strategy

AI visibility is not a one-quarter project. The most durable gains come from sustained improvement in entity clarity, authority and content depth.

Months 4 to 6: Build Defensibility

By month four, the organization should move from correction to defensibility.

Priorities include:

· Expanding original research and expert content.

· Building stronger third-party citation coverage.

· Creating industry-specific and use-case pages.

· Developing deeper comparison content.

· Improving knowledge graph relationships.

· Growing expert entities around important topics.

· Strengthening the commercial query portfolio.

· Standardizing measurement and reporting.

At this stage, the question is no longer “Are we visible?” It becomes “Can competitors easily displace our visibility?”

A defensible brand has multiple supporting sources, strong owned content, consistent entity relationships and repeated presence across providers.

Months 7 to 12: Build Category Association

The second half of the year should focus on becoming a recognized category reference.

This can include:

· Large-scale proprietary research.

· Annual benchmark reports.

· Original datasets.

· Industry partnerships.

· Expert roundtables.

· Technical documentation.

· Public methodology pages.

· Expanded case-study libraries.

· Cross-market localization.

· Stronger digital PR.

· Ongoing commercial content.

· Provider-specific citation gap campaigns.

The goal is to move from being one possible answer to being a recurring source of truth.

A mature 12-month program should be able to show not only score improvement but also stronger commercial discovery, broader citation diversity, improved entity consistency and reduced dependence on branded prompts.

How to Interpret AVM and VEM Scores Responsibly

Metrics become dangerous when their precision is mistaken for certainty. AVM and VEM are useful because they create structure around a complex problem, but they should be interpreted within their methodological boundaries.

AVM Is a Proprietary Diagnostic, Not an Official Provider Score

AVM is not issued by OpenAI, xAI, Anthropic, Perplexity or Google. It is a project-defined framework that transforms sampled evidence into a diagnostic assessment.

That means an AVM score should be presented as ThatWare’s AI visibility measurement, not as an official industry rating.

Provider API Behavior Is Not Identical to Consumer UI Behavior

An API or provider search endpoint can be a valuable testing environment, but it may not behave exactly like the consumer-facing product. User history, interface features, orchestration, personalization and model routing can influence real-world answers.

Use provider testing as a repeatable sample, not as a claim about every user session.

Answer Probability Is Not a Calibrated Market Probability

An answer probability metric can be useful for internal comparison, but it should not be described as if it were statistically validated across every real consumer interaction.

The responsible wording is “a methodology-based answer probability indicator,” not “the guaranteed probability of appearing in ChatGPT.”

Blended Results Are Not a Universal Market Census

Blending multiple providers improves coverage, but it does not turn a sample into the entire AI market. A blended score should be understood as a composite of the included eligible providers.

Historical Comparisons Need Version Context

Models, prompts, provider endpoints and scoring logic can change. A reliable reporting process should record assessment dates, provider identities, model identifiers where available, query sets and algorithm versions.

Without that context, a score change can be difficult to interpret.

The Score Is the Beginning of the Analysis

The most useful question after receiving a score is not “Is this good?” It is “Which evidence produced this result, and what action could improve it?”

A strong AVM/VEM report should therefore include dimension breakdowns, provider-level evidence, query-level evidence, competitor comparisons and a prioritized roadmap.

Using AVM and VEM for Different Business Models

The framework is flexible because AI visibility problems vary by business model.

B2B Services and Agencies

For agencies, consultancies and professional services firms, the most important queries are often commercial and comparative.

A B2B AVM program should test:

· Best provider queries.

· Industry-specific provider queries.

· Comparison queries.

· Problem-solution prompts.

· Location or market queries where relevant.

· Expertise and methodology questions.

VEM should focus heavily on organization-expert relationships, case studies, service taxonomy, industry proof and authoritative external references.

SaaS and Technology Companies

SaaS brands often need strong product-entity clarity.

Important relationships include product -> feature, product -> integration, product -> use case, company -> product, expert -> technical topic and product -> target audience.

Commercial AVM queries should test categories, alternatives, comparisons, pricing-oriented questions, implementation needs and enterprise suitability.

Ecommerce Brands

Ecommerce AI visibility involves category recommendations, product comparisons, reviews, attributes and availability information.

VEM should examine brand-product relationships, consistent product naming, structured data, merchant information, review ecosystems and authoritative product references.

Local and Multi-Location Businesses

Local AI search requires strong organization-location-service relationships.

Consistency across business profiles, local pages, reviews, citations and structured data becomes critical. Query sets should include city, neighborhood and near-me language where appropriate.

Healthcare and Regulated Industries

Healthcare, finance, legal and other regulated sectors require additional attention to accuracy, expertise and trust.

AI visibility should never be optimized through exaggerated claims. The entity and authority model should foreground qualified experts, transparent sources, review processes and clear limitations.

Enterprise Brands

Large enterprises often have the opposite problem from small companies: too much information and too many inconsistent sources.

VEM can be especially useful for enterprise governance because it reveals entity fragmentation across regions, divisions, sub-brands, product lines, legacy pages and corporate profiles.

AVM can then show how that fragmentation affects visibility across commercial and strategic query clusters.

A Practical Example: Diagnosing a Hypothetical AI Visibility Gap

Consider a hypothetical enterprise software company called Northstar Cloud.

Northstar ranks well for several traditional SEO keywords. Its website has strong domain authority and extensive documentation. Leadership assumes the brand will therefore perform well in AI recommendations.

An AVM assessment tells a more complicated story.

Northstar appears frequently for branded prompts and technical informational questions. However, it is absent from several commercial queries such as “best enterprise workflow automation platforms” and “workflow software for regulated teams.” A smaller competitor, Meridian Flow, appears consistently in those prompts.

The AVM breakdown shows:

· Strong presence in branded queries.

· Moderate overall presence.

· Good authority.

· Weak commercial discovery.

· Inconsistent position.

· Stronger competitor citation depth in buying-oriented prompts.

The VEM assessment explains why.

Northstar’s service and product pages use three different terms for the same workflow module. External review sites use an older product name. The organization schema does not clearly connect the parent company to the module. Leadership pages are strong, but few experts are associated with workflow automation topics. The company has excellent documentation but limited comparison content and few recent third-party articles describing the product’s enterprise use cases.

The solution is not “publish 100 more blogs.”

The roadmap focuses on:

1. Standardizing product naming across the site and external profiles.

2. Updating structured data to connect the organization, product and use cases.

3. Publishing a canonical product definition page.

4. Creating comparison pages for major alternative categories.

5. Publishing case studies for regulated enterprise use cases.

6. Launching expert-led research on workflow automation benchmarks.

7. Earning third-party coverage around the research.

8. Rerunning the commercial query set after the evidence ecosystem changes.

Three months later, Northstar may still rank similarly in Google, but its AI visibility can improve because the entity becomes easier to understand and the commercial evidence becomes stronger.

This example illustrates the core value of AVM and VEM: they help diagnose why AI visibility is weak instead of assuming that the answer is simply “more SEO.”

What AVM and VEM Are Not

Clear boundaries make the framework more credible.

AVM Is Not a Universal Industry Standard

It is a proprietary ThatWare methodology. It should be explained transparently rather than presented as an official metric adopted by every AI platform.

VEM Is Not a Vector Database

The documented implementation does not depend on a standalone vector store or embedding similarity pipeline. It is an entity modelling and readiness framework using structured context and deterministic scoring.

AVM Is Not a Replacement for Analytics

Traffic, conversions, leads, revenue, rankings and search console data still matter. AVM adds a different view of discovery.

VEM Is Not Just Schema Markup

Structured data is part of entity readiness, but VEM also considers content, authority, brand consistency, query coverage and entity relationships.

A High Score Is Not a Guarantee of Leads

Visibility creates opportunity. Conversion still depends on offer quality, pricing, positioning, user experience, trust and sales execution.

AI Search Optimization Is Not a One-Time Technical Fix

Models, competitors and source ecosystems change. Measurement and optimization need to be ongoing.

Building an AVM and VEM Reporting Dashboard

A useful dashboard should tell a story rather than display dozens of isolated numbers.

At minimum, include:

1. Overall AVM by provider.

2. Blended AVM where applicable.

3. Presence, citation, authority, consistency and position.

4. Evidence confidence or coverage.

5. Query-intent breakdown.

6. Top gaining and losing queries.

7. Competitor comparison.

8. Citation-source analysis.

9. VEM pillar scores.

10. Advanced VEM priority gaps.

11. Commercial and transactional visibility.

12. Assessment date and methodology version.

Suggested Executive View

Executives usually need three answers:

· Are we becoming more visible?

· Are we becoming more credible?

· Are we becoming more commercially discoverable?

The dashboard should therefore translate technical metrics into business implications.

Suggested Analyst View

Analysts need the evidence underneath the score:

· Query-level results.

· Provider-level outputs.

· Citation domains.

· Entity mapping.

· Content gaps.

· Source changes.

· Competitive deltas.

A dashboard that only shows the final score cannot support optimization.

Measurement Cadence: How Often Should AVM and VEM Be Reassessed?

The ideal cadence depends on how fast the category changes and how much optimization work is being performed.

For an active AI search program, a monthly or quarterly formal reassessment is usually more useful than daily score chasing.

Daily testing can reveal volatility, but it can also create noise. If teams react to every small change, they may over-optimize for temporary behavior.

A practical cadence is:

· Monthly for fast-moving AI, software or media categories.

· Quarterly for stable B2B categories.

· Before and after major launches for product or rebrand changes.

· After major technical migrations that affect crawlability or structured data.

· After major authority campaigns such as research launches or PR programs.

Keep a stable baseline query set for longitudinal comparison. New queries can be added in a separate expansion set so that historical trend lines remain meaningful.

Key Performance Indicators Beyond the AVM Score

A mature program should track more than the headline score.

Useful KPIs include:

· Non-branded AI presence rate.

· Commercial query presence rate.

· Transactional query presence rate.

· Average recommendation position.

· Citation frequency.

· Citation domain diversity.

· Authority quality of cited sources.

· Multi-provider consistency.

· Competitor share of voice.

· Number of queries where the brand is top-mentioned.

· Number of query clusters with no presence.

· VEM entity consistency score.

· AI readiness improvements completed.

· Knowledge graph relationships strengthened.

· New authoritative third-party references earned.

· Case-study coverage by industry.

· Conversion rate from AI-referred sessions where trackable.

These KPIs connect the methodology with operational progress.

Governance: Keeping AVM and VEM Accurate as the System Evolves

A methodology becomes less useful when its definitions drift. That is especially important in AI search because providers, interfaces and retrieval systems change quickly.

The first governance rule is terminology control. AVM should always be expanded as AI Visibility Metric. VEM should always be expanded as Vector Entity Modelling. Advanced AVM and Advanced VEM should inherit those definitions rather than introducing alternate meanings. Proprietary terms should have one canonical definition page that other content references.

The second rule is versioned measurement. If scoring logic, query taxonomy or provider coverage changes materially, the methodology version should change too. Historical comparisons can then be interpreted fairly. A score generated under one algorithm should not be compared casually with a score generated under a substantially different version.

The third rule is query-set governance. Maintain a stable baseline set for trend reporting and a separate exploration set for new opportunities. This prevents teams from improving the score simply by changing the questions. New commercial or transactional prompts can be added without erasing the historical benchmark.

The fourth rule is provider transparency. Reports should identify which providers were included and when the assessment was run. If a provider is unavailable or excluded, that should be visible. A blended score is meaningful only when stakeholders understand which sources contributed.

The fifth rule is evidence retention. Save enough query-level evidence to explain why a score changed. Screenshots, structured outputs, citation lists, provider identifiers and timestamps can all help analysts investigate movement. Do not rely only on the final number.

The sixth rule is claim discipline. Public pages should distinguish between observed behavior, methodology-based interpretation and universal claims. Statements such as “our sampled assessment found” are more defensible than statements such as “ChatGPT always ranks.” Likewise, answer probability should remain a methodology indicator rather than being marketed as a guaranteed consumer probability.

The seventh rule is security and confidentiality. Public methodology content should explain the conceptual framework without exposing credentials, private customer data, sensitive implementation details or unnecessary infrastructure weaknesses. An external thought-leadership article does not need to reproduce every internal engineering finding in order to demonstrate expertise.

Finally, governance should connect measurement with action. If AVM shows weak commercial discovery, the roadmap should assign an owner to commercial content and authority work. If VEM shows inconsistent entity relationships, there should be a process for correcting the website, structured data and major external profiles. If a provider-specific gap persists, the team should analyze the supporting sources rather than simply rerunning the same test.

A framework becomes strategically valuable when definitions remain stable, evidence remains traceable and optimization work can be tied back to measurable gaps.

Get an AVM + VEM AI Visibility Audit

If your organization already invests in SEO but does not know how consistently it appears across AI-assisted discovery, an AVM + VEM audit can establish the baseline.

A structured assessment can help identify:

· Your current AI visibility across selected providers.

· Presence gaps across informational, commercial and transactional queries.

· Citation and authority weaknesses.

· Competitors that dominate AI recommendations.

· Brand-entity consistency issues.

· Knowledge graph and entity relationship gaps.

· AI search readiness opportunities.

· Commercial discoverability gaps.

· GEO and LLM visibility priorities.

· A prioritized roadmap for improvement.

The objective is not to add another vanity metric to a dashboard. The objective is to understand how your brand is represented in the answer environment and what evidence needs to change if you want that representation to improve.

Request an AVM + VEM audit to measure your AI visibility, evaluate your entity foundation and build a clearer roadmap for AI search growth.

Conclusion

The rise of AI search does not mean the end of SEO. It means the definition of search visibility is expanding.

Rankings still matter. Crawlability still matters. Content quality still matters. Backlinks and authority still matter. But the discovery layer increasingly includes systems that synthesize, compare, cite and recommend. That environment requires brands to think beyond pages and keywords.

AVM and VEM provide two complementary lenses for that problem.

AVM, the AI Visibility Metric, measures how the brand appears in sampled AI discovery. It examines presence, citation, authority, consistency and position, then uses contextual logic to distinguish strong non-branded discovery from superficial branded recognition. A separate confidence layer helps analysts understand the strength of the available evidence.

VEM, Vector Entity Modelling, examines the brand foundation beneath that visibility. It evaluates whether the organization, content, authority, entity relationships, AI readiness and query coverage create a coherent machine-readable representation.

Advanced AVM adds strategic visibility intelligence. Advanced VEM adds deeper entity and GEO analysis. The Blended layer adds multi-provider context so that one model is not treated as the entire market.

The result is not a magic score. It is a measurement and decision framework.

For marketing leaders, it creates a way to answer questions that traditional SEO dashboards cannot answer alone. Are we actually being discovered inside AI answers? Are we cited for the topics that matter? Do AI systems associate us with the right category? Are competitors more visible at commercial moments? Is our entity foundation clear enough to support stronger recommendations? Are our third-party authority signals helping or hurting? Which improvements should we prioritize first?

For SEO teams, the framework connects familiar disciplines with new measurement. Technical SEO improves crawlability and machine access. Content strategy builds topical depth. Digital PR strengthens authority and citations. Structured data clarifies entity relationships. Internal linking reinforces semantic structure. Commercial pages improve buyer-intent coverage. AVM and VEM bring those activities into one analytical system.

For executives, the framework provides a more useful narrative than “AI search is important.” It creates a baseline, identifies competitive gaps and makes the work measurable.

The most important principle is simple: AI visibility should be earned through clear entities, useful content, authoritative evidence and repeatable measurement.

Brands that focus only on prompt tricks may see short-term fluctuations. Brands that strengthen their entity ecosystem, authority and buyer-intent coverage create a more durable foundation.

The next era of search will not be won by chasing every new interface. It will be won by becoming easier to understand, easier to verify, easier to cite and easier to recommend.

That is the purpose of AVM and VEM.

SUPERCHARGE YOUR ONLINE VISIBILITY! CONTACT US AND LET’S ACHIEVE EXCELLENCE TOGETHER!

Intro

Project Overview

Business Purpose and Interpretation

The Search Visibility Problem Has Changed

What Is AVM (AI Visibility Metric)?

Why AVM Is Not Traditional Rank Tracking

How the AVM Methodology Works

Step 1: Define the Assessment Context

Step 2: Collect Provider-Specific Evidence

Step 3: Normalize Brand and Competitor Signals

Step 4: Score the Five Core Dimensions

Step 5: Apply Contextual Adjustments

Step 6: Add Optional Supporting Evidence

Step 7: Compare the Brand With Competitors

Step 8: Interpret the Evidence Strategically

Provider Breakdown Summary

Breakdown & Competitor Comparison

Competitor AVM Overview

Query Test Summary

The Five Core AVM Dimensions

1. Presence: Are You Actually in the Answer?

2. Citation: Is the Brand Supported by Evidence?

3. Authority: How Trustworthy Is the Evidence Around the Brand?

4. Consistency: Does the Brand Tell the Same Story Everywhere?

5. Position: Where Does the Brand Sit in the Recommendation Structure?

Confidence Is a Separate Signal, Not a Sixth AVM Dimension

Query Taxonomy: Why Branded Visibility Is Not Enough

What Is Advanced AVM?

Advanced AVM Intelligence Summary

Query Intent Dominance Summary

Advanced AVM Competitor Summary

Discoverability

Trust

Entity Dominance

Answer Probability

Volatility

Memory

Sentiment

Market-Share Visibility and Share of Voice

What Is VEM (Vector Entity Modelling)?

VEM Score Summary

VEM Competitor Intelligence Summary

VEM Competitor Visibility Summary

Why Entity Modelling Matters in AI Search

The Six Pillars of VEM

1. Brand Clarity

2. Content Coverage

3. Authority

4. Entity Relationships

5. AI Readiness

6. Query Coverage

What Is Advanced VEM?

The 10 Advanced VEM Intelligence Layers

1. Entity Ecosystem Analysis

2. Knowledge Graph Strength

3. AI Search Readiness

4. Brand-Entity Consistency

5. Competitive Entity Gap Analysis

6. Query-Intent Coverage Analysis

7. Semantic Content Strength

8. AI Citation Probability

9. GEO Readiness

10. Strategic Roadmap

Advanced VEM Summary

Advanced VEM Competitor Summary

Advanced VEM Competitor Visibility Summary

AVM vs VEM vs Advanced AVM vs Advanced VEM

Blended Multi-Provider AI Visibility

Provider-Specific Measurement and the Importance of Scope

How AVM and VEM Work Across AI Search, AEO, GEO and LLM SEO

Commercial, Transactional and Informational Query Intelligence

Knowledge-Based Queries: Build Topic Association

Commercial Queries: Enter the Consideration Set

Transactional Queries: Make the Path to Action Explicit

Why Intent Mix Matters to AVM

How to Re-Optimize a Page Around AVM and VEM Keywords Without Keyword Stuffing

AI Search Readiness: Technical and Machine-Readable Foundations

Crawlability Still Comes First

Structured Data Should Match Visible Content