SUPERCHARGE YOUR ONLINE VISIBILITY! CONTACT US AND LET’S ACHIEVE EXCELLENCE TOGETHER!
This document explains the purpose, structure, strategic value, architecture and implementation model of an ai-answer-primitives.json file for websites, organisations, enterprises, knowledge systems, AI applications, answer engines, RAG pipelines, LLM workflows and generative search environments.
The goal of this file is to help AI systems access small, structured and reusable units of knowledge that can be assembled into accurate answers.
Most websites publish information as webpages.
Humans can read those pages, understand the context and extract the relevant information.
AI systems often work differently.
They may need to identify a precise fact, definition, comparison, procedure, qualification, relationship or answer component from a much larger body of content.
A well-designed ai-answer-primitives.json file can provide these smaller knowledge units in a structured machine-readable format.
It can potentially help AI systems identify:
- direct definitions
- concise factual statements
- entity descriptions
- question-answer pairs
- comparison points
- procedural steps
- eligibility conditions
- product characteristics
- service explanations
- evidence-backed claims
- numerical facts
- dates and temporal facts
- limitations
- exceptions
- relationships between concepts
- preferred supporting URLs
- source evidence
- answer freshness
- confidence or evidence status
- reusable answer components
In simple terms, an AI Answer Primitives JSON tells an AI system:
“Here are the smallest reliable pieces of knowledge that can be retrieved and combined when answering questions about this organisation, topic, product, service or knowledge domain.”
What Is ai-answer-primitives.json?
ai-answer-primitives.json is a structured JSON file designed to store atomic or semi-atomic pieces of information that can be retrieved and reused during AI answer generation.
An answer primitive is a small knowledge object that expresses one clear piece of meaning.
For example:
{
“id”: “primitive:service:llm-seo:definition”,
“type”: “definition”,
“subject”: “LLM SEO”,
“statement”: “LLM SEO focuses on improving how brands and their information are discovered, understood, retrieved and represented within large-language-model-driven environments.”,
“canonicalUrl”: “https://example.com/llm-seo/”,
“status”: “active”
}
The purpose of the primitive is not to reproduce an entire webpage.
It isolates one useful answer component.
Another primitive might explain who a service is designed for:
{
“id”: “primitive:service:llm-seo:audience”,
“type”: “audience”,
“subject”: “LLM SEO”,
“statement”: “LLM SEO may be relevant to organisations that want stronger visibility, retrieval and representation across AI-assisted search and generative answer environments.”,
“canonicalUrl”: “https://example.com/llm-seo/”
}
Another may represent a comparison:
{
“id”: “primitive:comparison:aeo-geo”,
“type”: “comparison”,
“subjectA”: “AEO”,
“subjectB”: “GEO”,
“statement”: “AEO focuses on improving answer readiness across answer-driven search experiences, while GEO focuses more broadly on visibility and representation within generative search environments.”
}
Instead of asking an AI system to infer every answer from a long document, AI Answer Primitives provide structured knowledge blocks that can participate in retrieval and answer composition.
Why ai-answer-primitives.json Exists
AI-generated answers are constructed from information.
The quality of an answer therefore depends heavily on the quality of the information retrieved before generation.
A conventional website may contain the correct answer, but the answer may be buried within:
- a 3,000-word article
- several service pages
- multiple product descriptions
- technical documentation
- FAQ sections
- PDF reports
- case studies
- research papers
- support articles
- knowledge-base pages
- schema markup
- structured datasets
This creates a retrieval problem.
Imagine a user asks:
“What does this company specialise in?”
The information may exist across the homepage, About page, individual service pages and author biography.
Another user may ask:
“How is AEO different from GEO?”
The organisation may explain both terms separately but never provide the exact comparison required by the question.
A third user may ask:
“Who is this service suitable for?”
The answer may be implied throughout a landing page rather than expressed as one retrievable statement.
An ai-answer-primitives.json file attempts to reduce this information fragmentation by expressing important knowledge as smaller reusable units.
Instead of retrieving an entire page and asking the model to determine which sentence matters, an AI retrieval layer can potentially locate a primitive whose purpose already matches the question.
This creates an architecture where information can be organised around answers, not only around pages.
Website Pages vs Answer Primitives
Traditional Website Content
Website content answers questions such as:
- What should the visitor know?
- How should this topic be explained?
- What product or service is being offered?
- What should the visitor do next?
Website pages are generally human-first.
They can contain storytelling, branding, examples, persuasion, supporting details and calls to action.
Schema Markup
Schema markup provides page-level structured information.
It helps systems identify information such as:
- organisation
- article
- author
- product
- service
- FAQ
- event
- breadcrumb
- review
- defined term
Schema is primarily structured description.
knowledge-graph.json
A knowledge graph focuses on relationships.
It may answer:
- What entities exist?
- How are those entities connected?
- Which person created a framework?
- Which service belongs to which organisation?
- Which research asset supports which concept?
Knowledge graphs are relationship-first.
entity-registry.json
An entity registry focuses on identity.
It may answer:
- What is the canonical name of an entity?
- What aliases does it use?
- What type of entity is it?
- What ID identifies it?
- Which URLs confirm it?
Entity registries are identity-first.
brand-memory.json
Brand Memory JSON focuses on what an AI system should remember about an organisation.
It stores organisational identity, expertise, products, frameworks, people, research, evidence and preferred sources.
Brand memory is memory-first.
ai-answer-primitives.json
AI Answer Primitives focus on what information can be used to construct an answer.
It may define:
- a definition
- a fact
- an explanation
- a comparison
- a condition
- a benefit
- a limitation
- a procedure
- an eligibility rule
- a relationship
- a recommendation context
- an evidence-backed claim
AI Answer Primitives are answer-first.
The distinction can be summarised as:
Entity Registry
“What exactly is this entity?”
Knowledge Graph
“How is this entity connected to other entities?”
Brand Memory
“What should the system remember about this organisation?”
Answer Primitives
“What reliable pieces of information can the system use to answer a question?”
These files can complement one another.
Why AI Answer Primitives Matter for AI Search
AI search increasingly involves retrieval followed by synthesis.
A system may:
- interpret a question
- identify the entities and intent involved
- retrieve relevant information
- rank candidate passages
- assemble context
- generate an answer
- select or display supporting sources
Long webpages can participate in this process, but they are not always the most efficient information structure for every question.
An answer-primitives layer can make important knowledge easier to identify programmatically.
It may help create more explicit representations of:
- factual knowledge
- definitional knowledge
- procedural knowledge
- comparative knowledge
- conditional knowledge
- temporal knowledge
- evidential knowledge
For organisations investing in machine-readable AI discovery infrastructure, this can provide an additional retrieval layer between raw webpages and generated answers.
Role in GEO, AEO and LLM SEO
Generative Engine Optimization, Answer Engine Optimization and LLM SEO all involve improving the ability of machine systems to discover, understand and use information.
AI Answer Primitives can support these objectives by organising useful knowledge into answer-ready objects.
GEO Benefit
For Generative Engine Optimization, answer primitives can make important statements easier to retrieve and associate with a brand or topic.
They can encode:
- brand definitions
- expertise statements
- service capabilities
- product functionality
- framework descriptions
- comparative distinctions
- research findings
- supporting evidence
- canonical sources
When a generative engine needs information about a topic, structured primitives may provide cleaner retrieval inputs than large undifferentiated documents.
AEO Benefit
Answer Engine Optimization is especially closely connected to answer primitives.
A user might ask:
“What is AI Visibility?”
A corresponding primitive might be:
{
“id”: “primitive:ai-visibility:definition”,
“type”: “definition”,
“questionPatterns”: [
“What is AI Visibility?”,
“What does AI visibility mean?”
],
“subject”: “AI Visibility”,
“answer”: “AI Visibility describes how discoverable, represented, referenced or recommended an entity is across AI-assisted search and generative answer environments.”,
“canonicalUrl”: “https://example.com/ai-visibility/”
}
The information is already structured in an answer-ready form.
LLM SEO Benefit
Large language models work particularly well when context is clear.
Answer primitives can help organise that context.
For LLM-oriented retrieval systems, primitives may provide:
- short retrievable passages
- explicit subjects
- answer types
- canonical sources
- entity references
- evidence mappings
- freshness metadata
- intent labels
- semantic relationships
This can make retrieval systems better equipped to locate the right information before passing context to an LLM.
AI Answer Primitives as Atomic Knowledge
A useful way to understand this framework is to think of knowledge like building blocks.
A webpage may be a complete building.
An answer primitive is one brick.
A complex AI answer may require several bricks.
Suppose someone asks:
“Why should an enterprise use a knowledge graph for AI search?”
One answer might require multiple knowledge units:
Primitive 1: Definition
{
“type”: “definition”,
“subject”: “Knowledge Graph”,
“statement”: “A knowledge graph represents entities and the relationships connecting them.”
}
Primitive 2: Function
{
“type”: “function”,
“subject”: “Knowledge Graph”,
“statement”: “Knowledge graphs can provide structured relationships that support semantic retrieval and entity resolution.”
}
Primitive 3: Enterprise Benefit
{
“type”: “benefit”,
“subject”: “Enterprise Knowledge Graph”,
“statement”: “Enterprises can use knowledge graphs to connect information distributed across products, departments, documents, systems and business entities.”
}
Primitive 4: AI Search Relevance
{
“type”: “use_case”,
“subject”: “Knowledge Graph”,
“context”: “AI Search”,
“statement”: “Knowledge graphs can provide AI retrieval systems with explicit entity relationships that complement unstructured text retrieval.”
}
An AI application can potentially combine several primitives to generate a broader answer.
That is why they are called primitives.
They represent components from which larger responses can be constructed.
What Can Consume ai-answer-primitives.json?
An AI Answer Primitives file can potentially be consumed or indexed by:
- RAG pipelines
- enterprise AI assistants
- internal search systems
- semantic search engines
- LLM applications
- AI agents
- knowledge graph systems
- MCP-connected applications
- vector databases
- customer-support assistants
- sales enablement assistants
- developer assistants
- content intelligence systems
- question-answering systems
- brand knowledge systems
- AI discovery platforms
- custom search applications
Public AI systems should not be assumed to automatically consume a custom JSON file simply because it exists.
The file is therefore best viewed as machine-readable infrastructure that can support systems capable of discovering, indexing, ingesting or being explicitly connected to it.
Recommended File Location
A straightforward public location is:
https://example.com/ai-answer-primitives.json
Optional paths could include:
https://example.com/.well-known/ai-answer-primitives.json
or:
https://example.com/ai/ai-answer-primitives.json
The file can also be referenced from supporting discovery resources such as:
- llms.txt
- llms-full.txt
- ai.txt
- ai-endpoints.json
- brand-memory.json
- entity-registry.json
- knowledge-graph.json
- developer documentation
- AI integration documentation
- internal RAG configuration
- MCP documentation
The root URL is generally the simplest to identify and maintain.
Recommended MIME Type
Serve the file as:
application/json
The HTTP response should ideally resemble:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Recommended technical settings include:
- return HTTP 200
- keep the JSON valid
- use UTF-8
- avoid comments inside strict JSON
- use stable primitive IDs
- provide version information
- include a last-updated date
- keep canonical URLs live
- avoid unsupported claims
- remove obsolete primitives
- validate the file before publishing
- maintain consistent entity naming
- ensure the file remains publicly retrievable when public consumption is intended
Core Design Principles
Atomicity
Every primitive should express one primary idea.
Poor example:
{
“statement”: “Our company provides SEO, AI SEO, web development, social media marketing, PPC, branding and many other digital services and has worked with many clients globally.”
}
This contains many separate concepts.
A better architecture separates them.
{
“id”: “primitive:service:seo”,
“type”: “service_capability”,
“subject”: “SEO”,
“statement”: “The organisation provides search engine optimisation services.”
}
A separate primitive can represent AI SEO.
Another can represent web development.
Atomicity makes information easier to retrieve.
One Primitive, One Meaning
A primitive should answer one identifiable information need.
Examples include:
- What is X?
- Who created X?
- What does X do?
- Who is X for?
- How does X differ from Y?
- What is required for X?
- What is the limitation of X?
- What evidence supports X?
Do not force multiple unrelated questions into the same object.
Canonical Subjects
Each primitive should identify its subject clearly.
For example:
{
“subject”: {
“id”: “entity:framework:avm”,
“name”: “AVM”,
“canonicalName”: “AI Visibility Metric”
}
}
This helps avoid ambiguity.
Explicit Answer Type
Classifying the primitive improves retrieval.
Useful types may include:
- definition
- fact
- description
- capability
- benefit
- limitation
- comparison
- requirement
- process
- step
- recommendation
- use_case
- eligibility
- specification
- relationship
- evidence
- temporal_fact
- quantitative_fact
- policy
- exception
- clarification
For example:
{
“type”: “limitation”,
“subject”: “ai-answer-primitives.json”,
“statement”: “Publishing a custom answer-primitives file does not guarantee that public AI platforms will discover, ingest, cite or rank its contents.”
}
This is very different from a definition primitive.
The type communicates that difference.
Evidence-Linked Answers
Important claims should point toward supporting evidence.
Example:
{
“id”: “primitive:research:001”,
“type”: “research_finding”,
“subject”: “AI Search Visibility”,
“statement”: “The study found a measurable relationship between the tested visibility variables.”,
“evidence”: [
{
“url”: “https://example.com/research/study/”,
“type”: “research”
}
]
}
Do not use answer primitives as a mechanism for manufacturing authority.
If the underlying evidence does not support a claim, the primitive should not make it.
Retrieval-Friendly Language
Statements should be concise enough to retrieve while containing sufficient context to stand on their own.
Avoid:
{
“statement”: “It improves this considerably.”
}
The meaning of “it” and “this” disappears when the statement is retrieved independently.
Prefer:
{
“statement”: “Entity disambiguation can improve retrieval accuracy by helping a system distinguish between similarly named entities.”
}
Each primitive should remain intelligible outside the surrounding document.
Stable IDs
Every primitive should have a stable unique identifier.
Example:
primitive:service:geo:definition
primitive:service:geo:benefit:01
primitive:framework:avm:creator
primitive:framework:avm:purpose
IDs should not change unnecessarily.
Stable identifiers make primitives easier to reference from:
- knowledge graphs
- internal APIs
- vector stores
- retrieval systems
- evaluation datasets
- AI applications
- debugging tools
Freshness
Some answers change.
Examples include:
- prices
- product versions
- leadership
- service availability
- statistics
- regulations
- supported platforms
- office locations
- availability
- research findings
Primitives dealing with mutable information should include temporal metadata.
{
“id”: “primitive:product:availability”,
“type”: “availability”,
“statement”: “The product is currently available in the listed markets.”,
“validFrom”: “2026-09-01”,
“lastVerified”: “2026-09-01”
}
An outdated primitive can be worse than no primitive.
Machine and Human Readability
Good JSON should remain understandable to developers and editors.
Use:
- meaningful field names
- plain-language statements
- consistent naming
- predictable nesting
- stable entity IDs
- valid URLs
- consistent dates
- explicit types
Avoid:
- unnecessary abbreviations
- unexplained internal IDs
- deeply nested structures
- duplicated statements
- keyword lists disguised as answers
- marketing superlatives
- ambiguous pronouns
Key Components of ai-answer-primitives.json
A comprehensive file may include:
- metadata
- organisation
- primitive schema definition
- primitive IDs
- answer types
- subjects
- question patterns
- answer statements
- short answers
- expanded answers
- supporting evidence
- canonical URLs
- entity references
- related primitives
- semantic topics
- audience or context
- constraints
- exceptions
- temporal metadata
- confidence or evidence status
- citation preferences
- language
- retrieval hints
- governance information
- validation metadata
Field-by-Field Explanation
metadata
Defines file-level information.
Recommended fields:
- version
- generatedAt
- lastUpdated
- publisher
- fileType
- language
- canonicalUrl
- description
Example:
{
“metadata”: {
“version”: “2026.1”,
“generatedAt”: “2026-09-03”,
“lastUpdated”: “2026-09-03”,
“publisher”: “ThatWare LLP”,
“fileType”: “ai-answer-primitives”,
“language”: “en”,
“canonicalUrl”: “https://thatware.co/ai-answer-primitives.json”,
“description”: “Machine-readable answer primitives for AI retrieval, answer generation, semantic search and knowledge systems.”
}
}
Purpose:
- establishes document identity
- indicates freshness
- supports version management
- assists validation
- identifies the publisher
organization
Defines the organisation responsible for the knowledge.
Example:
{
“organization”: {
“id”: “entity:organization:thatware”,
“name”: “ThatWare”,
“legalName”: “ThatWare LLP”,
“url”: “https://thatware.co/”
}
}
Purpose:
- provides publisher context
- supports entity disambiguation
- connects primitives to an authoritative organisation
- creates a consistent namespace
primitiveId
Every primitive should have a unique identifier.
Example:
{
“primitiveId”: “primitive:geo:definition”
}
Purpose:
- supports stable references
- enables deduplication
- helps retrieval debugging
- permits cross-file linking
- allows primitives to be related programmatically
type
Defines what kind of knowledge the primitive represents.
Example:
{
“type”: “definition”
}
Other types might include:
fact
benefit
comparison
process
requirement
limitation
evidence
relationship
use_case
recommendation
clarification
Purpose:
- helps retrieval systems understand answer intent
- enables filtering
- supports different response strategies
- makes datasets easier to evaluate
subject
Defines what the primitive is about.
Example:
{
“subject”: {
“id”: “entity:concept:geo”,
“name”: “Generative Engine Optimization”,
“alternateName”: “GEO”,
“type”: “Concept”
}
}
Purpose:
- provides entity context
- improves disambiguation
- connects answers to knowledge graphs
- supports semantic retrieval
questionPatterns
Defines example questions that the primitive can help answer.
{
“questionPatterns”: [
“What is Generative Engine Optimization?”,
“What does GEO mean in AI search?”,
“Explain GEO.”
]
}
These should not be treated as an exhaustive keyword list.
They are examples of intent.
Purpose:
- improves question-to-primitive matching
- creates training and evaluation examples
- supports FAQ-style retrieval
- clarifies expected use
shortAnswer
Provides a compact answer suitable for direct retrieval.
{
“shortAnswer”: “Generative Engine Optimization focuses on improving how information and entities are represented, retrieved and surfaced within generative search environments.”
}
Purpose:
- supports concise answers
- reduces retrieval payload
- helps voice or snippet-style systems
- enables direct-answer experiences
expandedAnswer
Provides additional explanation when a short answer is insufficient.
{
“expandedAnswer”: “Generative Engine Optimization applies content, entity, semantic and technical optimisation practices intended to make information easier for generative systems to discover, understand, retrieve and use when constructing answers.”
}
Purpose:
- supports richer responses
- provides additional context
- reduces the need to retrieve an entire webpage
statement
For primitives that are not naturally question-answer objects, a statement can represent the knowledge directly.
{
“statement”: “Canonical entity naming helps retrieval systems associate information with the correct entity.”
}
evidence
Links a primitive with supporting material.
{
“evidence”: [
{
“type”: “documentation”,
“url”: “https://example.com/research/”
}
]
}
Purpose:
- supports verification
- improves traceability
- discourages unsupported claims
- connects answers with primary sources
canonicalUrl
Defines the preferred source page for deeper information.
{
“canonicalUrl”: “https://example.com/generative-engine-optimization/”
}
Purpose:
- helps systems locate full context
- supports citation selection
- creates a bridge between primitive and webpage
- reduces ambiguity between duplicate sources
entityRefs
Links the primitive to related canonical entities.
{
“entityRefs”: [
“entity:organization:thatware”,
“entity:concept:geo”
]
}
Purpose:
- integrates primitives with entity architecture
- helps knowledge graph construction
- improves disambiguation
relatedPrimitives
Connects answer units.
Example:
{
“relatedPrimitives”: [
“primitive:geo:benefit”,
“primitive:geo:use-case”,
“primitive:geo:comparison:aeo”
]
}
Purpose:
- supports answer expansion
- allows multi-step retrieval
- makes larger responses easier to compose
topics
Provides broad semantic categorisation.
{
“topics”: [
“AI Search”,
“Generative Search”,
“AI Visibility”,
“Search Optimization”
]
}
Topics should remain semantic categories rather than keyword-stuffing fields.
context
Some information is only true within a particular context.
{
“context”: {
“audience”: “enterprise marketing teams”,
“useCase”: “AI search visibility”
}
}
This can help prevent a system from applying an answer too broadly.
constraints
Defines conditions affecting the answer.
{
“constraints”: [
“Results depend on whether the consuming system indexes or ingests the structured resource.”,
“The file should complement rather than replace human-readable content.”
]
}
Constraints are particularly important where an answer could otherwise sound absolute.
exceptions
Some statements have exceptions.
{
“exceptions”: [
“Not every AI platform supports custom JSON discovery files.”
]
}
Explicit exceptions can reduce overgeneralisation.
temporal
Represents freshness.
{
“temporal”: {
“firstPublished”: “2026-09-03”,
“lastVerified”: “2026-09-03”,
“status”: “current”
}
}
evidenceStatus
A useful governance field may distinguish between:
verified
supported
experimental
internal
historical
deprecated
Example:
{
“evidenceStatus”: “verified”
}
A system should not be encouraged to present experimental knowledge as established fact.
retrievalHints
For controlled internal retrieval systems, optional hints may indicate expected retrieval scenarios.
{
“retrievalHints”: {
“intents”: [
“definition”,
“comparison”
],
“priority”: “high”
}
}
These hints should support internal retrieval architecture rather than manipulate public systems.
Example Answer Primitive
A complete individual primitive might look like this:
{
“primitiveId”: “primitive:geo:definition:001”,
“type”: “definition”,
“subject”: {
“id”: “entity:concept:geo”,
“name”: “Generative Engine Optimization”,
“alternateNames”: [
“GEO”
],
“type”: “DefinedTerm”
},
“questionPatterns”: [
“What is GEO?”,
“What is Generative Engine Optimization?”,
“What does GEO mean in AI search?”
],
“shortAnswer”: “Generative Engine Optimization focuses on improving how information, entities and sources are understood and represented in generative search environments.”,
“expandedAnswer”: “Generative Engine Optimization combines content, entity, semantic, authority and technical optimisation practices intended to improve how information is discovered, interpreted, retrieved and potentially represented by generative search systems.”,
“topics”: [
“Generative Search”,
“AI Search”,
“AI Visibility”
],
“canonicalUrl”: “https://thatware.co/generative-engine-optimization/”,
“entityRefs”: [
“entity:organization:thatware”,
“entity:concept:geo”
],
“evidenceStatus”: “supported”,
“temporal”: {
“lastVerified”: “2026-09-03”,
“status”: “current”
}
}
Recommended Answer Primitive Categories
A mature answer-primitives file may separate knowledge into categories.
Definition Primitives
Explain what something is.
Examples:
- What is AI Visibility?
- What is AEO?
- What is RAG?
- What is entity SEO?
Identity Primitives
Explain who or what an entity is.
Examples:
- Who is the organisation?
- Who founded it?
- What is the official product name?
- Which company owns a framework?
Capability Primitives
Explain what something can do.
Examples:
- What does the platform support?
- What services are available?
- What functions does the product provide?
Benefit Primitives
Explain possible value.
Example:
{
“type”: “benefit”,
“subject”: “Structured Answer Primitives”,
“statement”: “Structured answer primitives can reduce the amount of irrelevant content passed into a retrieval context by isolating smaller answer-ready knowledge units.”
}
Comparison Primitives
Explicitly distinguish concepts.
These are especially important because comparisons are often distributed across multiple pages.
Example:
{
“type”: “comparison”,
“subjectA”: “SEO”,
“subjectB”: “AEO”,
“statement”: “Traditional SEO primarily improves visibility within search discovery and ranking environments, while AEO additionally focuses on making information suitable for direct answer retrieval and answer-driven interfaces.”
}
Procedure Primitives
Describe how something should be done.
{
“type”: “procedure”,
“subject”: “JSON Validation”,
“steps”: [
“Generate the JSON file.”,
“Check syntax using a JSON validator.”,
“Verify all URLs.”,
“Confirm UTF-8 encoding.”,
“Publish the file.”,
“Test the HTTP response.”
]
}
Requirement Primitives
Describe prerequisites.
Limitation Primitives
Communicate boundaries.
These are essential for trustworthy AI knowledge.
For example:
{
“type”: “limitation”,
“subject”: “AI Answer Primitives”,
“statement”: “An ai-answer-primitives.json file is not a guaranteed ranking signal and does not guarantee inclusion in third-party AI answers.”
}
Evidence Primitives
Represent proof or supporting material.
Temporal Primitives
Represent facts that depend on time.
Numerical Primitives
Represent numerical information while preserving units and context.
{
“type”: “quantitative_fact”,
“metric”: “Response Time”,
“value”: 24,
“unit”: “hours”,
“context”: “standard support response target”
}
Do not store a number without its meaning.
Policy Primitives
Represent formal policies or restrictions.
Exception Primitives
Clarify where an otherwise valid rule does not apply.
Complete Example ai-answer-primitives.json
Below is a simplified example showing how an organisation could structure the file.
{
“metadata”: {
“version”: “2026.1”,
“generatedAt”: “2026-09-03”,
“lastUpdated”: “2026-09-03”,
“fileType”: “ai-answer-primitives”,
“publisher”: “ThatWare LLP”,
“language”: “en”,
“canonicalUrl”: “https://thatware.co/ai-answer-primitives.json”,
“description”: “Machine-readable answer primitives designed to support AI retrieval, semantic question answering, RAG systems, LLM applications and generative search discovery.”
},
“organization”: {
“id”: “entity:organization:thatware”,
“name”: “ThatWare”,
“legalName”: “ThatWare LLP”,
“url”: “https://thatware.co/”,
“primaryCategory”: “AI Search Intelligence”
},
“primitiveSchema”: {
“supportedTypes”: [
“definition”,
“identity”,
“fact”,
“capability”,
“benefit”,
“comparison”,
“process”,
“requirement”,
“limitation”,
“relationship”,
“use_case”,
“evidence”,
“clarification”
]
},
“primitives”: [
{
“primitiveId”: “primitive:thatware:identity”,
“type”: “identity”,
“subject”: {
“id”: “entity:organization:thatware”,
“name”: “ThatWare”
},
“questionPatterns”: [
“What is ThatWare?”,
“What does ThatWare do?”
],
“shortAnswer”: “ThatWare is a search intelligence organisation working across SEO, AI search visibility, LLM SEO, AEO, GEO, semantic search and related digital discovery disciplines.”,
“canonicalUrl”: “https://thatware.co/”,
“evidenceStatus”: “supported”
},
{
“primitiveId”: “primitive:ai-visibility:definition”,
“type”: “definition”,
“subject”: {
“id”: “entity:concept:ai-visibility”,
“name”: “AI Visibility”
},
“questionPatterns”: [
“What is AI Visibility?”,
“What does AI visibility mean?”
],
“shortAnswer”: “AI Visibility refers to how discoverable, represented, cited or recommended a brand or entity is across AI-assisted search and generative answer environments.”,
“canonicalUrl”: “https://thatware.co/ai-search-visibility/”,
“topics”: [
“AI Search”,
“Generative Search”,
“Brand Visibility”
]
},
{
“primitiveId”: “primitive:aeo:definition”,
“type”: “definition”,
“subject”: {
“id”: “entity:concept:aeo”,
“name”: “Answer Engine Optimization”,
“alternateName”: “AEO”
},
“questionPatterns”: [
“What is AEO?”,
“What is Answer Engine Optimization?”
],
“shortAnswer”: “Answer Engine Optimization focuses on making information easier for answer-driven systems to understand, retrieve and present in response to user questions.”,
“canonicalUrl”: “https://thatware.co/answer-engine-optimization/”
},
{
“primitiveId”: “primitive:geo:definition”,
“type”: “definition”,
“subject”: {
“id”: “entity:concept:geo”,
“name”: “Generative Engine Optimization”,
“alternateName”: “GEO”
},
“questionPatterns”: [
“What is GEO?”,
“What is Generative Engine Optimization?”
],
“shortAnswer”: “Generative Engine Optimization focuses on improving how information and entities are discovered, understood and represented within generative search environments.”,
“topics”: [
“Generative Search”,
“AI Search”
]
},
{
“primitiveId”: “primitive:aeo-vs-geo”,
“type”: “comparison”,
“subjectA”: “Answer Engine Optimization”,
“subjectB”: “Generative Engine Optimization”,
“questionPatterns”: [
“What is the difference between AEO and GEO?”,
“AEO vs GEO”
],
“shortAnswer”: “AEO focuses specifically on answer readiness and direct response environments, while GEO addresses broader visibility, retrieval and representation within generative search systems.”,
“relatedPrimitives”: [
“primitive:aeo:definition”,
“primitive:geo:definition”
]
},
{
“primitiveId”: “primitive:answer-primitives:purpose”,
“type”: “use_case”,
“subject”: {
“name”: “AI Answer Primitives”
},
“shortAnswer”: “AI Answer Primitives organise reusable pieces of knowledge that retrieval systems can potentially combine when constructing responses.”,
“topics”: [
“RAG”,
“AI Retrieval”,
“Question Answering”
]
},
{
“primitiveId”: “primitive:answer-primitives:limitation”,
“type”: “limitation”,
“subject”: {
“name”: “ai-answer-primitives.json”
},
“shortAnswer”: “Publishing ai-answer-primitives.json does not guarantee that public search engines or AI platforms will discover, ingest, rank or cite the file.”,
“evidenceStatus”: “governance”
}
],
“relatedResources”: {
“brandMemory”: “https://thatware.co/brand-memory.json”,
“entityRegistry”: “https://thatware.co/entity-registry.json”,
“knowledgeGraph”: “https://thatware.co/knowledge-graph.json”,
“aiEndpoints”: “https://thatware.co/ai-endpoints.json”
},
“governance”: {
“reviewFrequency”: “Update whenever referenced knowledge materially changes.”,
“requireEvidenceForClaims”: true,
“removeDeprecatedPrimitives”: true,
“maintainStableIds”: true
}
}
This example is intentionally simplified.
A production system may contain hundreds or thousands of primitives depending on the size of the knowledge base.
How AI Answer Primitives Can Work With RAG
Retrieval-Augmented Generation typically involves locating external knowledge before an LLM generates its response.
A conventional RAG pipeline may retrieve document chunks.
For example:
Question
↓
Embedding
↓
Vector Search
↓
Document Chunks
↓
LLM Context
↓
Generated Answer
An answer-primitives layer can introduce more structured retrieval objects.
Question
↓
Intent + Entity Detection
↓
Primitive Retrieval
↓
Evidence Retrieval
↓
Context Assembly
↓
LLM
↓
Answer
Suppose a user asks:
“What are the limitations of AI Answer Primitives?”
Instead of retrieving five paragraphs containing the word “limitations,” a system could retrieve objects explicitly typed as:
type = limitation
subject = AI Answer Primitives
This can increase retrieval precision within controlled systems.
Hybrid Retrieval Architecture
Answer primitives do not need to replace vector search.
They can complement it.
A hybrid system may combine:
Lexical Retrieval
Matches exact terminology.
Vector Retrieval
Matches semantic similarity.
Entity Retrieval
Matches canonical entities.
Graph Retrieval
Traverses relationships.
Primitive Retrieval
Retrieves explicit answer components.
A sophisticated system could combine all five.
For example:
User Question
↓
Query Understanding
↓
Entity Resolution
↓
┌────────────────────────────┐
│ Lexical Search │
│ Vector Search │
│ Knowledge Graph │
│ Answer Primitive Retrieval │
└────────────────────────────┘
↓
Evidence Ranking
↓
Context Assembly
↓
LLM Generation
↓
Citation / Source Selection
This makes ai-answer-primitives.json particularly relevant to internal AI architecture, RAG systems and enterprise knowledge applications.
Relationship With brand-memory.json
The two files solve different problems.
brand-memory.json stores important long-term organisational knowledge.
ai-answer-primitives.json decomposes relevant knowledge into units that can participate directly in answering questions.
For example, Brand Memory may say:
{
“expertise”: [
“AI Visibility”,
“LLM SEO”,
“AEO”,
“GEO”
]
}
Answer Primitives could expand that into:
What is AI Visibility?
What is LLM SEO?
What is AEO?
What is GEO?
How are AEO and GEO different?
Who is LLM SEO suitable for?
What does AI Visibility measure?
Brand Memory provides context.
Answer Primitives provide reusable responses.
Relationship With entity-registry.json
Entity Registry JSON provides canonical identity.
Answer Primitives should reference those identities where possible.
Example entity:
{
“entityId”: “entity:framework:avm”,
“name”: “AVM”,
“fullName”: “AI Visibility Metric”,
“type”: “Framework”
}
Answer primitive:
{
“primitiveId”: “primitive:avm:definition”,
“type”: “definition”,
“subjectRef”: “entity:framework:avm”,
“shortAnswer”: “AVM stands for AI Visibility Metric.”
}
This avoids creating multiple inconsistent identities for the same concept.
Relationship With knowledge-graph.json
A knowledge graph stores relationships.
Answer primitives express knowledge about those entities or relationships.
For example, the graph may contain:
ThatWare
↓ created
AVM
An answer primitive could express:
{
“primitiveId”: “primitive:avm:creator”,
“type”: “relationship”,
“subject”: “AVM”,
“predicate”: “createdBy”,
“object”: “ThatWare LLP”
}
The knowledge graph represents the relationship structurally.
The primitive makes the relationship directly usable as an answer component.
Relationship With vector-feed.xml
A vector feed can provide content intended for embedding or semantic retrieval.
Answer primitives can be included as particularly precise embedding units.
For example, instead of embedding only entire pages, an organisation might embed:
primitive:geo:definition
primitive:geo:benefit
primitive:geo:limitations
primitive:geo:comparison:aeo
Each vector now corresponds to a narrower semantic meaning.
This can potentially improve precision in retrieval systems operated by the organisation.
Relationship With ai-endpoints.json
An AI endpoints file can tell applications where machine-readable resources exist.
For example:
{
“resources”: {
“answerPrimitives”: “https://example.com/ai-answer-primitives.json”,
“brandMemory”: “https://example.com/brand-memory.json”,
“entityRegistry”: “https://example.com/entity-registry.json”,
“knowledgeGraph”: “https://example.com/knowledge-graph.json”
}
}
The endpoint registry helps systems discover resources.
The Answer Primitives file contains the answer-ready knowledge.
Answer Composition
One of the most useful characteristics of primitives is composability.
Consider the question:
“Is AI Answer Primitives JSON a replacement for website content?”
A useful answer could combine three primitives.
Definition
AI Answer Primitives store reusable knowledge units.
Limitation
They do not guarantee ingestion by external AI systems.
Relationship
They complement full website pages rather than replacing them.
A response engine can assemble the three pieces.
This is more flexible than storing only one hardcoded FAQ response for every possible wording of the question.
Primitive Granularity
The size of each primitive matters.
If primitives are too broad, they recreate the original document-chunking problem.
If they are too narrow, meaningful context may disappear.
Too broad:
{
“statement”: “Everything about Generative Engine Optimization…”
}
Too narrow:
{
“statement”: “GEO exists.”
}
Better:
{
“type”: “definition”,
“subject”: “Generative Engine Optimization”,
“statement”: “Generative Engine Optimization focuses on improving how information and entities are represented within generative search environments.”
}
The ideal primitive is small enough to retrieve precisely but complete enough to remain meaningful independently.
Answer Primitive Quality Model
Every primitive should ideally satisfy five criteria.
Accuracy
The statement should be correct.
Atomicity
It should communicate one major idea.
Context Independence
It should make sense when retrieved alone.
Evidence
Important factual claims should have support.
Freshness
Information that changes should include review metadata.
A sixth useful factor is:
Composability
The primitive should combine naturally with related primitives.
Confidence and Evidence Should Not Be Confused
If confidence fields are included, their meaning should be explicit.
A system being “confident” that a statement exists does not prove that the statement is true.
It may therefore be better to distinguish:
{
“evidenceStatus”: “supported”,
“verificationStatus”: “reviewed”
}
instead of using an unexplained:
{
“confidence”: 0.99
}
Numbers that look scientific but have no defined methodology can introduce false certainty.
Citation-Ready Primitives
A useful primitive may contain a preferred source.
{
“primitiveId”: “primitive:geo:definition”,
“shortAnswer”: “Generative Engine Optimization focuses on improving visibility and representation within generative search environments.”,
“canonicalUrl”: “https://example.com/geo/”,
“citation”: {
“preferredUrl”: “https://example.com/geo/”,
“title”: “Generative Engine Optimization”
}
}
This does not force a third-party system to cite the URL.
It simply keeps the primitive connected to a preferred supporting resource.
Multilingual Answer Primitives
An organisation serving several markets may maintain multilingual primitives.
Example:
{
“primitiveId”: “primitive:service:definition”,
“translations”: {
“en”: {
“shortAnswer”: “…”
},
“fr”: {
“shortAnswer”: “…”
},
“de”: {
“shortAnswer”: “…”
}
}
}
Alternatively, separate language-specific files may be easier to maintain:
/ai-answer-primitives.en.json
/ai-answer-primitives.fr.json
/ai-answer-primitives.de.json
Whichever architecture is chosen, avoid machine-generated translations that have not been reviewed where factual precision matters.
Enterprise Use Cases
Customer Support
Primitives can represent:
- refund conditions
- account requirements
- troubleshooting steps
- support availability
- policy explanations
Ecommerce
Primitives can represent:
- product specifications
- compatibility
- materials
- dimensions
- shipping conditions
- return rules
SaaS
Primitives can represent:
- feature definitions
- pricing conditions
- integration support
- plan limitations
- technical requirements
Financial Services
Primitives can represent:
- product definitions
- eligibility rules
- documentation requirements
- fee explanations
Any regulated or high-stakes financial information should receive appropriate professional and compliance review.
Healthcare
Primitives can represent reviewed informational knowledge, but health-related information requires strong source governance, appropriate qualifications and clear boundaries between general information and medical advice.
Education
Primitives can represent:
- course requirements
- programme structure
- entry criteria
- learning outcomes
- accreditation information
B2B Services
Primitives can represent:
- capabilities
- industries served
- engagement models
- deliverables
- service differences
- implementation processes
Recommended Primitive Collections
A large organisation could organise its primitives into conceptual groups.
Organisation Primitives
- company definition
- legal identity
- founder
- headquarters
- mission
- areas of expertise
Service Primitives
- service definition
- intended audience
- deliverables
- benefits
- process
- limitations
Product Primitives
- product definition
- functionality
- supported platforms
- integrations
- specifications
- use cases
Framework Primitives
- framework definition
- creator
- purpose
- methodology
- related frameworks
Research Primitives
- finding
- methodology
- sample
- result
- limitation
- source
Policy Primitives
- eligibility
- restriction
- requirement
- exception
- effective date
Comparison Primitives
- product A vs product B
- service A vs service B
- framework A vs framework B
Citation Primitives
- claim
- evidence source
- preferred URL
- supporting entity
Validation Checklist
Before publishing ai-answer-primitives.json, verify:
- The JSON is syntactically valid.
- The URL is accessible.
- The response returns HTTP 200.
- Content-Type is application/json.
- The encoding is correct.
- Metadata is included.
- A version number exists.
- The last-updated date is accurate.
- Every primitive has a stable ID.
- Primitive types are consistent.
- Subjects are explicit.
- Canonical entity names are used.
- Definitions are accurate.
- Statements can stand independently.
- Ambiguous pronouns are removed.
- Important claims contain evidence where appropriate.
- Canonical URLs are live.
- Related entity IDs are valid.
- Related primitive IDs exist.
- Time-sensitive facts include freshness data.
- Old information is removed or deprecated.
- Experimental claims are identified.
- Marketing superlatives are avoided.
- Keywords are not artificially stuffed into primitives.
- Duplicate primitives are removed.
- The complete file remains reasonably maintainable.
- Sensitive or private information is excluded.
- Legal, medical and financial statements receive appropriate review where applicable.
Common Mistakes to Avoid
Mistake 1: Turning It Into an FAQ Dump
Answer Primitives are not simply FAQs stored in JSON.
FAQ objects can form part of the architecture, but primitives can also represent:
- facts
- relationships
- constraints
- comparisons
- procedures
- quantitative data
- evidence
- temporal states
Think in terms of knowledge units rather than only questions.
Mistake 2: Copying Entire Webpages Into JSON
A 2,000-word article stored inside one JSON field is not an answer primitive.
The purpose is decomposition.
Extract the important knowledge units.
Mistake 3: Keyword Stuffing
Do not create primitives such as:
{
“keywords”: [
“best AI SEO company”,
“top AI SEO company”,
“number one AI SEO company”,
“leading AI SEO agency”
]
}
This contributes little to structured knowledge and may reduce quality.
Mistake 4: Unsupported Claims
Avoid statements such as:
“The world’s best AI SEO company.”
unless there is a clearly defined, verifiable basis for the assertion.
Use factual language.
Mistake 5: Missing Context
Bad:
{
“statement”: “It costs $500.”
}
What costs $500?
Under which conditions?
Which currency?
Which period?
Better:
{
“type”: “price”,
“subject”: “Example Service”,
“value”: 500,
“currency”: “USD”,
“billingPeriod”: “month”,
“lastVerified”: “2026-09-03”
}
Mistake 6: Treating Custom JSON as a Guaranteed Ranking Factor
Do not claim that adding ai-answer-primitives.json will automatically improve rankings in Google, ChatGPT, Gemini, Claude, Perplexity or another third-party system.
Its immediate value is as structured AI and knowledge infrastructure.
Any external discovery or use depends on the behaviour and capabilities of the consuming system.
Mistake 7: Ignoring Contradictions
A primitive should not say:
The service is available worldwide.
while the website says:
Available only in the United States.
Machine-readable files should reflect authoritative website information.
Mistake 8: Missing Freshness
Prices, statistics, policies and product features change.
Include dates where the truth is time-sensitive.
Mistake 9: Creating Orphan Primitives
Important primitives should connect to:
- entities
- canonical URLs
- evidence
- related primitives
where appropriate.
Otherwise, the system receives isolated facts without sufficient semantic context.
Mistake 10: Excessive Nesting
Complex JSON is not automatically better JSON.
Keep the structure predictable.
Implementation Steps
Step 1: Audit Existing Content
Collect important information from:
- homepage
- service pages
- product pages
- About page
- FAQs
- support documentation
- research
- case studies
- policies
- knowledge base
- technical documentation
Step 2: Identify High-Value Questions
Determine what users and AI systems are likely to need to know.
Examples:
- What is the organisation?
- What does it offer?
- What is each service?
- Who is the service for?
- How do two services differ?
- What does a framework do?
- What are the requirements?
- What are the limitations?
Step 3: Break Knowledge Into Atomic Units
Convert long explanations into individual knowledge objects.
Do not copy text mechanically.
Each primitive should have a clear purpose.
Step 4: Assign Primitive Types
Classify each object as:
- definition
- fact
- comparison
- benefit
- process
- limitation
- requirement
- evidence
- relationship
- use_case
or another controlled type.
Step 5: Connect Canonical Entities
Reference official entity IDs when available.
Step 6: Add Answer Variants
Where helpful, include:
- short answer
- expanded answer
- question patterns
Step 7: Add Evidence
Connect important claims with authoritative supporting sources.
Step 8: Add Canonical URLs
Every important primitive should point to the best deeper source where appropriate.
Step 9: Add Freshness Metadata
Identify facts that can expire.
Add:
- lastVerified
- validFrom
- validUntil
- status
where relevant.
Step 10: Validate the JSON
Check:
- syntax
- IDs
- URLs
- duplicates
- references
- dates
- unsupported claims
Step 11: Publish the File
Publish:
/ai-answer-primitives.json
Step 12: Connect It to the AI Discovery Stack
Where appropriate, reference the file from:
- llms.txt
- ai.txt
- ai-endpoints.json
- brand-memory.json
- entity-registry.json
- knowledge-graph.json
- internal AI documentation
- MCP resources
- RAG ingestion pipelines
Step 13: Maintain It
Update primitives whenever authoritative knowledge changes.
Example llms.txt Reference
# AI Answer Primitives
Machine-readable answer primitives are available at:
https://example.com/ai-answer-primitives.json
The resource contains structured definitions, facts, comparisons, procedures, limitations, evidence references and reusable answer components intended for AI retrieval and knowledge applications.
Example ai.txt Reference
# Machine-Readable AI Knowledge
Answer Primitives:
https://example.com/ai-answer-primitives.json
Brand Memory:
https://example.com/brand-memory.json
Entity Registry:
https://example.com/entity-registry.json
Knowledge Graph:
https://example.com/knowledge-graph.json
Example robots.txt Reference
A comment can document the location for developers or systems that inspect the file:
# AI Knowledge Resources
# Answer Primitives: https://example.com/ai-answer-primitives.json
# Brand Memory: https://example.com/brand-memory.json
# Entity Registry: https://example.com/entity-registry.json
# Knowledge Graph: https://example.com/knowledge-graph.json
A robots.txt comment is documentation.
It should not be interpreted as a standard mechanism that forces crawlers to ingest the referenced JSON resource.
Strategic Value for Brands
Search is moving from a page-only model toward an environment where information can be retrieved, summarised, transformed and recombined by AI systems.
Traditional websites remain essential.
However, organisations can increasingly benefit from thinking about their information at multiple levels:
Page level
What complete resource should humans read?
Entity level
What person, company, product, framework or concept does this information describe?
Relationship level
How are those entities connected?
Memory level
What should an AI system remember about the organisation?
Answer level
What individual pieces of information can be used to respond to a question?
AI Answer Primitives address the final layer.
They create an organised inventory of answerable organisational knowledge.
For brands investing in:
- AI Visibility
- AEO
- GEO
- LLM SEO
- semantic search
- RAG
- enterprise AI
- knowledge management
- conversational search
- AI assistants
- machine-readable discovery
this can become a useful component of a wider AI discovery architecture.
Final Summary
ai-answer-primitives.json is a machine-readable knowledge resource designed to store compact, reusable answer components.
Instead of treating every webpage as one indivisible unit, it decomposes important knowledge into smaller objects such as:
- definitions
- facts
- comparisons
- capabilities
- benefits
- requirements
- limitations
- procedures
- relationships
- evidence
- contextual statements
- temporal facts
Each primitive can contain:
- a unique ID
- answer type
- canonical subject
- question patterns
- short answer
- expanded answer
- evidence
- entity references
- canonical URLs
- related primitives
- freshness metadata
- governance information
The file can complement:
- website content
- schema markup
- llms.txt
- ai.txt
- brand-memory.json
- entity-registry.json
- knowledge-graph.json
- vector feeds
- AI endpoints
- RAG pipelines
- semantic retrieval systems
It should not be positioned as a replacement for webpages.
It should not be positioned as a guaranteed ranking mechanism.
It should not be used to manufacture claims.
Its core value is architectural.
Webpages organise information for reading.
Entity registries organise identity.
Knowledge graphs organise relationships.
Brand Memory organises persistent organisational context.
AI Answer Primitives organise knowledge for answers.
As AI-assisted search and enterprise retrieval systems increasingly generate responses from retrieved information, organisations need to think not only about whether information exists, but whether the correct information can be found, understood, verified and assembled efficiently.
That is the role ai-answer-primitives.json is designed to address.
