Methodology
How AiVIS Cite Ledger scores AI visibility
AiVIS Cite Ledger measures whether answer engines - ChatGPT, Perplexity, Gemini, and Claude - can parse, trust, and cite a page with confidence. Every score is grounded in observable page evidence, not heuristics or black-box models. This document explains the full scoring framework, dimension weights, validation pipeline, and the BRAG trail protocol that connects every finding to a specific crawl observation.
The scoring formula (avs-v3)
The AiVIS Cite Ledger composite score is a weighted sum of ten independent scoring families, each scored on a 0–100 scale. Weights were derived from observed citation patterns across major answer engines and reflect how heavily each signal influences whether a page gets extracted and quoted in a generated response.
Each family score is computed independently before weighting. Hard-blocker caps apply first: one hard blocker caps the composite at 79, three or more cap it at 59. Hard blockers are absent JSON-LD, absent title tag, absent H1, or AI crawlers blocked in robots.txt.
Family weights and signals (avs-v3)
| Family | Weight | Primary signals evaluated |
|---|---|---|
| Schema & Structured Data | 18% | JSON-LD presence (hard blocker if absent), schema type coverage, entity references, relationship completeness, syntax validity, multi-type schema diversity |
| Entity & Heading Signals | 14% | Single H1 presence (hard blocker if absent), H2 section structure, title-to-OG title semantic consistency, entity declaration clarity |
| Authority & E-E-A-T | 12% | Knowledge Graph entity record, SERP top-10 organic presence, featured snippet or knowledge panel ownership, external citations on-page |
| Meta Tags & Open Graph | 10% | Title tag (hard blocker if absent), meta description, OG title, OG description, OG image, HTML lang attribute |
| Content Depth | 10% | Word count ≥ 300, question-style H2 headings for snippet eligibility, TL;DR or summary block presence |
| Crawlability & Bot Access | 8% | robots.txt accessible, AI crawlers not blocked (hard blocker if blocked), llms.txt advisory file |
| Renderability & Page Speed | 8% | Page load under 3 s, LCP under 2500 ms, images present, image alt text coverage ≥ 80% |
| Citation Signal Quality | 8% | Meta description length 25–160 chars, meta/OG description consistency, TL;DR positioned at top |
| Indexability & Link Graph | 6% | Canonical URL set, internal links present, external links present, XML sitemap accessible |
| Security & Trust Signals | 6% | HTTPS canonical URL, language/hreflang targeting, zero evidence contradictions |
Why structured data and entity signals outweigh hygiene families: In generative engine pipelines, structured data provides machine-readable entity relationships that directly inform knowledge graph construction. A technically clean page with no schema is functionally opaque to extraction models. Hard blockers are enforced before weighting — a site can score A on hygiene families and still be capped at 79 if JSON-LD is absent.
Citation readiness classification
AiVIS Cite Ledger classifies citation readiness using the implemented three-band model derived from retrieval evidence. These thresholds reflect observed behavior across Perplexity, ChatGPT Browse, and Google AI Overviews - not theoretical ideals.
An alternative five-band visibility classification is also used in platform reporting: Invisible (0–29), Minimal (30–49), Found (50–69), Recognized (70–84), Prominent (85–100). Both classifications derive from the same avs-v3 composite score.
The BRAG trail protocol
BRAG is AiVIS Cite Ledger's internal evidence chain standard. Every finding in an AiVIS Cite Ledger Cite Ledger audit report must pass a four-step BRAG verification before it is surfaced as a recommendation. This prevents generic advice - the kind that applies to every site and helps none of them - from appearing alongside evidence-grounded findings.
Build from observed fields
Every finding originates from a specific crawl-observable element: a missing JSON-LD block, a duplicate H1, an absent meta description. If the finding cannot be traced to a concrete page field, it is not included in the report.
Reference explicit evidence
Each finding includes a direct excerpt or field reference from the crawled page. Teams can verify the finding independently without re-running the audit. The evidence is attached to the finding, not implied.
Audit recommendation linkage
Recommendations must map to the specific finding they address. A schema recommendation links to schema evidence. A content depth recommendation links to the content fields evaluated. No recommendation is orphaned from its finding.
Ground claims in stored outputs
Findings and scores are stored per-scan so every future audit can compare against a prior baseline. Score movement is measured against stored crawl outputs, not recalculated from memory, ensuring comparison stability across weeks and model updates.
In practice, the BRAG trail means every recommendation in an AiVIS Cite Ledger report answers three questions simultaneously: what exactly is wrong on this specific page, where is the evidence in the crawl output, and what specific change will move the score. Teams that implement fixes without this chain typically address symptoms while missing root causes.
Validation pipeline
AiVIS Cite Ledger audits run through a multi-stage validation pipeline before scores are finalized. The pipeline is designed to distinguish high-confidence findings - those grounded in directly observable page structure - from advisory findings that reflect best practice patterns but cannot be verified by crawl alone.
The optimization loop
A single audit is a diagnostic, not a solution. AiVIS Cite Ledger is designed for iterative improvement cycles where teams fix a cluster of related findings, re-audit, and measure category-level delta rather than overall score movement alone. Overall score can mask improvement in one dimension while another degrades - category tracking prevents this.
The most common optimization failure mode is fixing all technical issues first while leaving content depth and structured data untouched. Security & Trust Signals accounts for only 6% of the composite score. A page can achieve a perfect security score and still sit at 30 overall if content depth and structured data are near zero. Always prioritize dimension weight when sequencing fixes.
Score inflation warning: Adding schema markup without validating relationship completeness can produce a misleading score increase. AiVIS Cite Ledger distinguishes between schema presence (any JSON-LD block exists) and schema quality (relationships are complete, entity references are accurate, type matches page context). The schema dimension weight applies to quality, not presence.
What answer engines actually extract
AiVIS Cite Ledger scoring is grounded in the extraction behavior of retrieval-augmented generation pipelines. The implementation uses DDG/Bing retrieval, OpenAI model simulation, and multi-model simulation for higher tiers. It does not directly inspect private internal retrieval/citation decisions of ChatGPT, Perplexity, Gemini, or Claude.
Observed (what we measure):
- Retrieved source URLs and snippets from DDG/Bing
- Page structure, HTML, JSON-LD, meta tags, heading hierarchy
- Structured data completeness and validity
- Search-result evidence (SERP position, features)
- Model-generated simulation output (OpenAI, multi-model)
Not observable (what we cannot measure):
- Proprietary answer-engine ranking logic
- Private model retrieval state
- Internal citation-selection decisions
AiVIS Cite Ledger scores each extraction phase through its dimension framework. Content depth and AI readability measure extractability. Structured data and heading structure measure entity resolution quality. Meta tags, crawlability, and security & trust measure reliability and accessibility. Improving all ten scoring families together is the only reliable path to consistent citation across answer engines.
Deterministic output contract
The scoring layer is deterministic for a fixed evidence set, configuration, and scoring version. Evidence collection, external retrieval, browser rendering, and model-assisted interpretation may vary between runs.
Formal clause: The scoring layer is deterministic for a fixed evidence set, configuration, and scoring version. Evidence collection, external retrieval, browser rendering, and model-assisted interpretation may vary between runs.
Verification loop definition
- Single pass: observation only.
- Double pass: same result repeated under identical query conditions = soft confirmation.
- Cross-query confirmation: agreement across independent query intents = verified signal.
Confidence scoring logic
Confidence is derived from the citation filter's reliability score, which combines: base extractor confidence, value volatility penalty, structured-data bonus, and fix-cycle delta corrections. Output is normalized to High (≥0.80), Medium (0.55–0.79), and Low (<0.55). The four-input model described in earlier documentation is not implemented; the current system uses the deterministic citation filter at 0.98 threshold for Citation Handle issuance.
Failure modes and limits
- Entity ambiguity (brand token collides with common-language usage).
- SERP personalization variance across location/session state.
- Temporal volatility during news spikes and event windows.
- Model hallucination vs retrieval mismatch.
- Thin-source environments with low-quality or sparse source coverage.
CITE LEDGER, from BRAG evidence to citable data
BRAG (Based-Retrieval-Auditable-Grading) is the evidence protocol. CITE LEDGER is the structured record of evidence collected during an AiVIS audit, including crawl observations and citation-test context where those tests run. The deterministic citation filter evaluates evidence against stability and provenance rules. A Citation Handle is a hash-backed reference to qualifying evidence, not proof that an answer engine cited the page or a view into private model internals.
ledger_entry {
query
timestamp
result_snapshot
entity_detected
position
source_url
serp_feature
confidence_score
}
Evidence capture and validation
These stages describe how observed page data is extracted, aligned to evidence fields, and checked for source stability. Customer corrections are not represented as model training unless a separately documented training process applies.
| Phase | Input | Evidence processing | Output |
|---|---|---|---|
| Extraction | Raw DOM / HTML | Parses the captured page into observable fields such as text, headings, metadata, links, and structured data. | Captured page evidence |
| Alignment | Captured page evidence | Maps observed fields to the entity, claim, and evidence categories used by the audit; it does not generate or publish JSON-LD. | Normalized evidence fields |
| Validation | Normalized evidence fields | The deterministic citation filter evaluates evidence stability and provenance against the captured source. | Validated evidence references |
Tracing evidence to its source
For data to be citable, it must transition from subjective interpretation to objective reference. The pipeline enforces this through three layers:
Upstream, Immutable capture. The system captures the DOM snapshot (raw HTML) at the moment of extraction. This evidence is non-negotiable and forms the immutable base layer of every CITE LEDGER record. Computed CSS capture is not currently implemented.
Deterministic stability checks. The citation filter applies documented rules to evidence fields and rejects evidence that is missing, unstable, or otherwise ineligible. It does not train a classifier from audit corrections.
Downstream, evidence reference. The deterministic filter evaluates a reliability score under its configured rules. Evidence meeting the 0.98 threshold can receive a hash-backed Citation Handle linked to its source snapshot; that handle does not claim an external model cited the page.
Pipeline principles
Design constraint: The CITE LEDGER filter applies deterministic eligibility and provenance rules; it is not a generator. A Citation Handle identifies qualifying retained evidence, but does not establish that an external answer engine cited it. Findings and model-assisted interpretation must remain distinguishable in the report.
Related documentation
The AiVIS Cite Ledger Guide covers how to interpret audit output and sequence implementation. The FAQ addresses common questions about score interpretation, category grades, and optimization sequencing. The Compliance page documents data handling and crawl governance policies. Teams running the full optimization loop can track progress in Report History.