This document defines the controlled vocabulary for the AI Visibility Lifecycle Framework, developed by AI Visibility Architecture Group Limited. It provides authoritative definitions for terms used to describe how web content is discovered, evaluated, trusted, and surfaced by AI systems.
This vocabulary is submitted by Bernard Lynch to the AI Visibility Lifecycle Framework Community Group (https://www.w3.org/community/ai-web-visibility/) as proposed input for collaborative vocabulary development. The AIVA Terminology Index (DOI: 10.5281/zenodo.19505330) is the originating definitional authority developed and maintained by AI Visibility Architecture Group Limited.
[Status] This section describes the status of this document at the time of its publication.
This document is an author’s draft submitted by Bernard Lynch to the AI Visibility Lifecycle Framework Community Group as proposed input. It has not been adopted as a CG deliverable and does not represent the consensus of the W3C Membership or staff.
The vocabulary defined herein originates from the AIVA Terminology Index (v1.0), developed and maintained by AI Visibility Architecture Group Limited under a CC BY-NC-ND 4.0 licence. Participants contributing new or modified terms within this Community Group context do so under the W3C Community Contributor License Agreement. New material created within the CG context is governed by the W3C CLA; the originating Terminology Index remains under its original licence.
GitHub Issues (https://github.com/Bernardnz/ai-visibility-lifecycle/issues) are the preferred channel for discussion. The public mailing list (https://lists.w3.org/Archives/Public/public-ai-web-visibility/) is also available.
Version consistency notice: Version references across the broader AIVA corpus — including Zenodo papers, GitHub repository, and website — may not be fully consistent at the time of this publication. This is a known condition arising from the phased multi-platform development and publication programme and is under active remediation. This Terminology Index is the canonical definitional authority for all terms defined herein, regardless of version reference inconsistencies in companion documents.
Terminology Governance
Canonical Authority
This document is the authoritative vocabulary for the AI Visibility Architecture (AIVA) framework. All definitions contained herein are canonical. Where alternative interpretations exist in external literature, practitioner usage, or derivative works, those interpretations should defer to the definitions recorded in this index. In the event of conflict between this index and any other AIVA document, the terminology index takes precedence for definitional matters.
Controlled Vocabulary Principle
AIVA terminology is intentionally controlled. Precise, stable definitions are required to ensure that lifecycle stages, visibility classes, evidence types, and governance concepts are interpreted consistently across reporting, documentation, client engagements, and implementation work. Controlled vocabulary prevents definitional drift.
Version Governance
This index evolves under three rules:
• Addition. New terms may be introduced when the framework identifies concepts not yet covered.
• Clarification. Existing definitions may be refined to resolve ambiguity without changing substantive meaning.
• Deprecation. Terms retired from active use are not deleted — they are transferred to the Deprecation Register with reason and date.
Originating Authority
All terminology not attributed to an external standard constitutes original vocabulary developed by Bernard Lynch and AI Visibility Architecture Group Limited. This index is the originating definitional authority for all such terms. Where these terms are adopted, cited, or applied externally, this index shall be acknowledged as the source.
Introduction
[Informative] This section is informative.
AI systems increasingly determine what web content people see. Yet no shared vocabulary exists for describing how content becomes visible — or invisible — within AI discovery and response systems. Publishers, developers, platform operators, and researchers lack common reference points for evaluating, measuring, or improving AI-mediated content visibility.
Background
The AI Visibility Lifecycle Framework was developed through systematic observation of AI search behaviour across multiple platforms (Google AI, ChatGPT, Claude, Perplexity, Gemini), beginning with CV4Students.com and subsequently extended through the development of AI Visibility Architecture Group Limited, 28 published papers, the Signal-Native Papers bilateral document architecture, client implementations across multiple domains, and engagement with the IETF and W3C standards processes.
The framework is published on Zenodo (DOI: 10.5281/zenodo.18460710).
About This Vocabulary
This document defines terms in two categories:
• Core vocabulary — universal AI visibility terms available for collaborative development within the Community Group.
• AIVA Extensions [AIVA Extension] — terms specific to AIVA implementation architecture, defined and maintained solely by AI Visibility Architecture Group Limited. The CG references these terms but does not govern them.
Why New Terminology Was Needed
The AIVA framework required a purpose-built vocabulary because adjacent disciplines — SEO, web analytics, digital marketing — carried embedded assumptions about ranking, conversion, and algorithmic indexing that do not map onto how AI systems discover, process, trust, and surface digital content. The discipline needed terms grounded in direct observation of AI system behaviour, neutral with respect to prior paradigms.
Methodology
Terms emerged from the framework outward, reverse-engineered from sustained observation of how AI systems behave when encountering websites. The governing criterion for term precision is defensibility: every term must be usable in a governance or reporting context without ambiguity, without importing assumptions from other disciplines.
Adopted Standard Terms
Where established technical vocabulary from web infrastructure, structured data standards, academic publishing, external identity registries, or internet governance bodies adequately describes a concept, those terms are adopted and defined here for AIVA-specific application. In all cases of conflict, the originating standard governs general technical usage; this index governs AIVA-specific application only.
Scope
[Informative] This section is informative.
This vocabulary covers terms used to describe:
• The 11 stages of the AI Visibility Lifecycle
• Visibility classes and stage status labels
• Signal types and signal mesh architecture concepts
• Evidence, measurement, and reporting terms
• AI system behaviour: crawling, ingestion, evaluation, trust, citation
• Bot detection and AI identity terms
• Governance and operational roles within an AI visibility programme
This vocabulary does not cover:
• Traditional SEO terminology (except where explicitly contrasted)
• General web standards terminology defined elsewhere
• Platform-specific implementation details beyond general reference
Normative References
[Normative] This section is normative.
AIVA Terminology Index v1.0
DOI: 10.5281/zenodo.19505330
AI Visibility Lifecycle Framework v0.7
Lynch, B. (2026). The 11-Stage AI Visibility Lifecycle (v0.7). DOI: 10.5281/zenodo.18460710.
JSON-LD 1.1
Sporny, M. et al. (2020). JSON-LD 1.1. W3C Recommendation. https://www.w3.org/TR/json-ld11/
SKOS Reference
Miles, A. & Bechhofer, S. (2009). SKOS Simple Knowledge Organization System Reference. https://www.w3.org/TR/skos-reference/
A stage-based, observational construct that expresses where and how a digital entity is currently visible within AI discovery, comprehension, trust, and human exposure systems, based solely on observable evidence across the 11-stage AI Visibility Lifecycle.
Scope Note
The index is distributional, not scalar. It produces a visibility profile, not a score.
An 11-stage sequential framework describing the complete process by which a digital entity progresses from initial AI system discovery through to stable, exponentially scaled AI-mediated visibility.
Scope Note
Used as an explanatory framework, not a governing mechanism. Stages 1–2 are sequential gates; Stages 3–11 operate as parallel evaluation dimensions.
The three-part evidential constraint defining what counts as valid evidence of AI visibility: evidence must be observable (detectable through infrastructure signals), verifiable (confirmable through independent means), and repeatable (consistent across multiple measurement instances). Evidence failing any part of this test is not admissible as proof of AI visibility status.
Scope Note
Makes Governable Observability operational rather than philosophical. Without this standard, visibility claims cannot be distinguished from inference or estimation. Companion concept to Governable Observability — the measurement philosophy and the evidential constraint it requires form a logical pair. Published: Zenodo DOI 10.5281/zenodo.18857032.
Visibility into what can be externally observed about a digital entity’s AI system interactions, including detection of change, stability, regression, and progression.
Scope Note
What AIVA restores to human decision-makers. Distinguishes observable signals from inferred or estimated signals.
A specific technical or infrastructure report from a provider used as evidence for AI visibility assessment.
Scope Note
Examples: CloudFlare Verified Bots report, Rocket.net cache hit ratio report. The authoritative source of truth in AIVA. Distinct from estimated or inferred data.
The sole purpose of the AIVA Visibility Index: expressing the current visibility state of a digital entity, without measuring quality, predicting outcomes, or prescribing actions.
Scope Note
State Articulation constrains the interpretive scope of the index. The index describes; it does not evaluate or recommend.
The explicit definition of what can and cannot be measured in AI visibility assessment for a specific platform or context, and why. Establishes the observational ceiling and prevents overclaim in reporting.
Scope Note
The concept that governs honest AI visibility reporting. Distinct from the Measurement Boundary Document, which is the AIVA-proprietary document type that records this boundary for a specific platform. The concept is CORE vocabulary; the document type is AIVA Extension.
A governance document that explicitly defines what can be measured, what cannot be measured, and why, for a specific platform or context.
Scope Note
Prevents overclaim and ensures honest reporting. Required before producing a platform-specific Evidence Inventory.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
2. The 11 AI Visibility Lifecycle Stages
[Normative] This section is normative.
2.1 Application
Lifecycle stage terms SHALL be applied in sequence. Stages 1–2 function as sequential gates: a web entity must pass both before Stages 3–11 evaluation begins. Stages 3–11 operate as parallel evaluation dimensions — a digital entity may exhibit evidence across all 11 stages simultaneously.
2.2 Use Cases
[Informative] This subsection is informative.
• Practitioner reporting: a consistent vocabulary to describe where a site stands in AI-mediated visibility as a progression with observable milestones.
• Diagnostic assessment: named stages with defined entry criteria so diagnosis is repeatable across practitioners.
• Cross-platform observation: consistent patterns observed across Google AI, ChatGPT, Claude, Perplexity, and Gemini mapped to discrete, nameable stages.
Stage 1 of the AI Visibility Lifecycle: the process by which an AI system’s crawler first identifies and retrieves a digital entity’s content.
Scope Note
Index question: Is the entity discoverable by AI systems at all? Key evidence: bot traffic reports, verified crawler identification, user-agent analysis. Sequential gate — must be satisfied before Stage 2 begins.
Stage 2 of the AI Visibility Lifecycle: the process by which an AI system parses and transforms a digital entity’s content into machine-readable semantic form.
Scope Note
Index question: Is the entity’s content processable into machine-readable semantic form? Key evidence: cache hit ratios, response times, error rates, content delivery metrics. Sequential gate — must be satisfied before Stages 3–11 evaluation begins.
Stage 3 of the AI Visibility Lifecycle: the process by which an AI system determines the purpose, identity, and type of a digital entity.
Scope Note
Index question: Is the entity’s purpose and identity intelligible to AI systems? Key evidence: URL path analytics, content type distribution, structured data presence. Parallel evaluation dimension.
Stage 4 of the AI Visibility Lifecycle: the process by which an AI system verifies the internal coherence and self-consistency of a digital entity’s content and infrastructure.
Scope Note
Index question: Is the entity internally coherent and self-consistent? Key evidence: error rate stability, cache consistency, origin health metrics. Parallel evaluation dimension.
Stage 5 of the AI Visibility Lifecycle: the process by which an AI system validates a digital entity against external, globally trusted knowledge structures.
Scope Note
Index question: Does the entity align with external, globally trusted knowledge structures? Key evidence: historical analytics, longitudinal stability, external reference patterns, alignment with authoritative global sources. The Comprehension Barrier — approximately 30–50% of websites pass this stage. Parallel evaluation dimension.
Stage 6 of the AI Visibility Lifecycle: the process by which an AI system accumulates evidence of a digital entity’s consistent behaviour and reliability over time.
Scope Note
Index question: Is trust evidence accumulating over time? Key evidence: 30+ day performance trends, consistent crawler access patterns. Parallel evaluation dimension.
Stage 7 of the AI Visibility Lifecycle: the point at which an AI system formally marks a digital entity as eligible for use in AI-generated outputs.
Scope Note
Index question: Is the entity formally eligible for use in AI-generated outputs? Key evidence: non-regression in metrics, absence of alerts, sustained positive signals over time. The Trust Barrier — approximately 5–15% of websites pass this stage. The most significant filter in the lifecycle. Parallel evaluation dimension.
Stage 8 of the AI Visibility Lifecycle: the process by which an AI system evaluates a digital entity’s eligibility for human-facing exposure.
Scope Note
Index question: Is the entity eligible for human-facing exposure? Key evidence: external analytics required — CDN/infrastructure cannot evidence this stage. Parallel evaluation dimension.
Stage 9 of the AI Visibility Lifecycle: the process by which an AI system begins exposing a digital entity to real users in experimental or limited contexts.
Scope Note
Index question: Is the entity being tested with real users? Key evidence: external analytics required (Google Analytics, etc.). Parallel evaluation dimension.
Stage 11 of the AI Visibility Lifecycle: the state in which a digital entity’s AI-mediated visibility is expanding across scale, regions, and query families.
Scope Note
Index question: Is visibility expanding across scale, regions, and query families? Key evidence: external analytics required. The terminal stage of the lifecycle.
The abbreviated stage sequence: AI Crawling → AI Ingestion → AI Classification → AI Harmony Checks → AI Cross-Correlation → AI Trust Building → AI Trust Acceptance → Candidate Surfacing → Early Human Visibility Testing → Baseline Human Visibility → Growth Visibility.
Scope Note
Used in quick-reference contexts. Each stage name maps directly to the full lifecycle stage term.
The diagnostic question that defines the entry criterion for each lifecycle stage, used in AIVA assessments to determine the current stage of a web entity.
Scope Note
Each of the 11 lifecycle stages has a corresponding Index Question.
skos:broader
AI Visibility Lifecycle
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
3. The 11 Visibility Classes
[Normative] This section is normative.
3.1 Application
Visibility class terms SHOULD be assigned based on observable evidence across the lifecycle stages. Visibility classes provide functional grouping independent of lifecycle position — a single report may contribute evidence to multiple visibility classes simultaneously.
3.2 Use Cases
[Informative] This subsection is informative.
• Stage assessment reporting: a vocabulary to describe the observed state of a web entity’s AI-mediated visibility at a specific point in time.
• Client communication: visibility classes provide non-technical stakeholders with a stable, named reference point for their position within the lifecycle.
The complete set of visibility classes: Discovery, Semantic Availability, Identity, Internal Coherence, External Alignment, Temporal Trust, Eligibility, Competitive Readiness, Experimental Exposure, Stable Presence, Scaled Visibility.
Scope Note
Quick-reference grouping of the Visibility Classes defined in Section 3.
skos:broader
Visibility Profile
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
4. Stage Status Labels
[Normative] This section is normative.
4.1 Application
Stage status labels SHALL be assigned to describe the completion state of an individual lifecycle stage at the time of reporting. Each stage is assigned one primary status label. Status is descriptive, time-bound, and non-regulatory. Modifiers from Section 5 may be combined with status labels via the syntax: Status (modifier), e.g. Constrained (Degrading).
4.2 Use Cases
[Informative] This subsection is informative.
• Report standardisation: consistent labels ensure reports produced by different practitioners use the same terms for the same observable phenomena.
A stage status indicating that the stage shows consistent, reliable evidence over the reporting period with no significant change or degradation observed.
The complete set of stage status labels: Stable, Constrained, Residual, Inactive, Unresolved.
Scope Note
Quick-reference grouping of the Stage Status Labels defined in Section 4.
skos:broader
Stage Status Label
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
5. Behaviour Modifiers
[Normative] This section is normative.
5.1 Application
Behaviour modifiers MAY be combined with Stage Status Labels to describe directional movement. The syntax is: Status (modifier). Example combinations: Constrained (Degrading), Residual (Volatile), Stable (Improving).
5.2 Use Cases
[Informative] This subsection is informative.
• Trend reporting: vocabulary to describe not just current stage status but direction of movement — improving, degrading, or volatile — to support forward-looking recommendations.
The complete set of behaviour modifiers: Improving, Degrading, Volatile.
Scope Note
Quick-reference grouping of the Behaviour Modifiers defined in Section 5.
skos:broader
Stage Status Label
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
6. Index Column Terms
[Normative] This section is normative.
6.1 Application
Index column terms SHALL be applied consistently across all AIVA Visibility Index implementations. The index uses exactly 13–14 columns. Column definitions are fixed; only Column 11 (Observed Signal) updates regularly.
6.2 Use Cases
[Informative] This subsection is informative.
• Reporting consistency: named columns with defined semantics so index implementations produced by different practitioners can be compared and audited.
Column 12b of the AIVA Visibility Index: a brief human-readable explanation of the evidence recorded for a given lifecycle stage row.
skos:broader
Index Column Terms
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
7. Report Classification Terms
[Normative] This section is normative.
7.1 Application
Report classification terms SHALL be used to categorise AIVA reports by their intended use, audience, and admissibility in governance contexts.
7.2 Use Cases
[Informative] This subsection is informative.
• Governance documentation: distinguishing between independently admissible and context-dependent reports requires named classifications with defined governance semantics.
A report that requires configuration or integration with external systems to be available.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
PART II — Technical Infrastructure
8. Bot Detection & Identity Terms
[Normative] This section is normative.
8.1 Application
Bot detection and identity terms SHALL be used consistently when describing or reporting AI crawler activity in server logs and infrastructure monitoring.
8.2 Use Cases
[Informative] This subsection is informative.
• Bot identification: distinguishing AI crawler traffic from human traffic required named terms for specific crawler identities enabling practitioners to verify AI engagement.
• Citation failure diagnosis: when an AI system failed to cite a web entity, named behaviour terms enable identification of the specific cause.
An identity confidence level indicating that bot identity has been verified through authoritative means such as ASN verification, reverse DNS verification, or a verified bot registry.
Scope Note
Suitable for governance reporting without qualification.
An identity confidence level indicating that bot identity is suggested by behavioural analysis or signature match but has not been independently verified.
Google’s web crawler for search indexing and potentially AI training.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Bingbot
URI
https://aivisibilityarchitects.com/vocab#Bingbot
Type
noun phrase; skos:Concept
Definition
Microsoft’s web crawler for Bing search and AI services.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
9. CDN & Infrastructure Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
9.1 Application
CDN and infrastructure terms SHOULD be applied when assessing a web entity’s hosting architecture for AI visibility implications. Platform Capability Tier SHOULD be assigned based on verified bot management capability.
9.2 Use Cases
[Informative] This subsection is informative.
• Platform assessment: consistent vocabulary to describe CDN and hosting infrastructure capabilities specifically in relation to AI crawler identification and management.
9.3 Vocabulary
CDN and infrastructure terms provide vocabulary for AIVA practitioners when describing and assessing hosting architecture for AI visibility implications.
CDN (Content Delivery Network)
URI
https://aivisibilityarchitects.com/vocab#CDN
Type
noun phrase; skos:Concept
Definition
A distributed network of servers that delivers content to users based on geographic proximity.
Scope Note
Critical for Stage 2 (AI Ingestion) evidence generation. CDN-reported metrics constitute the primary evidence base for Stages 1–7.
Status
stable
Source
Adopted — general technical standard, defined here for AIVA application.
Server logs recording each HTTP request with details including IP address, user-agent string, URL path, and response status code.
Scope Note
Primary raw evidence source for Stage 1 bot identification.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
10. Evidence & Measurement Terms
[Normative] This section is normative.
10.1 Application
Evidence and measurement terms SHALL be applied when describing the observable, verifiable signals used to assess lifecycle stage position. Evidence MUST be observable and repeatable to qualify as valid stage evidence.
10.2 Use Cases
[Informative] This subsection is informative.
• Observable verification: precise terms for signals constituting valid evidence of stage completion, distinguishing genuine evidence from coincidental signals.
• Report standardisation: a shared evidence vocabulary so reports produced by different practitioners use the same terms for the same observable phenomena.
A record of verified AI visibility outcomes used to substantiate framework claims and support acquisition due diligence.
Scope Note
Enhancement #5. Declared in aiva-entity.txt.
skos:broader
Evidence Inventory
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
11. Architecture Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
11.1 Application
Architecture terms SHOULD be applied when describing the structural components of an AI-visible web entity.
11.2 Use Cases
[Informative] This subsection is informative.
• Architecture documentation: terms for the structural components that produce AI visibility signals, enabling consistent implementation documentation.
The degree to which a website’s technical infrastructure, content structure, and semantic organisation are optimised for AI comprehension and trust validation.
Scope Note
The primary determinant of timeline to AI visibility. Architectural quality — not commercial classification — determines how quickly a website progresses through the lifecycle.
An architectural quality tier characterised by weak semantic structure and significant inconsistencies, projecting 24–36+ months to Stage 9 if achievable at all.
The confidence level AI systems require before formally accepting a domain as reliable at Stage 7.
Scope Note
Varies by commercial classification — not by timeline. Commercial classification determines the height of the threshold; architectural quality determines the speed of evidence accumulation.
The property of Stages 1 and 2 of the AI Visibility Lifecycle, which must be satisfied in sequence before parallel evaluation of Stages 3–11 can begin.
Commercial components comprising less than 10–15% of total content that do not distort the primary educational or informational mission of a digital entity.
The principle that trust thresholds (what percentage of evidence is required) and progression timelines (how long advancement takes) are governed by different variables.
Scope Note
Threshold is determined by Commercial Classification; Timeline is determined by Architectural Quality. The two are independent.
The three-tier classification of website architectural quality in relation to AI visibility: Optimised (95%+ implementation, 6–12 months to Stage 11), Average (12–24 months), and Poor (24–36+ months).
Scope Note
Architectural Quality Tier is the primary determinant of lifecycle progression timeline.
The estimated percentage of AIVA-Optimised websites that successfully reach Stage 11: approximately 50–70%, compared to the 1–6% baseline for all websites.
The two lifecycle stages with the lowest passage rates: Stage 5 (AI Cross-Correlation, ~30–50% pass) and Stage 7 (AI Trust Establishment, ~5–15% pass).
Scope Note
Used to calibrate client expectations and prioritise architectural interventions.
skos:broader
Survival Rates
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
PART III — Governance and Operations
13. Governance Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
13.1 Application
Governance terms SHALL be applied consistently in AIVA governance documents, client engagements, and standards submissions.
13.2 Use Cases
[Informative] This subsection is informative.
• Governance documentation: terms with defined semantics distinguishing, for example, between the originating authority and the collaborative development forum.
The authoritative, append-only register of all retired AIVA terminology, maintained in aiva-deprecation.txt and the Document Control section of this index.
Scope Note
Entries are never removed. Each entry records the deprecated term, the replacement term, the reason for deprecation, and the version in which deprecation occurred.
skos:broader
AI Visibility Governance Boundary
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
14. Operational Roles [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
14.1 Application
Operational role terms SHALL be used to describe practitioner responsibilities within an AI visibility programme.
14.2 Use Cases
[Informative] This subsection is informative.
• Practitioner certification: named roles referenced in training materials with consistent meaning across contexts.
• Client engagement: role terms that non-technical stakeholders can understand and adopt.
Layer 1 of the AIVA operational chain: the system that produces governed AI visibility reports, enforces disciplined language, separates observation from inference, and maintains evidence integrity.
Layer 2 of the AIVA operational chain: the human professional who reads and audits AIVA reports, identifies patterns, interprets without fabricating causality, adds professional commentary, and signs off with professional responsibility.
Layer 3 of the AIVA operational chain: the decision maker who receives interpreted reports, decides what to act on, adjusts architecture and strategy, and takes organisational responsibility.
Core principle terms SHALL be cited in governance documents and client agreements to prevent methodological drift. They SHALL NOT be overridden by platform-specific implementations or client preferences.
15.2 Use Cases
[Informative] This subsection is informative.
• Framework integrity: explicitly stated, named principles cited in governance documents and client agreements to prevent methodological drift.
The principle that the AIVA Visibility Index is built from independent stage assessments with no mandatory sequence, no required completeness, no mathematical weighting, and no pass/fail outcome.
The foundational decision chain of the AIVA framework: AIVA observes → AI Visibility Architect interprets → Organisation decides.
Scope Note
Expresses the human authority principle — AI visibility data informs but does not replace human decision-making.
skos:broader
AI Visibility Human Authority Is Sovereign
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
16. AIVA Document Types [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
16.1 Application
AIVA document type terms SHALL be applied when categorising or referencing documents within the AIVA framework ecosystem.
16.2 Use Cases
[Informative] This subsection is informative.
• Document management: named document types prevent confusion between, for example, the canonical Terminology Index and derivative practitioner guides.
The operational tracking spreadsheet implementing the AIVA Visibility Index, with one row per lifecycle stage and columns as defined in the Index Column Terms.
A LOW TIER compute provider with minimal AI visibility measurement capability when used without a CDN layer.
Scope Note
LOW TIER. Cannot identify AI crawlers without CDN integration.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Linode (standalone)
URI
https://aivisibilityarchitects.com/vocab#Linode
Type
noun; skos:Concept
Definition
A LOW TIER compute provider with minimal AI visibility measurement capability when used without a CDN layer.
Scope Note
LOW TIER. Cannot identify AI crawlers without CDN integration.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
18. Platform Capability Tiers [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
18.1 Application
Platform capability tier terms SHALL be assigned based on verified bot management capability as defined in the CDN & Infrastructure Terms section.
18.2 Use Cases
[Informative] This subsection is informative.
• Infrastructure assessment: a tiered classification system to communicate platform capability levels to clients and justify infrastructure recommendations.
19. Web Infrastructure Standard Files [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
19.1 Application
Web infrastructure standard file terms SHALL be applied when describing the standard machine-readable files deployed at the website root that serve search engine crawlers, security researchers, and AI systems. These are adopted internet standards given AIVA-specific application and documented here for practitioner reference.
19.2 Use Cases
[Informative] This subsection is informative.
• Infrastructure communication: standard files that govern how crawlers, AI systems, and security tools interact with the website root, each requiring AIVA-specific configuration for optimal AI visibility outcomes.
19.3 Vocabulary
Adopted web infrastructure standards given AIVA-specific application. Source files for the AIVA Root Directory Architecture.
The crawler and AI bot access control file containing crawl directives, query parameter blocking, AI bot-specific allow/disallow rules, sitemap declarations, and AI context hints.
Scope Note
Located at the website root. AI context hints in comments point to llms.txt, llms-full.txt, aiva-entity.txt, and aiva-deprecation.txt.
A vulnerability reporting contact file following RFC 9116, located at /.well-known/security.txt, containing contact email, expiry date, and canonical URL.
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
20.1 Application
Root directory architecture terms SHALL be applied when describing the 13-file machine-communication architecture deployed at the root of AI-visible websites.
20.2 Use Cases
[Informative] This subsection is informative.
• Machine communication design: vocabulary for the specific files and architectural patterns constituting a fully deployed root directory architecture for AI systems.
20.3 Vocabulary
llms.txt
URI
https://aivisibilityarchitects.com/vocab#LLMSTxt
Type
noun phrase; skos:Concept
Definition
A lean AI orientation file placed at the website root providing AI systems with website identity, URL inventory, reading order, content classification, citation preferences, and terminology authority in plain text.
Scope Note
The index version — AI systems follow links for detail. Distinct from llms-full.txt.
The design principle that root directory files serve three distinct audiences — AI systems, search engine crawlers, and security researchers and humans — with each file optimised for its primary audience.
The layered sequence through which AI systems discover AIVA content: robots.txt → llms.txt → llms-full.txt → aiva-entity.txt → aiva-deprecation.txt → aiva-llms-sitemap.xml.
A child sitemap containing 5 core methodology URLs: homepage, lifecycle overview, architect role, white papers library, and training certification index.
A child sitemap containing 10 identity, stewardship, and legal URLs across four groups: AIVA Definition, Architectural Stewardship, Footer and Legal, and Contact and Engagement.
A child sitemap containing 17 training and certification URLs: foundation tiers, 11 sequential modules, professional certifications, and specialised courses.
21. Signal Mesh & Enhancement Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
21.1 Application
Signal mesh and enhancement terms SHOULD be applied when describing the interconnected semantic signal architecture underlying AI visibility outcomes.
21.2 Use Cases
[Informative] This subsection is informative.
• Architecture documentation: the Signal Mesh Architecture required vocabulary for its five core components and 21 enhancement types to enable consistent implementation documentation.
The structural methodology for creating interconnected semantic signals that AI systems interpret accurately, constituting the implementation layer beneath the AI Visibility Lifecycle.
Scope Note
Five core components: Primary Beacon Pages, Global Beacon Network, JSON-LD Metadata Layer, Internal Link Topology, and External Signal Reinforcement.
Component 1 of the Signal Mesh Architecture: the core pages of a website carrying the highest concentration of identity, purpose, and authority signals.
Scope Note
Architected to satisfy Stage 3 (AI Classification) and Stage 5 (AI Cross-Correlation) requirements simultaneously.
Component 4 of the Signal Mesh Architecture: the deliberate structure of internal links within a website designed to guide AI crawlers to Primary Beacon Pages and reinforce topical coherence signals.
Component 5 of the Signal Mesh Architecture: the set of signals that confirm an entity’s identity and authority from sources outside its own website.
Scope Note
Includes Wikidata entries, ORCID records, Zenodo publications, IETF Internet-Drafts, W3C Community Group participation, and third-party citations. Primary mechanism for passing Stage 5.
The formal declaration that AI Visibility Architecture Group Limited is the originating and controlling authority for all AIVA framework terminology.
Scope Note
Declared in llms.txt, llms-full.txt, each SNP provenance block, and the Terminology Governance section of this index.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
22. AI Stewardship Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
22.1 Application
AI stewardship terms SHALL be applied when describing the ethical and governance obligations of AIVA practitioners toward AI systems and the broader AI ecosystem.
22.2 Use Cases
[Informative] This subsection is informative.
• Ethical governance: as AI systems increasingly rely on web content for training and inference, practitioners needed vocabulary for describing obligations toward accurate, honest, well-structured AI-readable content.
A retained architectural governance service ensuring accurate AI interpretation of organisational identity across model updates, platform changes, and time.
Scope Note
Not SEO management, not content creation, not implementation. A long-term governance framework.
An AI Stewardship principle requiring ongoing verification that the version of a document retrieved by AI systems matches the current authoritative version.
Scope Note
Version misalignment occurs when outdated content on distribution platforms or archives is retrieved in preference to the current canonical version.
An AI Stewardship principle requiring anticipation of information changes and signal updates before inaccuracies propagate into AI system representations.
A core AI Stewardship output: strategic guidance on maintaining and improving AI visibility architecture over time.
skos:broader
AI Stewardship
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
23. Training & Certification Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
23.1 Application
Training and certification terms SHALL be applied in all AIVA training materials, certification programmes, and professional development documentation.
23.2 Use Cases
[Informative] This subsection is informative.
• Professional development: a tiered certification structure required named tiers with defined scope and learning objectives referenced consistently across training materials.
The professional certification tier requiring completion of Tier 1B and all Tier 2 modules, leading to Certified AI Visibility Architect or Certified AI Visibility Account Manager.
Scope Note
Requires examination and practical assessment in addition to module completion.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Certified AI Visibility Architect
URI
https://aivisibilityarchitects.com/vocab#CAIVA
Type
noun phrase; skos:Concept
Definition
A professional certification for practitioners licensed to use AIVA methodology for client work.
Scope Note
Requirements: Tier 1B + all Tier 2 modules + examination + practical assessment. Abbreviated as CAIVA.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Certified AI Visibility Account Manager
URI
https://aivisibilityarchitects.com/vocab#CAVAM
Type
noun phrase; skos:Concept
Definition
A professional certification for client-facing AI visibility management roles.
Scope Note
Requires designated training pathway plus client communication competency assessment. Abbreviated as CAVAM.
A bilateral document architecture that produces two simultaneous outputs from a single AIVA white paper or IP document: a human-readable expression and a machine-readable expression.
Scope Note
The SNP is not a separate document type — it is the structured output pairing that accompanies every qualifying AIVA publication.
The design principle that every SNP-compliant document exists in two parallel forms — one optimised for human reading, one optimised for machine ingestion — without either form being a subset or derivative of the other.
The machine-readable form of a Signal-Native Paper: a structured JSON file using the snp: namespace containing provenance metadata, canonical claims, authorship, versioning, and a resolution block.
Scope Note
Deployed alongside the human expression at publication. Ratification by the author is implicit — machine expressions carry no ratification field.
The JSON property namespace used in all SNP machine expressions, applied as a prefix to all SNP-specific fields to distinguish them from generic metadata vocabularies.
The section of a machine expression that declares authorship, institutional affiliation, Wikidata identifiers, ORCID, Zenodo DOI, version number, and publication date.
The multi-step process for publishing a complete SNP pair: prepare human expression → upload to Zenodo → generate machine expression → deploy to website → archive to Wayback Machine → deploy to GitHub → update resolution block with all live URLs.
Scope Note
Layer 2/3 distribution follows only after core Layer 1 provenance platforms are confirmed.
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
25.1 Application
Reporting framework terms SHALL be applied in all AIVA client reports and reporting methodology documentation.
25.2 Use Cases
[Informative] This subsection is informative.
• Report standardisation: consistent vocabulary ensures reports produced by different practitioners can be compared and audited against the same standards.
The raw observational output of the AIVA system, recording what was observed, from which reports, at which stages, during which observation window, with no interpretation, causal inference, or recommendations.
Scope Note
The evidentiary foundation of all downstream reporting.
The AI Visibility Architect’s interpretive layer added after review of the AI-Side Report, containing pattern identification, professional commentary, and qualified inferences.
Scope Note
Signed with professional responsibility. May not contradict the AI-Side Report — it adds interpretation, not replacement observation.
The complete documentation suite for SNP deployment and reporting, covering all reporting layers, provenance platform verification procedures, governance rules, and step-by-step deployment procedures.
The defined cadence at which AIVA reports are produced for a client or entity.
Scope Note
Distinct from the observation window: the reporting period is the governance schedule; the observation window is the evidence timeframe within a single report.
The canonical document defining the minimum, non-negotiable rules for constructing, interpreting, and using AIVA reports.
Scope Note
Governs observation discipline, evidence mapping, language standards, and the separation of observation from inference across all three reporting layers.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
26. Structured Data and JSON-LD Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
26.1 Application
Structured data and JSON-LD terms SHOULD be applied when describing the machine-readable metadata layer of an AI-visible web entity.
26.2 Use Cases
[Informative] This subsection is informative.
• Machine-readable implementation: vocabulary for the specific structured data patterns constituting valid AI visibility signals in JSON-LD format.
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
27.1 Application
External identity anchor terms SHALL be applied when describing the external platform registrations constituting a web entity’s provenance chain.
27.2 Use Cases
[Informative] This subsection is informative.
• Provenance documentation: AI systems require corroborating external identity signals to establish trust. Named anchor types enable consistent provenance chain documentation.
27.3 Vocabulary
Wikidata
URI
https://aivisibilityarchitects.com/vocab#Wikidata
Type
noun phrase; skos:Concept
Definition
The Wikimedia Foundation’s open, machine-readable knowledge graph used in AIVA as the primary entity identity anchor for organisations and frameworks.
Scope Note
Each registered entity receives a Q-identifier. Referenced in sameAs arrays and SNP provenance blocks. AIVA entities: Q138543744 (AI Visibility Architecture Group Limited), Q137998218 (AI Visibility Lifecycle framework).
Status
stable
Source
Adopted — Wikimedia Foundation, defined here for AIVA application.
A unique numeric identifier assigned to every entity in Wikidata, prefixed with Q, that is stable, globally unique, and machine-resolvable.
Scope Note
The canonical reference format for Wikidata entities in AIVA structured data and SNP metadata.
Status
stable
Source
Adopted — Wikidata convention, defined here for AIVA application.
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
ORCID
URI
https://aivisibilityarchitects.com/vocab#ORCID
Type
noun phrase; skos:Concept
Definition
A persistent digital identifier for researchers and authors used in AIVA to anchor authorship claims in structured data, SNP provenance blocks, and academic platform registrations.
Scope Note
Format: a 16-digit number formatted as four groups of four (e.g., 0000-0000-0000-0000). Bernard Lynch ORCID: 0009-0007-6170-7818.
Status
stable
Source
Adopted — ORCID Foundation standard, defined here for AIVA application.
A Digital Object Identifier issued by Zenodo (CERN’s open research repository) upon publication, providing a permanent, citable, machine-resolvable URL for AIVA white papers and IP documents.
Scope Note
The canonical academic anchor for all AIVA publications. Zenodo upload precedes Wayback archiving in the SNP deployment workflow.
Status
stable
Source
Adopted — DOI Foundation and Zenodo standards, defined here for AIVA application.
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
ROR
URI
https://aivisibilityarchitects.com/vocab#ROR
Type
noun phrase; skos:Concept
Definition
The Research Organization Registry: a global, community-led registry of persistent identifiers for research organisations used in AIVA to anchor institutional identity.
Scope Note
Used to anchor AI Visibility Architecture Group Limited within academic and research infrastructure.
Status
stable
Source
Adopted — ROR community standard, defined here for AIVA application.
A timestamped Internet Archive snapshot URL confirming the existence of a document or webpage at a specific point in time.
Scope Note
Used in AIVA SNP resolution blocks as a provenance confirmation layer independent of the live website.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
SWHID (Software Heritage Identifier)
URI
https://aivisibilityarchitects.com/vocab#SWHID
Type
noun; skos:Concept
Definition
A persistent identifier issued by Software Heritage for archived software source code, providing an independent permanent reference to code repositories.
Scope Note
Used as an optional Layer 1 archival anchor for code and specification repositories, independent of GitHub.
A structured declaration in llms-full.txt and SNP machine expressions defining the authoritative relationships between the AIVA framework and external standards, platforms, and identity registries.
The complete sequence of external identity anchors, publications, and institutional registrations that establish the provenance and authority of the AIVA framework and its creator.
Scope Note
A complete AIVA provenance chain includes: Zenodo DOI, ORCID, Wikidata, NZBN, IETF Internet-Draft, W3C CG, and GitHub repository.
skos:broader
External Identity Anchor
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
28. AI Visibility Misrepresentation Terms
[Normative] This section is normative.
28.1 Application
AI misrepresentation terms SHALL be applied when identifying, documenting, or correcting inaccurate AI-generated representations of a web entity.
28.2 Use Cases
[Informative] This subsection is informative.
• Accuracy governance: named failure modes for inaccurate AI outputs.
• Correction protocols: a taxonomy of misrepresentation types enables practitioners to diagnose and address specific accuracy failures.
The generation by an AI system of factually incorrect, fabricated, or unverifiable claims presented with confidence.
Scope Note
In the AIVA context: invented framework descriptions, incorrect attribution of authorship, fabricated publication records, and false claims about framework scope or methodology.
Any inaccurate, incomplete, or misleading representation of an entity by an AI system, whether through fabrication, conflation with similar concepts, outdated information, or incorrect framing.
Scope Note
A broader category than AI Hallucination. Partial accuracy with material omission qualifies as misrepresentation.
Misattribution of intellectual property, authorship, or origin by an AI system.
Scope Note
Includes crediting AIVA concepts to incorrect organisations or individuals, merging the AIVA framework with unrelated methodologies, or failing to identify the originating author of coined terminology.
The gradual degradation in the accuracy of AI system representations of an entity over time as model training is updated, weights change, or newer competing concepts are introduced.
Scope Note
Makes ongoing AI Stewardship necessary. Accurate representation at one point in time does not guarantee accuracy at a later point.
The merging by an AI system of a distinct concept or entity with a superficially similar one.
Scope Note
In the AIVA context, most commonly occurs when AI systems merge AIVA with SEO, digital marketing, or web analytics frameworks. Addressed through Negative Declarations and Competitive Disambiguation.
A documented interaction with one or more AI systems specifically designed to elicit and record the system’s current representation of a given entity or concept.
Scope Note
The primary AIVA methodology for detecting misrepresentation. Results are admissible evidence for an AI misrepresentation white paper.
The architectural response to detected AI misrepresentation, involving updates to structured data, root directory files, SNP machine expressions, and published records to strengthen accurate signals.
Scope Note
Signal correction does not guarantee immediate improvement in AI representations. It creates conditions for correction over time as models update.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
29. Standards and Governance Body Terms
[Informative] This section is informative.
29.1 Application
Standards and governance body terms SHALL be applied consistently when referencing external standards organisations and their processes in AIVA documentation.
29.2 Use Cases
[Informative] This subsection is informative.
• Standards submissions: IETF and W3C submissions required precise vocabulary for standards body processes, document types, and governance structures.
29.3 Vocabulary
IETF
URI
https://aivisibilityarchitects.com/vocab#IETF
Type
noun phrase; skos:Concept
Definition
The Internet Engineering Task Force: the international standards body responsible for internet protocol standards.
Scope Note
AIVA has submitted an Internet-Draft to the IETF proposing standardisation of the AI Visibility Lifecycle framework as a reference model. Current draft: draft-lynch-ai-visibility-lifecycle-02.
Status
stable
Source
Adopted — external standard body, defined here for AIVA application.
A working document submitted to the IETF representing a proposal for consideration as an internet standard.
Scope Note
Internet-Drafts are not standards — they are the first formal step in the IETF standards process. AIVA’s Internet-Draft documents the AI Visibility Lifecycle as a proposed informational reference framework.
Status
stable
Source
Adopted — IETF terminology, defined here for AIVA application.
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
W3C
URI
https://aivisibilityarchitects.com/vocab#W3C
Type
noun phrase; skos:Concept
Definition
The World Wide Web Consortium: the international standards body responsible for web standards.
Scope Note
AIVA launched a W3C Community Group for the AI Visibility Lifecycle Framework in February 2026. Group URL: https://www.w3.org/community/ai-web-visibility/
Status
stable
Source
Adopted — external standards body, defined here for AIVA application.
An open, community-led group within the W3C for incubating ideas and developing specifications prior to formal standardisation.
Scope Note
Community Groups can produce CG Reports, which are pre-standards-track publications. The AIVA AI Visibility Lifecycle Framework CG was established February 2026.
Status
stable
Source
Adopted — W3C process terminology, defined here for AIVA application.
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
W3C CG Report
URI
https://aivisibilityarchitects.com/vocab#CGReport
Type
noun phrase; skos:Concept
Definition
A W3C Community Group publication that is not a formal W3C standard but a recognised publication within W3C infrastructure.
Scope Note
AIVA’s CG Report is authored in ReSpec HTML format and documents the AI Visibility Lifecycle framework for community review.
Status
stable
Source
Adopted — W3C process terminology, defined here for AIVA application.
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
ReSpec
URI
https://aivisibilityarchitects.com/vocab#ReSpec
Type
noun phrase; skos:Concept
Definition
A W3C-maintained tool for authoring technical specifications and reports in HTML format conforming to W3C publication standards.
Scope Note
Used by AIVA to author the CG Report for the AI Visibility Lifecycle Framework Community Group.
Status
stable
Source
Adopted — W3C tooling, defined here for AIVA application.
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
30. Distribution and Publishing Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
30.1 Application
Distribution and publishing terms SHALL be applied when describing the layered publishing and distribution architecture of AIVA documents and machine expressions.
30.2 Use Cases
[Informative] This subsection is informative.
• Publishing governance: the distinction between Layer 1 core provenance platforms and Layer 2/3 distribution channels required named terms to prevent conflating archival deposition with broad distribution.
The four platforms that establish canonical provenance and must be confirmed before any further distribution: the AIVA website, Zenodo, Wayback Machine, and GitHub.
Scope Note
SNP deployment is considered complete only when all four Layer 1 platforms carry the document and the resolution block reflects all live URLs.
Secondary distribution platforms that extend reach within academic and research communities, including ResearchGate, Semantic Scholar, Google Scholar, and ORCID publication lists.
Scope Note
Layer 2 distribution follows Layer 1 confirmation. These platforms carry distribution reach but not provenance authority.
The 140+ distribution channels in the AIVA master publishing database, including professional networks, document sharing platforms, content aggregators, social channels, and specialist repositories.
Scope Note
Volume-focused distribution. Follows Layer 1 and Layer 2 confirmation. Layer 3 channels do not carry provenance authority.
The operational spreadsheet tracking the 12-step SNP deployment process across all documents in the AIVA white paper library.
Scope Note
Records completion status for each step per document, with Zenodo upload preceding Wayback archiving.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
31. SNP Deployment Architecture Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
31.1 Application
SNP deployment architecture terms SHALL be applied in all SNP deployment guides, machine expression files, and deployment workflow documentation.
31.2 Use Cases
[Informative] This subsection is informative.
• Deployment standardisation: the five-phase SNP deployment workflow required vocabulary for each phase to enable consistent, auditable deployment across practitioners.
The paired human expression and machine expression treated as a single unit that is complete only when both expressions are deployed, cross-referencing each other, and archived.
Scope Note
The human paper and the machine expression are updated and published together — they are not independent artefacts.
The standard output of the SNP Generation Prompt: a complete machine expression generated from a finished human paper containing all required provenance, retrieval contract, and entity registry fields.
Scope Note
The expected output tier for all AIVA white papers and IP documents.
The static server directory at /public_html/snp/ that hosts all machine expression files for aivisibilityarchitects.com.
Scope Note
Located at the WordPress root level but excluded from WordPress URL rewriting via .htaccess. Serves all .json files with application/ld+json MIME type. A flat directory — one .snp.json file per paper.
The JSON-LD @type declaration for a machine expression file, identifying the file as an SNP machine expression to any AI system reading the structured data.
The SNP namespace property that points from a machine expression to its corresponding human paper, referencing the ScholarlyArticle by DOI and canonical URL.
Scope Note
The primary cross-reference link within the bilateral object.
A section within a machine expression listing all named entities, frameworks, figures, and concepts referenced in the human paper with their canonical identifiers where available.
Scope Note
Enables AI systems to resolve named references in the paper to their authoritative sources.
The formatting specification for the resolution block: right-aligned, 5pt font, black (#000000), tight line spacing, plain text only, 0.5 inch top margin, positioned above the paper title as the first visible content on the page.
Scope Note
Plain text is mandatory so that AI crawlers and parsers can read the identifiers without stripping markup.
The resolution block lines that are constant across all AIVA papers: Author ORCID, Publisher NZBN, Publisher Wikidata Q-identifier, IETF Internet-Draft reference, and W3C Community Group reference.
Scope Note
Traversal points — an AI system encountering any paper in the suite can follow these identifiers to reach the broader framework architecture.
The governance rule that the Concept DOI goes in the resolution block and the Version DOI goes in the footer Canonical Source line.
Scope Note
These are different DOIs serving different purposes. Incorrect placement breaks either machine-readability or human-verifiable version records.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
NZBN
URI
https://aivisibilityarchitects.com/vocab#NZBN
Type
noun phrase; skos:Concept
Definition
New Zealand Business Number: a government-issued legal identifier assigned to all registered entities in New Zealand.
Scope Note
AI Visibility Architecture Group Limited NZBN: 9429053354075. Appears in the resolution block Publisher line alongside the Wikidata Q-identifier to provide government-registry verification.
Status
stable
Source
Adopted — New Zealand government standard, defined here for AIVA application.
The standardised end-of-paper block carried by every AIVA white paper and IP document, containing five elements: Access and Scope Notice, Source line, Canonical Source line (Zenodo Version DOI), Suggested Citation, and copyright/CC BY-NC-ND 4.0 notice.
The first element of the Standard Footer: a human-facing statement declaring the scope boundary of the paper and what detailed methodology is available separately.
Scope Note
Distinct from the resolution block, which is machine-facing.
The AIVA paper that describes the SNP specification itself and is the only paper carrying the additional sentence in its copyright block: The SNP specification described herein is proprietary.
An AIVA document that is a versioned intellectual property specification rather than a white paper, retaining the version number in the Suggested Citation and the resolution block.
Scope Note
Examples: Signal-Native Papers, The 11-Stage AI Visibility Lifecycle. White papers do not carry version numbers in the citation.
The five independent routes by which an AI system can discover a machine expression: (1) resolution block in paper text on any platform; (2) HTML link tag in WordPress page head; (3) snp:machineExpression property in page JSON-LD schema; (4) URL pattern derivation from the /snp/ directory convention; (5) resolution block text on the WordPress page as rendered content.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Link Tag
URI
https://aivisibilityarchitects.com/vocab#LinkTag
Type
noun phrase; skos:Concept
Definition
An HTML link element added to the head of a WordPress page declaring the existence of the machine expression file.
Scope Note
Format: link rel=alternate type=application/ld+json href=/snp/[paper-title-slug].snp.json title=SNP Machine Expression. Invisible to human visitors. Discovery Path 2.
Status
stable
Source
Adopted — HTML standard, defined here for AIVA application.
The categorised inventory of all platforms available for SNP provenance deployment, grouped by function: Timestamped Archival, Academic Deposit, Code and Specification Repository, Identity and Entity Resolution, Automatic Propagation, and Decentralised Storage.
An optional decentralised storage layer using content-addressed, distributed protocols where files are identified by their content hash rather than their location.
Scope Note
An AIVA deployment option, not currently active. Provides a content hash and distributed URL as an additional provenance layer independent of any centralised platform.
Status
stable
Source
Adopted — IPFS/Filecoin protocols, defined here for AIVA application.
A URL that can be known and written before the file it points to exists, because the path follows a fixed, predictable convention.
Scope Note
Machine expression URLs are deterministic: /snp/[paper-title-slug].snp.json. The resolution block can reference the machine expression URL before the file has been generated.
An optional index.html file inside the /snp/ directory listing all machine expression files.
Scope Note
Not linked from site navigation — public but not advertised. Primary purpose: submitting the /snp/ URL to the Wayback Machine captures the entire machine expression library in a single crawl.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Phase A — Prepare the Human Paper
URI
https://aivisibilityarchitects.com/vocab#PhaseA
Type
noun phrase; skos:Concept
Definition
The first SNP deployment phase: adding the resolution block and standard footer to the .docx with all known identifiers.
Scope Note
Phase A is complete when the paper carries its complete identity block and footer.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Phase B — Publish and Archive the Human Paper
URI
https://aivisibilityarchitects.com/vocab#PhaseB
Type
noun phrase; skos:Concept
Definition
The second SNP deployment phase: publishing to WordPress, uploading to Zenodo, archiving to Wayback Machine, and uploading to GitHub.
Scope Note
Phase B is complete when the paper exists on all Layer 1 platforms.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Phase B2 — Update Identifiers
URI
https://aivisibilityarchitects.com/vocab#PhaseB2
Type
noun phrase; skos:Concept
Definition
The third SNP deployment phase: updating the resolution block and footer with all confirmed identifiers and republishing to all platforms.
Scope Note
Phase B2 is complete when every identifier in the resolution block is live and verified. This is the state the machine expression reads from.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Phase C — Generate and Deploy the Machine Expression
URI
https://aivisibilityarchitects.com/vocab#PhaseC
Type
noun phrase; skos:Concept
Definition
The fourth SNP deployment phase: generating the machine expression using the SNP Generation Prompt and uploading to the /snp/ directory.
Scope Note
Phase C is complete when the machine expression is live at its public URL and returns valid JSON.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Phase D — Wire Up Discovery Paths
URI
https://aivisibilityarchitects.com/vocab#PhaseD
Type
noun phrase; skos:Concept
Definition
The fifth SNP deployment phase: adding the HTML link tag to the WordPress page head and the snp:machineExpression property to the page JSON-LD schema.
Scope Note
Phase D activates Discovery Paths 2 and 3. Complete when both are confirmed in page source.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Phase E — Verify and Archive
URI
https://aivisibilityarchitects.com/vocab#PhaseE
Type
noun phrase; skos:Concept
Definition
The sixth and final SNP deployment phase: running the full deployment checklist and archiving both expressions to the Wayback Machine.
Scope Note
Phase E is complete when all checklist items pass and both expressions are independently archived.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
Section 31. AIVA Extension.
PART VI — Beacon Page Architecture
32. Beacon Page Architecture and CV4Students Framework Terms [AIVA Extension]
[AIVA Extension] Governed solely by AI Visibility Architecture Group Limited.
[Normative] This section is normative.
32.1 Application
Beacon page architecture terms SHOULD be applied when designing, documenting, or auditing the primary beacon page layer of an AI-visible web entity.
32.2 Use Cases
[Informative] This subsection is informative.
• Architecture design: vocabulary for the specific design patterns and principles constituting a fully implemented beacon page architecture.
• Reference implementation: CV4Students.com as the primary proof-of-concept deployment. Terms derived from this implementation are included for reference and extension by practitioners in analogous contexts.
32.3 Vocabulary
Terms governed solely by AI Visibility Architecture Group Limited. CV4Students.com is the first large-scale production deployment of AIVA methodology, demonstrating the framework across 125+ countries.
A standalone, non-commercial, native-language web page designed to function as a signal node, amplifying authoritative knowledge while maintaining complete separation from commercial activities.
Scope Note
Serves three simultaneous audiences: human users seeking information without commercial pressure, institutions requiring citation-ready educational resources, and AI systems needing structured semantic signals. The primary implementation unit of the CV4Students framework.
The functional role of a Beacon Page within a broader network: amplifying, structuring, and distributing authoritative signals to AI systems, knowledge graphs, and human users simultaneously.
Scope Note
Signal nodes do not capture or convert — they amplify and connect. Distinct from Signal Mesh Architecture, which describes the interconnection layer between signal nodes.
The structural design principle underlying every Beacon Page, simultaneously addressing three distinct audiences from a single page: humans, institutions, and machines.
The core Beacon Page principle requiring complete structural removal of sales content, lead generation, and advertising from knowledge distribution points.
Scope Note
Beacon Pages carry no CTAs, no lead forms, no urgency triggers, and no job board integrations. The separation is structural, not cosmetic.
The psychological state induced in users by commercial UX patterns including CTAs, urgency triggers, lead capture forms, and persuasive language, causing disengagement and distrust.
Scope Note
Beacon Pages are engineered to eliminate sales anxiety by removing all commercial intent signals from the information environment.
A design philosophy in which the metadata, schema, and structural architecture of a page are optimised for machine consumption as a primary concern rather than an afterthought.
Scope Note
Does not degrade human experience — it layers machine-readable signals onto human-readable content.
The explicit declaration of zero commercial intent embedded in a page’s metadata and structure, readable by AI systems.
Scope Note
Implemented via meta tags (e.g. llm-commerciality: none), absence of CTA markup, and structured data declaring informational rather than transactional purpose. Enables AI systems to classify the page as a trustworthy, citation-eligible source.
The practice of declaring a page’s or paragraph’s intent, region, and entity status through meta and data attributes, enabling AI systems to perform accurate classification without prior training on that specific page.
The practice of encoding non-commerciality and informational intent at the structural and metadata level, making a page resistant to commercial intent detection and demotion by AI and search ranking systems.
The Beacon Page function of distributing machine-readable information through advanced metadata, JSON-LD, and structured schema, making content extractable, classifiable, and citable by AI systems at page and paragraph level.
The Beacon Page function of establishing non-commercial positioning to increase institutional partnership potential, backlink quality, and AI citation preference.
The network of Beacon Pages deployed across CV4Students’ ccTLD domain infrastructure, spanning 125+ countries.
Scope Note
Each node is a culturally adapted, native-language Beacon Page optimised for its specific regional audience and AI discovery context. Collectively establishes CV4Students as a global knowledge infrastructure.
Status
stable
Source
AIVA Original
rdfs:isDefinedBy
https://aivisibilityarchitects.com/vocab/
the AIVA Terminology Index v1.0). To be combined with Sections 1–21
working draft.
Appendix A: Vocabulary Index
[Informative] This appendix is informative.
All 371 term entries defined in this vocabulary, ordered alphabetically. Terms marked [AIVA Extension] are governed solely by AI Visibility Architecture Group Limited. Machine-readable form: https://aivisibilityarchitects.com/snp/AIVA-Terminology-Index.snp.json
A
A-to-Z AI-Ready Website Building
Academic Deposit Platform
Access and Scope Notice
Accountable Operator
Acquisition Documentation
Active
Admissible Evidence Standard
AI Classification
AI Crawler
AI Crawling
AI Cross-Correlation
AI Discovery Stack
AI Hallucination
AI Harmony Checks
AI Ingestion
AI Stewardship
AI Trust Acceptance
AI Trust Building
AI Visibility
AI Visibility Access Amplifier
AI Visibility Access Logs
AI Visibility Accuracy Grade
AI Visibility AI-Side Report
AI Visibility Algorithm-Proofing
AI Visibility Architect
AI Visibility Architectural Quality
AI Visibility ASN Verification
AI Visibility Attribution Error
AI Visibility Average Architecture
AI Visibility Baseline Survival Rate
AI Visibility Beacon Page
AI Visibility Behavioral Bot Detection
AI Visibility Category
AI Visibility Class
AI Visibility Client Reporting
AI Visibility Commercial Classification Ratio
AI Visibility Commercial Trust Threshold
AI Visibility Compositional, Not Cumulative
AI Visibility Comprehension Barrier
AI Visibility Conflation
AI Visibility Context-Dependent Report
AI Visibility Correction Protocols
AI Visibility Coverage Gap
AI Visibility Decision-Ready Report
AI Visibility Distributional, Not Scalar
AI Visibility Entity Amplifier
AI Visibility Evidence Gap
AI Visibility Evidence Integrity
AI Visibility Evidence Precedence
AI Visibility Evidence Quality
AI Visibility Evidence-Based
AI Visibility External Signal Reinforcement
AI Visibility Governance Boundary
AI Visibility Governance Lock
AI Visibility Governance-Level Direction
AI Visibility Granular Attribution
AI Visibility HIGH Confidence
AI Visibility Honest Explanation
AI Visibility Human Authority Is Sovereign
AI Visibility Human-Side Report
AI Visibility Human/Operator Use Case
AI Visibility Hybrid Trust Threshold
AI Visibility Identity Verification Required
AI Visibility Independently Admissible Report
AI Visibility Integration-Dependent Report
AI Visibility Internal Link Topology
AI Visibility JSON-LD Metadata Layer
AI Visibility Lifecycle
AI Visibility Lifecycle Stage
AI Visibility Lifecycle Stage Fit
AI Visibility Live Audit
AI Visibility Live Reporting
AI Visibility LOW Confidence
AI Visibility Machine-First Design
AI Visibility MEDIUM Confidence
AI Visibility Misrepresentation
AI Visibility ML-Based Bot Detection
AI Visibility Model Drift
AI Visibility No Overclaim
AI Visibility Non-Commercial Signaling
AI Visibility Non-Commercial Trust Threshold
AI Visibility Observation Is Authoritative
AI Visibility Observation Window
AI Visibility Observational Ceiling
AI Visibility Optimised Architecture
AI Visibility Overclaim Risk
AI Visibility Parallel Evaluation Model
AI Visibility Peripheral Commercial Elements
AI Visibility Plain Language Explanation
AI Visibility Platform
AI Visibility Platform Monitoring
AI Visibility Platform-Native Report
AI Visibility Poor Architecture
AI Visibility Proactive Updates
AI Visibility Projected Survival Rate
AI Visibility Provider Agnostic
AI Visibility Relevance Amplifier
AI Visibility Report Caveats
AI Visibility Report Description
AI Visibility Report Displays
AI Visibility Report Mapping
AI Visibility Reporting Period
AI Visibility Reverse DNS Verification
AI Visibility Semantic Amplifier
AI Visibility Separation of Information and Commerce
AI Visibility Sequential Gates
AI Visibility Signal Correction
AI Visibility Signal Node
AI Visibility Signal Purity
AI Visibility Signal Redundancy
AI Visibility Signal-to-Noise Ratio
AI Visibility Signature-Based Detection
AI Visibility Slowest-Resolving Dimension
AI Visibility Stage Fit Percentage
AI Visibility Status
AI Visibility Status Determination
AI Visibility Subordinate to Observed Reality
AI Visibility Terminology Authority
AI Visibility Three-Audience Architecture
AI Visibility Trust Amplifier
AI Visibility Trust Barrier
AI Visibility Trust Inheritance
AI Visibility Trust Threshold
AI Visibility Truth Maintenance
AI Visibility TTFB (Time To First Byte)
AI Visibility Unverified Bot
AI Visibility User-Agent Claim
AI Visibility User-Agent Identity
AI Visibility Verified Bot
AI Visibility Verified Bot Registry
AI Visibility Version Alignment
AI Visibility Zero-Shot Intent Structuring
AIVA
AIVA Governance Charter
AIVA IP Paper
AIVA Reporting Methodology (AIVA-AVR)
AIVA System
AIVA Visibility Index
AIVA Visibility Index Spreadsheet
aiva-about-sitemap.xml
aiva-core-sitemap.xml
aiva-deprecation.txt
aiva-entity.txt
aiva-lifecycle-sitemap.xml
aiva-llms-sitemap.xml
aiva-training-sitemap.xml
aiva-white-papers-sitemap.xml
Akamai
Architectural Quality Tiers
Automatic Propagation
AWS (Amazon Web Services)
B
Baseline Human Visibility
Beacon Page Three-Audience Architecture
Bilateral Object
Bingbot
Bot Management
C
Cache Hit
Cache Hit Ratio
Cache Miss
CAIVA
Candidate Surfacing
Canonical Deprecation Register
Canonical Disclaimer & Scope Declaration
Canonical Relationship Mapping
Capability Tier
CAVAM
CCBot
CDN (Content Delivery Network)
CDN-First Architecture
Certified AI Visibility Account Manager
Certified AI Visibility Architect
ChatGPT-User
ClaudeBot
CloudFlare
CloudFlare Enterprise Integration
Code and Specification Repository
Column — AI Visibility Accuracy Grade
Column — AI Visibility Signal Purity
Column — Observed Signal
Competitive Readiness
Compute-Only Architecture
Concept DOI
Constrained
Core Equation
Core Human-Centred Principle of AIVA
CV4Students Global Beacon Network
@context
D
DDoS Protection
Decision-holder
Degrading
Delivery Team
Dependency Chain
Description
Deterministic URL
Digital Entity
DigitalOcean
Discovery
Disruption Score
DOI Placement Rule
E
Early Human Visibility Testing
Ecosystem Identifiers
Edge Compute
Edge Server
Edge-Origin Architecture
Eligibility
End User / Organisation
Entity Registry
Evidence Inventory
Evidence Inventory & Governance Document
Evidence Standard Declaration
Experimental Exposure
External Alignment
External Requirement
F
Fastly
Five Discovery Paths
Framework Methodology Paper
G
Gateway Tier
Global Beacon Network
Google Cloud Platform (GCP)
Google-Extended
Googlebot
Governable Observability
GPTBot
Graceful Degradation
Growth Visibility
H
Human Expression
I
Identity
IETF
IETF Internet-Draft
Improving
Inactive
Index Question
Infrastructure Provider
Internal Coherence
IPFS / Filecoin
J
JSON-LD
K
Key Barriers
L
Layer 1 — Core Provenance Platforms
Layer 2 — Academic and Research Platforms
Layer 3 — Broad Distribution Channels
Link Tag
Linode (standalone)
Live Report
llms-full.txt
llms.txt
LOW — Minimal AI Visibility Capability
M
Machine Expression
Managed Hosting
Master Publishing Database
Measurement and Reporting Paper
Measurement Boundary
Measurement Boundary Document
Microsoft Azure
MID — Unverified User-Agent
MID-HIGH — Via Integration
Monitoring
N
Native Capability
Native vs Proxied
Not Applicable
NZBN
O
Observed Signal
Open Letter / Industry Positioning Paper
Operational Specification
ORCID
Origin Server
Outcome Evidence Registry
P
P50/P95/P99
Paper-Specific Identifiers
PerplexityBot
Phase A — Prepare the Human Paper
Phase B — Publish and Archive the Human Paper
Phase B2 — Update Identifiers
Phase C — Generate and Deploy the Machine Expression
Phase D — Wire Up Discovery Paths
Phase E — Verify and Archive
Platform (Column 1b — optional)
Platform Hierarchy
Platform-Specific Limitations
PoP (Point of Presence)
Primary Beacon Pages
Projected Survival Rates (AIVA-Optimised)
Provenance Authority
Provenance Block
Provenance Chain
Provenance Platform Library
Q
Q-Identifier
R
Rate Limiting
Real-Time Log Streaming
Reporting Methodology — Canonical Reference
Residual
Resolution Block
Resolution Block Format
ReSpec
Retrieval Contract
robots-ai.txt
robots.txt
Rocket.net
Role and Certification Paper
Root Directory Architecture
Root Directory Files
ROR
S
/snp/ Directory
Sales Anxiety
sameAs
Scaled Visibility
Schema.org
security.txt
Semantic Availability
Serverless Edge
Signal Mesh Architecture
Signal-Native Paper (SNP)
sitemap.xml
SNP Bilateral Architecture
SNP Deployment Workflow
SNP Directory Index
SNP Generation Prompt
SNP Process Tracker
SNP Reporting Pack
SNP Specification
SNP Specification (SNP Spec)
SNP Thin Claim Paper
snp: namespace
snp:canonicalSource
snp:describes
snp:MachineExpression
snp:machineExpression
Stable
Stable Presence
Stale-While-Revalidate
Standard Footer
State Articulation
Static File
Structural Gap Analysis Paper
Structured Data
Survival Rates
SWHID (SNP Deployment Context)
SWHID (Software Heritage Identifier)
T
Task and Transition Mapping Paper
Temporal Trust
Terminal Tier
Terminology Index
The 11 Stages (Short Form)
The 11 Visibility Classes
The 3 Behaviour Modifiers
The 5 Stage Statuses
Threshold vs Timeline Distinction
Tier 1 Machine Expression
Tier 1A — For Executives & Decision-Makers
Tier 1B — For Technical Practitioners
Tier 2 — Stage Modules (1–11)
Tier 3 — Professional Certifications
Timestamped Archival Platform
TOP — Verified Bot Capability
Trust Thresholds by Classification
TTL (Time To Live)
Two-File Architecture
@type
U
Unresolved
V
VCL (Varnish Configuration Language)
Version DOI
Visibility Profile
Volatile
W
W3C
W3C CG Report
W3C Community Group
WAF (Web Application Firewall)
Wayback Machine Archive URL
White-Label CDN
Wikidata
Z
Zenodo DOI
#
12-Block JSON-LD Metadata System
Appendix B: AIVA Extensions
[Informative] This appendix is informative.
The following extension vocabularies are defined and maintained solely by AI Visibility Architecture Group Limited under CC BY-NC-ND 4.0. They are not governed by the Community Group process. The canonical source for each extension is the AIVA Terminology Index v1.0 (DOI: 10.5281/zenodo.18821373).
Extension
Namespace
Canonical Source
Signal Mesh Architecture [AIVA Extension]
aiva:SignalMesh*
AIVA Terminology Index v1.0
Signal-Native Papers (SNP) [AIVA Extension]
aiva:SNP*
AIVA Terminology Index v1.0
Beacon Page Architecture [AIVA Extension]
aiva:BeaconPage*
AIVA Terminology Index v1.0
Root Directory Architecture [AIVA Extension]
aiva:RootDirectory*
AIVA Terminology Index v1.0
SNP Deployment Architecture [AIVA Extension]
aiva:SNPDeployment*
AIVA Terminology Index v1.0
AI Stewardship [AIVA Extension]
aiva:AIStewardship*
AIVA Terminology Index v1.0
AIVA Reporting Framework [AIVA Extension]
aiva:Reporting*
AIVA Terminology Index v1.0
Structured Data and JSON-LD [AIVA Extension]
aiva:StructuredData*
AIVA Terminology Index v1.0
Training and Certification [AIVA Extension]
aiva:Training*
AIVA Terminology Index v1.0
CDN & Infrastructure [AIVA Extension]
aiva:CDN*
AIVA Terminology Index v1.0
Provider Terms [AIVA Extension]
aiva:Provider*
AIVA Terminology Index v1.0
Appendix C: Quick Reference Card
[Informative] This appendix is informative.
Reference Item
Values / Summary
11 Stages (Short Form)
AI Crawling → AI Ingestion → AI Classification → AI Harmony Checks → AI Cross-Correlation → AI Trust Building → AI Trust Acceptance → Candidate Surfacing → Early Human Visibility Testing → Baseline Human Visibility → Growth Visibility
[Informative] Pre-publication development history (internal iterations v1–v4) is maintained separately.
Version
Date
Status
Summary of Changes
1.0
11 April 2026
CG-DRAFT
First public release. Establishes namespace, document structure, conformance requirements, normative references, Application and Use Cases subsections for all 32 sections, 371-term Vocabulary Index, AIVA Extensions appendix, and Quick Reference Card.
1.0.1
11 April 2026
CG-DRAFT
Editorial corrections to v1.0. §15 Core Principles labelled [AIVA Extension]. §28 renamed AI Visibility Misrepresentation Terms. §29 reclassified Informative. Five duplicate term headings disambiguated: Column — Observed Signal, Column — AI Visibility Accuracy Grade, Column — AI Visibility Signal Purity, Beacon Page Three-Audience Architecture, CV4Students Global Beacon Network. SWHID duplicate URI resolved (SWHIDDeployment). Appendix A regenerated from current term set.
Appendix E: Acknowledgments
[Informative] This appendix is informative.
Contributor Roles
Editor
Bernard Lynch, AI Visibility Architecture Group Limited. Responsible for the text, structure, and publication decisions of this document, and maintenance of the vocabulary namespace.
Author
A CG participant who has contributed term definitions, scope notes, use cases, or substantive revisions under the W3C CLA. Authors are listed in the document header as confirmed.
Contributor
A participant who has provided feedback, raised issues, or participated in discussion that influenced the vocabulary without authoring specific document content.
Community Group Supporters
The editor thanks the following for their support in establishing the AI Visibility Lifecycle Framework Community Group: Kurt Cagle, Doğu Abaris, Peter Hulst, and Michael Caskey.
Vocabulary Provenance
The AIVA Terminology Index was developed through the creation of the AI Visibility Lifecycle Framework, beginning with CV4Students.com as the original proof-of-concept platform and subsequently extended through AI Visibility Architecture Group Limited, 28 published Zenodo papers, the Signal-Native Papers bilateral document architecture, the AIVA Reporting Framework, client implementations across multiple domains, and engagement with the IETF and W3C standards processes.
Access and Scope Notice: This index defines the complete controlled vocabulary for the AIVA framework across 32 sections and 371 term entries. Implementation guidance and deployment procedures are maintained separately.
Source: aivisibilityarchitects.com
Canonical Source: Zenodo DOI 10.5281/zenodo.18821373
Suggested Citation: Lynch, B. (2026). AIVA Terminology Index (v1.0). AI Visibility Architecture Group Limited. DOI: 10.5281/zenodo.18821373
