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.

Composite score formula (avs-v3)
Score = Schema & Structured Data × 0.18 + Entity & Heading Signals × 0.14 + Authority & E-E-A-T × 0.12 + Meta Tags & Open Graph × 0.10 + Content Depth × 0.10 + Crawlability & Bot Access × 0.08 + Renderability & Page Speed × 0.08 + Citation Signal Quality × 0.08 + Indexability & Link Graph × 0.06 + Security & Trust Signals × 0.06

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.

Score tiers and citation readiness

AiVIS Cite Ledger maps composite scores to five citation readiness tiers. These thresholds reflect observed behavior across Perplexity, ChatGPT Browse, and Google AI Overviews - not theoretical ideals. Pages below 50 face structural extraction barriers that content improvements alone cannot resolve.

A - Elite Consistently cited across answer engines. Strong entity clarity, complete schema, extractable answer blocks. 85–100
B - Ready Citation-ready for most queries. Minor gaps in schema relationships or content depth. Competes well. 70–84
C - Partial Parseable but deprioritized. Cited only on low-competition queries or when competitors are weaker. 50–69
D - Blocked Structural barriers present. Answer engines can reach the page but extraction confidence is low. 30–49
F - Invisible Critical failures across multiple dimensions. Not practically citable in current state. 0–29

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.

B

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.

R

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.

A

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.

G

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.

1
Crawl and extractionThe target URL is fetched and rendered. HTML structure, JSON-LD blocks, meta fields, heading hierarchy, internal link topology, and raw text content are extracted and stored as the crawl baseline for this scan.
2
Dimension scoringEach of the ten scoring families (avs-v3) is scored independently against the extracted fields. Scoring is deterministic: the same page input produces the same family scores across re-runs, enabling reliable before/after comparison.
3
Evidence mappingLow-scoring dimension items are mapped to specific crawl evidence. A heading structure score of 30 references the exact H1 and H2 fields observed, not a generic statement about heading importance.
4
AI model validation (paid tiers)Eligible tiers include a secondary pass where an AI critique model reviews content against the observed dimension scores. This surfaces advisory findings - issues the crawl can detect but cannot fully evaluate, such as whether a FAQ answer is factually complete or merely present.
5
Confidence classificationEach finding is classified as high-confidence (directly crawl-observable), medium-confidence (pattern-based), or advisory (model-evaluated). Teams should prioritize high-confidence findings first - these have the most predictable score impact.
6
Score storage and baseline commitThe composite score, dimension scores, and finding set are committed to the report history store. All future audits on the same URL compare delta against this committed baseline.

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.

Recommended cycle
Baseline audit
Fix high-confidence cluster
Re-audit
Compare category delta
Log change
Repeat

The most common optimization failure mode is fixing all technical issues first while leaving content depth and structured data untouched. Technical Trust accounts for only 15% of the composite score. A page can achieve a perfect technical trust 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. When Perplexity, ChatGPT, or Gemini answers a question using web sources, the selection and extraction process follows a predictable pattern:

Entity resolution first. The model identifies what the page is about by reading the title, H1, first paragraph, and any schema with a name or description field. Pages with ambiguous or inconsistent entity signals are assigned lower retrieval priority regardless of content quality.

Passage extraction second. The model scans for short, self-contained answer units - sentences or paragraphs that fully answer a question without requiring surrounding context. This is why direct answer blocks and FAQ-style sections outperform long narrative content in citation selection even when the narrative is higher quality.

Trust verification third. The model cross-references the source against signals that indicate authority: presence of a methodology or about page, internal links to trust documents like privacy and terms, external corroboration from other indexed sources, and schema that asserts organizational identity. Pages without these signals are cited less frequently on contested or consequential queries.

AiVIS Cite Ledger scores each of these extraction phases through its dimension framework. Content depth and AI readability measure extractability. Structured data and heading structure measure entity resolution quality. Meta tags, technical trust, 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 methodology enforces a deterministic query-layer contract: same input URL + same entity seed + same configuration produces the same query set and scoring rules. Model variance is isolated to model output generation, not to query construction or weighting.

Formal clause: All evaluations are deterministic at the query layer. Variance is isolated to model output, not system design.

Verification loop definition

Confidence scoring logic

Confidence combines four numeric inputs: frequency across queries, position stability, source authority weighting, and cross-query agreement. Output is normalized to High (>=0.80), Medium (0.55-0.79), and Low (<0.55).

Failure modes and limits

CITE LEDGER, from BRAG evidence to citable data

BRAG (Based-Retrieval-Auditable-Grading) is the evidence protocol. CITE LEDGER is the structured record each audit produces, the transformation layer that converts messy scraped content into deterministic, citable ground truth. ML in this pipeline operates as a deterministic filter: its job is to reject any scraped evidence that does not meet the structural requirements for a valid citation.

ledger_entry {
  query
  timestamp
  result_snapshot
  entity_detected
  position
  source_url
  serp_feature
  confidence_score
}

The audit-fix ML feedback loop

The ML model is trained on audit failures (where citations were rejected or incorrect) and manual fixes (human corrections to data). Each phase transforms the data closer to citation-ready state.

Phase Input ML Transformation Output
Extraction Raw DOM / HTML Denoising, ML identifies non-content elements (ads, sidebars, boilerplate) based on patterns learned from previous audit removals. Cleaned Data Packet
Alignment Cleaned Packet Semantic Mapping, ML aligns extracted text to known entity schemas found in historically successful citations. Structured JSON-LD
Validation Structured Data Hallucination Scoring, Cross-references the citation coordinates with the stable DOM anchor to confirm the data was actually observed on the page. Citable Evidence

Transforming scraped evidence into citations

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 and Computed CSS at the moment of extraction. This evidence is non-negotiable and forms the immutable base layer of every CITE LEDGER record.

ML Auditor, Stability classification. A classifier trained on citable vs. non-citable data evaluates DOM element stability. If an element's ID or class varies too much across audit logs, the ML flags it as volatile and requests a more stable anchor.

Downstream, Reliability scoring. ML generates a reliability score from 0.0 to 1.0. Only data scoring above 0.98 earns a citation handle, a unique, auditable reference that resolves back to the original rendered source.

Pipeline principles

1
Lock the upstreamThe SERP fetch → Cloudflare Render path is the only source of truth. No extraction bypasses, no manual content injection. The pipeline is deterministic from crawl to evidence.
2
Audit-integrated scoringML scoring runs after DOM stabilization but before citation finalization. Evidence that passes the reliability threshold (≥ 0.98) earns a citation handle. Evidence below the threshold is flagged as volatile and excluded from the citable record.
3
Fix-cycle trainingEvery manual correction to a citation produces a delta between the scraped value and the fixed value. That delta is fed back into the ML model to refine future extraction , turning each audit-fix cycle into a training signal.
4
Deterministic mappingEvery citation contains a unique hash that resolves back to the original rendered HTML source. The audit trail is fully reversible: from final citation handle → structured evidence → cleaned extraction → raw DOM snapshot.

Design constraint: ML in the CITE LEDGER pipeline is a deterministic filter, not a generator. Its job is to say "no" to any scraped evidence that does not perfectly align with the structure required for a valid citation. By the time data reaches the user, it is not just scraped information, it is a verified asset backed by the history of the system's audits and fixes.

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.