SUPERCHARGE YOUR ONLINE VISIBILITY! CONTACT US AND LET’S ACHIEVE EXCELLENCE TOGETHER!
Artificial intelligence systems are moving beyond information retrieval.
They increasingly need to decide.
A traditional search engine may retrieve ten webpages.
A modern AI system may instead need to determine:
- which source should be trusted
- which answer should be preferred
- which recommendation is appropriate
- whether enough evidence exists
- whether an action should be taken
- whether a human should review the decision
- whether a policy prevents an action
- which alternative should be presented
- whether information is too old to use
- which product or service best matches a requirement
- whether uncertainty should be disclosed
- when an answer should be refused
- when an agent should stop
- when another knowledge source should be consulted
This represents an important shift.
The challenge is no longer only:
“Can the AI find the information?”
The next question becomes:
“What should the AI do with the information it finds?”
That is the purpose of an ai-decision-layer.json architecture.
The file can act as a structured machine-readable decision framework containing the rules, evidence requirements, constraints, priorities, confidence thresholds, escalation logic and preferred actions that an AI application can use when converting retrieved knowledge into a decision.
In simple terms:
ai-decision-layer.json defines how an AI-enabled system should move from knowledge to action.
It does not replace an LLM.
It does not replace a knowledge graph.
It does not replace RAG.
It does not automatically control third-party AI platforms.
Instead, it provides a structured decision-governance layer that AI agents, RAG systems, enterprise assistants, recommendation engines and controlled AI applications can potentially consume.
What Is ai-decision-layer.json?
ai-decision-layer.json is a machine-readable JSON resource designed to express decision logic for AI-enabled systems.
It can define:
- decision domains
- decision inputs
- required evidence
- eligibility conditions
- decision rules
- priorities
- constraints
- risk levels
- confidence thresholds
- permitted actions
- prohibited actions
- fallback behaviour
- escalation conditions
- source requirements
- recommendation criteria
- exception handling
- freshness requirements
- human-review requirements
- explanation requirements
- audit information
A simple decision object might look like this:
{
“decisionId”: “decision:service-recommendation:geo”,
“decisionType”: “recommendation”,
“subject”: “Generative Engine Optimization”,
“conditions”: [
{
“field”: “userGoal”,
“operator”: “includes”,
“value”: “AI search visibility”
}
],
“preferredAction”: {
“type”: “recommend”,
“target”: “service:geo”
},
“confidenceThreshold”: 0.80,
“requiresEvidence”: true
}
This does not tell an AI system everything about Generative Engine Optimization.
Other machine-readable resources can provide that knowledge.
Instead, the decision object answers a different question:
Under what circumstances should GEO become a relevant recommendation?
That difference is fundamental.
Why an AI Decision Layer Is Needed
Most AI information architectures focus heavily on knowledge.
They answer questions such as:
- What entities exist?
- What does the organisation offer?
- What sources are authoritative?
- What facts are available?
- Which content should be retrieved?
- How are entities related?
- What can be remembered?
- What answer components are available?
But knowledge alone does not define behaviour.
Consider an enterprise AI assistant that retrieves three facts:
User wants greater AI visibility.
The organisation provides GEO services.
The organisation also provides traditional SEO.
Retrieving those facts does not automatically determine what should happen next.
Should the AI:
- recommend GEO?
- recommend SEO?
- recommend both?
- ask another question?
- provide a comparison?
- avoid recommending anything because there is insufficient information?
Those are decision questions.
A decision layer can provide the logic between:
Knowledge
↓
Interpretation
↓
Decision
↓
Action
Without explicit decision architecture, the model itself may need to infer every decision from unstructured context.
In controlled enterprise AI systems, that can create:
- inconsistent recommendations
- unsupported assumptions
- policy violations
- excessive model discretion
- difficult auditing
- weak explainability
- contradictory outcomes
- overconfident answers
- outdated decisions
- poor escalation behaviour
A structured decision layer can help reduce these problems.
Knowledge Layer vs Decision Layer
Understanding this distinction is essential.
Knowledge Layer
The knowledge layer answers:
What is known?
It may contain:
- company information
- product specifications
- definitions
- relationships
- research
- evidence
- policies
- factual statements
Decision Layer
The decision layer answers:
Given what is known, what should happen?
It may contain:
- selection criteria
- conditions
- priorities
- thresholds
- exclusions
- recommendations
- escalation logic
- fallback behaviour
For example:
Knowledge
{
“product”: “Enterprise GEO”,
“recommendedFor”: [
“large websites”,
“enterprise brands”,
“AI visibility programmes”
]
}
Decision Logic
{
“decisionId”: “decision:geo-enterprise-fit”,
“conditions”: [
{
“field”: “organizationSize”,
“operator”: “equals”,
“value”: “enterprise”
},
{
“field”: “objective”,
“operator”: “includes”,
“value”: “AI visibility”
}
],
“action”: {
“type”: “prioritize”,
“target”: “product:enterprise-geo”
}
}
The first object describes the product.
The second describes when the product should become a preferred option.
How ai-decision-layer.json Fits Into an AI Knowledge Stack
A mature AI-readable website or enterprise knowledge system may contain multiple machine-readable layers.
Each solves a different problem.
entity-registry.json
Answers:
What entities exist and what are their canonical identities?
It focuses on:
- canonical names
- aliases
- IDs
- entity classes
- URLs
- relationships
It is identity-first.
knowledge-graph.json
Answers:
How are entities connected?
It focuses on:
- entity relationships
- predicates
- semantic connections
- ownership
- authorship
- topical associations
It is relationship-first.
brand-memory.json
Answers:
What should a system remember about the organisation?
It focuses on:
- brand identity
- expertise
- products
- people
- frameworks
- research
- long-term organisational context
It is memory-first.
ai-answer-primitives.json
Answers:
What reusable pieces of knowledge can contribute to an answer?
It focuses on:
- definitions
- facts
- comparisons
- limitations
- procedures
- evidence-backed answer components
It is answer-first.
reasoning-map.json
A reasoning map can describe:
How are concepts or reasoning paths connected?
It can provide structured reasoning relationships and potential inference paths.
It is reasoning-path-first.
context-engine.json
A context layer can answer:
What information should be considered relevant in this situation?
It may define contextual dimensions such as audience, market, intent, stage or environment.
It is context-first.
ai-decision-layer.json
The Decision Layer answers:
Given the available evidence and context, what decision or action should be selected?
It focuses on:
- conditions
- rules
- priorities
- thresholds
- exceptions
- recommendations
- permitted actions
- prohibited actions
- escalation
- governance
It is decision-first.
This creates an increasingly structured AI architecture:
IDENTITY
entity-registry.json
↓
KNOWLEDGE
knowledge-graph.json
↓
MEMORY
brand-memory.json
↓
CONTEXT
context-engine.json
↓
ANSWERS
ai-answer-primitives.json
↓
REASONING
reasoning-map.json
↓
DECISIONS
ai-decision-layer.json
↓
ACTION
AI Agent / Application
Not every system needs every layer.
However, the separation creates a useful conceptual architecture for sophisticated AI applications.
From Retrieval to Decision
Traditional Retrieval-Augmented Generation frequently follows a pattern similar to:
User Query
↓
Embedding
↓
Vector Search
↓
Relevant Documents
↓
Prompt Context
↓
LLM
↓
Answer
A decision-aware architecture can introduce additional stages.
User Query
↓
Intent Detection
↓
Entity Resolution
↓
Context Identification
↓
Knowledge Retrieval
↓
Evidence Evaluation
↓
Decision Rules
↓
Policy Constraints
↓
Action Selection
↓
LLM Response
The Decision Layer occupies the area between evidence and action.
This can be particularly valuable when an AI system must do more than explain information.
Examples include:
- recommending a service
- selecting a product
- routing a support request
- qualifying a lead
- deciding whether human approval is necessary
- deciding whether information is reliable enough to present
- choosing between multiple answers
- determining whether an automated action is permitted
Why AI Decisions Need Explicit Governance
LLMs are probabilistic systems.
Given slightly different context, wording or model settings, they may generate different outputs.
This flexibility is useful.
But decision consistency can matter greatly in enterprise environments.
Suppose a company deploys an AI sales assistant.
Two users ask almost identical questions.
User A receives:
Enterprise GEO is recommended.
User B receives:
Standard SEO is recommended.
If both users have the same requirements, the organisation may want to know why the recommendation changed.
A structured decision framework can make that logic more transparent.
For example:
{
“ruleId”: “rule:recommend-enterprise-geo”,
“conditions”: [
{
“field”: “monthlyOrganicTraffic”,
“operator”: “>”,
“value”: 500000
},
{
“field”: “goal”,
“operator”: “contains”,
“value”: “AI visibility”
}
],
“decision”: “recommend:enterprise-geo”
}
Now the recommendation is not based entirely on free-form generation.
There is explicit logic behind it.
Core Functions of ai-decision-layer.json
A sophisticated Decision Layer may perform several functions.
1. Eligibility
Determine whether an option qualifies.
Example:
{
“decisionType”: “eligibility”,
“rule”: {
“field”: “websiteStatus”,
“operator”: “equals”,
“value”: “live”
}
}
2. Selection
Choose among several options.
{
“decisionType”: “selection”,
“options”: [
“SEO”,
“AEO”,
“GEO”,
“LLM SEO”
]
}
3. Prioritisation
Rank actions or recommendations.
{
“decisionType”: “prioritization”,
“priorityOrder”: [
“technical-indexability”,
“entity-foundation”,
“content-coverage”,
“AI-visibility-expansion”
]
}
4. Risk Evaluation
Determine whether an action is high-risk.
{
“decisionType”: “risk_evaluation”,
“riskLevel”: “high”,
“requiresHumanReview”: true
}
5. Escalation
Determine whether an AI should hand the situation to a human.
6. Fallback
Define what happens when information is insufficient.
7. Recommendation
Select an appropriate service, product, answer or next step.
8. Suppression
Prevent inappropriate actions or recommendations.
9. Evidence Validation
Require sufficient supporting information before an answer is used.
10. Conflict Resolution
Define behaviour when sources disagree.
Core Design Principle: AI Should Know When Not to Decide
An important Decision Layer is not only about making more decisions.
It must also define when the system should not make one.
For example:
{
“decisionId”: “decision:insufficient-evidence”,
“trigger”: {
“evidenceCount”: {
“operator”: “<“,
“value”: 1
}
},
“action”: {
“type”: “abstain”
},
“fallback”: {
“type”: “request_more_information”
}
}
This introduces the concept of decision abstention.
Possible abstention conditions include:
- insufficient evidence
- contradictory evidence
- low confidence
- unavailable required input
- expired information
- unresolved entity identity
- policy restriction
- high-risk outcome
- unclear user intent
For trustworthy AI applications, abstention can be as important as decision-making.
Decision Architecture
A practical AI decision object may contain the following lifecycle:
Trigger
↓
Inputs
↓
Context
↓
Evidence
↓
Conditions
↓
Constraints
↓
Score / Threshold
↓
Decision
↓
Action
↓
Explanation
↓
Audit Record
Each stage serves a different function.
Recommended File Location
The simplest public location is:
https://example.com/ai-decision-layer.json
Alternative locations could include:
https://example.com/.well-known/ai-decision-layer.json
or:
https://example.com/ai/ai-decision-layer.json
The root location is generally the simplest when public discovery is intended.
For internal enterprise AI systems, the file may instead sit behind:
- authenticated APIs
- MCP servers
- internal knowledge systems
- agent configuration layers
- enterprise RAG infrastructure
Sensitive decision policies should not automatically be exposed publicly.
Recommended MIME Type
The file should normally be served as:
application/json
Example HTTP response:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Recommended technical conditions include:
- valid JSON syntax
- HTTP 200 response
- UTF-8 encoding
- stable rule IDs
- explicit versioning
- last-updated metadata
- consistent entity references
- validated URLs
- controlled rule changes
- change logging
- appropriate access controls for sensitive rules
Recommended Top-Level Structure
A mature file could include:
{
“metadata”: {},
“organization”: {},
“decisionDomains”: [],
“inputSchema”: {},
“evidencePolicy”: {},
“decisionRules”: [],
“priorities”: {},
“confidencePolicy”: {},
“riskPolicy”: {},
“conflictResolution”: {},
“fallbackPolicy”: {},
“escalationPolicy”: {},
“prohibitedDecisions”: [],
“explanationPolicy”: {},
“relatedResources”: {},
“governance”: {}
}
The exact architecture should depend on the application.
Field-by-Field Explanation
metadata
Defines information about the Decision Layer itself.
Example:
{
“metadata”: {
“version”: “2026.1”,
“fileType”: “ai-decision-layer”,
“generatedAt”: “2026-09-03”,
“lastUpdated”: “2026-09-03”,
“language”: “en”,
“publisher”: “ThatWare LLP”,
“canonicalUrl”: “https://thatware.co/ai-decision-layer.json”
}
}
Useful metadata may include:
- version
- publisher
- creation date
- update date
- language
- canonical URL
- schema version
- governance owner
- environment
Versioning becomes particularly important because changing a decision rule may change AI behaviour.
organization
Defines the organisation responsible for the rules.
{
“organization”: {
“id”: “entity:organization:thatware”,
“name”: “ThatWare”,
“legalName”: “ThatWare LLP”,
“url”: “https://thatware.co/”
}
}
This helps establish:
- ownership
- governance
- namespace consistency
- entity disambiguation
decisionDomains
Not every rule applies everywhere.
Decision domains can separate areas such as:
{
“decisionDomains”: [
“content”,
“service-selection”,
“recommendation”,
“research”,
“support”,
“lead-qualification”,
“AI-search”,
“risk”,
“citation”
]
}
This prevents rules designed for one scenario from accidentally affecting another.
decisionId
Every decision object should have a stable identifier.
Example:
{
“decisionId”: “decision:service:geo-fit”
}
Recommended naming may follow:
decision:<domain>:<subject>:<purpose>
Examples:
decision:service:geo:eligibility
decision:content:citation:selection
decision:support:human-escalation
decision:research:evidence-sufficiency
decision:ai-search:source-preference
Stable IDs support:
- auditing
- testing
- logging
- references
- version history
- debugging
decisionType
The decision type describes what the rule does.
Possible values include:
eligibility
selection
recommendation
ranking
routing
classification
approval
rejection
abstention
escalation
suppression
validation
risk_evaluation
Example:
{
“decisionType”: “recommendation”
}
trigger
A trigger determines when a decision rule becomes relevant.
Example:
{
“trigger”: {
“intent”: “service_recommendation”
}
}
Another example:
{
“trigger”: {
“event”: “insufficient_evidence”
}
}
Triggers could originate from:
- a user question
- an agent event
- retrieval results
- threshold changes
- workflow states
- data updates
- policy conditions
inputs
Inputs define which information the rule requires.
{
“requiredInputs”: [
“userGoal”,
“organizationSize”,
“websiteType”,
“currentVisibility”
]
}
The system should ideally distinguish required and optional fields.
{
“inputs”: {
“required”: [
“userGoal”
],
“optional”: [
“budget”,
“timeline”,
“market”
]
}
}
If a required input is unavailable, the system may need to ask for more information rather than infer it.
conditions
Conditions determine whether a rule applies.
Example:
{
“conditions”: [
{
“field”: “userGoal”,
“operator”: “contains”,
“value”: “AI visibility”
},
{
“field”: “organizationType”,
“operator”: “equals”,
“value”: “enterprise”
}
]
}
Useful operators may include:
equals
not_equals
contains
not_contains
greater_than
less_than
greater_than_or_equal
less_than_or_equal
in
not_in
exists
not_exists
Keep operators explicit.
Avoid burying important rules inside natural-language fields when they can be represented structurally.
evidenceRequirements
Some decisions should require supporting evidence.
Example:
{
“evidenceRequirements”: {
“minimumSources”: 2,
“primarySourcePreferred”: true,
“requireFreshEvidence”: true
}
}
Evidence requirements can depend on the decision type.
A basic informational recommendation may tolerate fewer constraints.
A high-stakes decision may need:
- multiple sources
- primary evidence
- recent verification
- human approval
sourcePriority
When multiple sources exist, source selection can matter.
Example:
{
“sourcePriority”: [
“official_documentation”,
“primary_research”,
“organization_website”,
“trusted_external_authority”,
“secondary_source”
]
}
This does not make a source correct merely because of its category.
It simply defines an evidence preference.
confidenceThreshold
Some controlled AI systems calculate confidence or evidence scores.
A Decision Layer may define minimum thresholds.
{
“confidenceThreshold”: {
“minimum”: 0.80,
“belowThresholdAction”: “abstain”
}
}
However, caution is essential.
A numeric confidence value should not be used unless the underlying system has a defined method for calculating it.
Avoid arbitrary fields such as:
{
“confidence”: 0.99
}
if the number has no methodology.
A better alternative may be categorical verification:
{
“verificationStatus”: “verified”
}
Possible values could include:
verified
supported
uncertain
conflicting
unverified
deprecated
priority
When multiple rules apply, priority determines precedence.
Example:
{
“priority”: 100
}
A system might establish:
Safety rules: 1000
Legal rules: 900
Compliance rules: 800
Evidence rules: 700
Business recommendations: 500
Formatting preferences: 100
The exact numbers matter less than maintaining predictable precedence.
action
The action describes what should happen when the decision succeeds.
Example:
{
“action”: {
“type”: “recommend”,
“target”: “service:geo”
}
}
Possible action types might include:
recommend
select
rank
route
approve
reject
abstain
ask_clarification
retrieve_more_evidence
escalate
suppress
display_warning
prohibitedActions
A robust decision system should also specify what must not happen.
Example:
{
“prohibitedActions”: [
“invent_missing_evidence”,
“represent_uncertain_claim_as_fact”,
“ignore_required_human_review”
]
}
Prohibited actions provide negative constraints.
This can be particularly important for autonomous agents.
fallback
The fallback determines what happens when the normal decision path cannot complete.
Example:
{
“fallback”: {
“when”: “required_input_missing”,
“action”: “request_more_information”
}
}
Another:
{
“fallback”: {
“when”: “sources_conflict”,
“action”: “present_uncertainty”
}
}
Possible fallbacks include:
- ask for clarification
- retrieve additional sources
- abstain
- escalate
- provide alternatives
- display uncertainty
- stop execution
escalation
Escalation sends the decision to another process or a human.
{
“escalation”: {
“requiredWhen”: [
“high_risk”,
“conflicting_evidence”,
“policy_exception”
],
“target”: “human_review”
}
}
This can be particularly important for:
- finance
- healthcare
- legal applications
- account security
- enterprise procurement
- compliance
- high-value transactions
explanation
Good decision systems should not only record what happened.
They should also preserve why.
Example:
{
“explanationPolicy”: {
“required”: true,
“include”: [
“matchedRules”,
“evidenceUsed”,
“constraintsApplied”
]
}
}
A decision explanation might say:
GEO was prioritised because the stated objective was AI search visibility and the organisation matched the enterprise profile defined by the service-fit rules.
Explainability supports:
- debugging
- auditing
- human review
- trust
- regulatory analysis
- quality assurance
audit
Decision systems should maintain traceability.
{
“audit”: {
“logRuleMatches”: true,
“logEvidence”: true,
“logFinalAction”: true,
“retainVersion”: true
}
}
A future reviewer should ideally be able to determine:
- which rule fired
- which version was active
- what evidence was available
- which conditions matched
- what decision resulted
Decision Rule Example
A complete rule could look like:
{
“decisionId”: “decision:service:geo:recommendation”,
“decisionType”: “recommendation”,
“trigger”: {
“intent”: “service_selection”
},
“inputs”: {
“required”: [
“businessGoal”
],
“optional”: [
“organizationSize”,
“currentSEOStatus”
]
},
“conditions”: [
{
“field”: “businessGoal”,
“operator”: “contains”,
“value”: “AI visibility”
}
],
“evidenceRequirements”: {
“requireServiceDefinition”: true
},
“action”: {
“type”: “recommend”,
“target”: “service:geo”
},
“fallback”: {
“when”: “businessGoal_unclear”,
“action”: “request_more_information”
},
“explanationRequired”: true,
“status”: “active”
}
Complete Example ai-decision-layer.json
Below is a simplified conceptual implementation.
{
“metadata”: {
“version”: “2026.1”,
“fileType”: “ai-decision-layer”,
“generatedAt”: “2026-09-03”,
“lastUpdated”: “2026-09-03”,
“language”: “en”,
“publisher”: “ThatWare LLP”,
“canonicalUrl”: “https://thatware.co/ai-decision-layer.json”,
“description”: “Machine-readable decision rules, policies, priorities, evidence requirements and escalation logic for AI-enabled retrieval, recommendation and agent workflows.”
},
“organization”: {
“id”: “entity:organization:thatware”,
“name”: “ThatWare”,
“legalName”: “ThatWare LLP”,
“url”: “https://thatware.co/”
},
“decisionDomains”: [
“AI search”,
“service recommendation”,
“answer generation”,
“evidence selection”,
“citation”,
“human escalation”
],
“globalPolicies”: {
“requireEvidenceForFactualClaims”: true,
“doNotInventMissingInformation”: true,
“preferCanonicalSources”: true,
“discloseMaterialUncertainty”: true,
“respectFreshnessRequirements”: true
},
“decisionRules”: [
{
“decisionId”: “decision:service:geo-fit”,
“decisionType”: “recommendation”,
“trigger”: {
“intent”: “service_selection”
},
“conditions”: [
{
“field”: “goal”,
“operator”: “contains”,
“value”: “AI visibility”
}
],
“action”: {
“type”: “prioritize”,
“target”: “entity:service:geo”
},
“fallback”: {
“when”: “insufficient_context”,
“action”: “request_more_information”
},
“status”: “active”
},
{
“decisionId”: “decision:evidence:insufficient”,
“decisionType”: “abstention”,
“trigger”: {
“event”: “evidence_evaluation”
},
“conditions”: [
{
“field”: “evidenceStatus”,
“operator”: “equals”,
“value”: “insufficient”
}
],
“action”: {
“type”: “abstain”
},
“fallback”: {
“action”: “retrieve_more_evidence”
},
“status”: “active”
},
{
“decisionId”: “decision:evidence:conflict”,
“decisionType”: “escalation”,
“trigger”: {
“event”: “source_conflict”
},
“conditions”: [
{
“field”: “materialConflict”,
“operator”: “equals”,
“value”: true
}
],
“action”: {
“type”: “display_uncertainty”
},
“secondaryAction”: {
“type”: “retrieve_primary_source”
},
“status”: “active”
},
{
“decisionId”: “decision:source:canonical-priority”,
“decisionType”: “ranking”,
“priorityOrder”: [
“primary_source”,
“official_documentation”,
“verified_research”,
“trusted_secondary_source”
],
“status”: “active”
},
{
“decisionId”: “decision:human-review:high-risk”,
“decisionType”: “escalation”,
“conditions”: [
{
“field”: “riskLevel”,
“operator”: “equals”,
“value”: “high”
}
],
“action”: {
“type”: “escalate”,
“target”: “human_review”
},
“autonomousExecutionAllowed”: false,
“status”: “active”
}
],
“confidencePolicy”: {
“allowAutomaticDecision”: “supported”,
“requireAdditionalEvidence”: “uncertain”,
“abstain”: “unverified”,
“escalate”: “conflicting”
},
“conflictResolution”: {
“preferPrimarySources”: true,
“neverSilentlyDiscardMaterialConflict”: true,
“retrieveAdditionalEvidence”: true,
“discloseUnresolvedConflict”: true
},
“fallbackPolicy”: {
“missingInput”: “request_more_information”,
“insufficientEvidence”: “retrieve_more_evidence”,
“unresolvedConflict”: “display_uncertainty”,
“highRisk”: “human_review”
},
“prohibitedDecisions”: [
“unsupported factual assertion”,
“fabricated evidence”,
“automatic high-risk decision without required review”
],
“explanationPolicy”: {
“required”: true,
“includeMatchedRules”: true,
“includeEvidenceReferences”: true,
“includeMaterialConstraints”: true
},
“relatedResources”: {
“entityRegistry”: “https://thatware.co/entity-registry.json”,
“brandMemory”: “https://thatware.co/brand-memory.json”,
“answerPrimitives”: “https://thatware.co/ai-answer-primitives.json”,
“knowledgeGraph”: “https://thatware.co/knowledge-graph.json”,
“reasoningMap”: “https://thatware.co/reasoning-map.json”,
“contextEngine”: “https://thatware.co/context-engine.json”
},
“governance”: {
“ruleChangesRequireReview”: true,
“maintainVersionHistory”: true,
“testBeforeProduction”: true,
“auditDecisionOutputs”: true
}
}
A production implementation may be significantly more sophisticated.
Decision Rules vs Hardcoded Prompts
Many AI applications currently encode business logic directly into prompts.
For example:
If the user is an enterprise customer interested in AI search, recommend the GEO service.
This can work.
However, as decision logic grows, prompts can become difficult to manage.
A structured Decision Layer provides several advantages.
Rules Become Explicit
Instead of hiding logic inside thousands of tokens of prompting, decisions have identifiable objects.
Rules Become Testable
Individual rules can be evaluated independently.
Rules Become Versionable
A change can be associated with:
version 2026.2
Rules Become Auditable
A system can record:
Matched rule:
decision:service:geo-fit
Rules Become Reusable
The same decision policy could potentially be consumed by:
- website assistants
- sales assistants
- internal copilots
- support systems
- RAG applications
This does not mean prompts become unnecessary.
The Decision Layer complements model instructions.
AI Decision Layer and RAG
RAG helps an AI system retrieve external information.
Decision logic determines what should happen after retrieval.
Consider the question:
Which ThatWare service is suitable for increasing visibility in generative AI search?
A retrieval system might locate information about:
- SEO
- AEO
- GEO
- LLM SEO
- AI Visibility
RAG retrieves the candidates.
The Decision Layer can then evaluate:
Primary user objective = generative AI visibility
↓
Relevant services identified
↓
GEO relevance = high
LLM SEO relevance = high
Traditional SEO relevance = supporting
↓
Decision
↓
Explain GEO and LLM SEO as the most directly aligned options
This separates retrieval relevance from recommendation logic.
AI Decision Layer and AI Answer Primitives
These two resources complement each other particularly well.
Answer Primitives provide:
What can be said?
Decision Layer provides:
Which answer component should be selected in this situation?
Suppose Answer Primitives contain:
primitive:geo:definition
primitive:geo:benefit
primitive:geo:limitation
primitive:seo:definition
primitive:llm-seo:definition
A Decision Layer may choose:
User asks “What is GEO?”
↓
Select primitive:geo:definition
Another question:
“Is GEO guaranteed to make ChatGPT recommend my company?”
The Decision Layer may select:
primitive:geo:limitation
This makes answer selection more intentional.
AI Decision Layer and context-engine.json
Context changes decisions.
Imagine two users ask:
Which service should I choose?
User A:
Small local business
Primary objective: Google Maps visibility
User B:
Global enterprise
Primary objective: citations in generative AI systems
The answer should probably not be identical.
The Context Engine can identify:
business size
market
objective
audience
search environment
The Decision Layer can then use that context.
Architecture:
Context Engine
↓
Decision Layer
↓
Recommendation
AI Decision Layer and reasoning-map.json
Reasoning and decision-making are related but not identical.
A reasoning map may express:
Generative visibility
↓ influenced by
Entity clarity
Authority
Retrievability
Citation support
The Decision Layer may then use those relationships to determine:
Entity clarity is weak
↓
Prioritise entity remediation before advanced AI visibility expansion
The Reasoning Map describes why concepts are connected.
The Decision Layer determines what to do because of those relationships.
AI Decision Layer and Knowledge Graphs
A knowledge graph might know:
ThatWare
provides
GEO Service
GEO Service
relates to
Generative Search
Generative Search
relates to
AI Visibility
A Decision Layer can use those relationships as inputs.
For example:
User goal = AI Visibility
↓
Graph traversal
↓
Related service = GEO
↓
Decision rule validates fit
↓
Recommendation generated
Graph retrieval discovers relationships.
Decision logic evaluates them.
AI Decision Layer and AI Agents
AI agents make the Decision Layer especially important.
A chatbot may only produce text.
An agent can potentially:
- search
- retrieve documents
- create files
- call APIs
- update systems
- execute workflows
- make purchases
- submit forms
- modify records
When an AI system can take actions, decision governance becomes significantly more important.
A Decision Layer could define:
{
“actionPolicy”: {
“read”: {
“permission”: “automatic”
},
“draft”: {
“permission”: “automatic”
},
“send”: {
“permission”: “requires_user_confirmation”
},
“delete”: {
“permission”: “requires_explicit_authorization”
}
}
}
This creates a structured difference between:
Can the AI perform the action?
and:
Is the AI permitted to perform the action now?
Autonomous Action Boundaries
Decision architecture should define action boundaries.
Possible levels could be:
Level 0: Informational
AI may retrieve and explain information.
Level 1: Suggestive
AI may recommend a next action.
Level 2: Preparatory
AI may prepare an action but not execute it.
Example:
Draft an email.
Level 3: Confirmed Execution
AI may act after explicit approval.
Level 4: Delegated Execution
AI may act autonomously within clearly defined boundaries.
High-risk systems should use more restrictive defaults.
Recommendation Rules
AI-generated recommendations can strongly influence user decisions.
Recommendation rules should therefore consider:
- relevance
- evidence
- suitability
- user constraints
- availability
- conflicts of interest
- freshness
- risk
- limitations
A recommendation should not simply optimise for whichever product the organisation wants to sell most.
For example:
{
“recommendationPolicy”: {
“prioritizeUserFit”: true,
“requireRelevantEvidence”: true,
“discloseMaterialLimitations”: true,
“doNotRecommendUnavailableProducts”: true
}
}
This improves reliability.
Evidence-Based Decision Making
A decision should ideally be traceable to evidence.
Example:
{
“decisionId”: “decision:recommend:geo”,
“evidence”: [
“primitive:user-goal:ai-visibility”,
“primitive:geo:use-case”,
“entity:service:geo”
]
}
The system now has a path:
Input
↓
Evidence
↓
Rule
↓
Decision
This is significantly easier to inspect than opaque generation.
Decision Provenance
Decision provenance records where the decision came from.
A provenance object might include:
{
“provenance”: {
“decisionRule”: “decision:service:geo-fit”,
“ruleVersion”: “2026.1”,
“sources”: [
“https://example.com/geo/”
],
“evaluatedAt”: “2026-09-03T10:00:00Z”
}
}
Provenance is valuable for:
- audit trails
- debugging
- regulatory review
- quality assurance
- incident investigation
Handling Conflicting Evidence
AI systems regularly encounter conflicting information.
Example:
Source A: Product supports 50 integrations.
Source B: Product supports 70 integrations.
The system should not arbitrarily select one.
The Decision Layer can define:
{
“conflictResolution”: {
“firstAction”: “check_freshness”,
“secondAction”: “prefer_primary_source”,
“thirdAction”: “retrieve_additional_evidence”,
“unresolvedAction”: “disclose_conflict”
}
}
This produces more transparent behaviour.
Freshness-Aware Decisions
A fact can be correct but obsolete.
Decision systems should therefore understand freshness.
Example:
{
“freshnessPolicy”: {
“pricing”: {
“maximumAgeDays”: 30
},
“serviceAvailability”: {
“maximumAgeDays”: 7
},
“companyHistory”: {
“maximumAgeDays”: 365
}
}
}
The actual periods depend on the domain.
A useful principle is:
The faster information changes, the shorter its acceptable verification window should be.
Decision Risk Levels
Not all decisions have equal consequences.
A basic framework could classify:
low
medium
high
critical
Example:
{
“riskPolicy”: {
“low”: {
“humanReview”: false
},
“medium”: {
“humanReview”: “optional”
},
“high”: {
“humanReview”: true
},
“critical”: {
“automaticExecution”: false,
“humanReview”: true
}
}
}
Risk can depend on:
- financial impact
- health impact
- legal impact
- privacy
- security
- irreversible actions
- account permissions
- reputational consequences
Decision Hierarchy
Some rules must override others.
A useful hierarchy could be:
Safety
↓
Legal / Compliance
↓
Security / Privacy
↓
Evidence Integrity
↓
User Intent
↓
Business Logic
↓
Optimisation Preferences
↓
Formatting
For example, a sales rule should never override a compliance restriction.
Decision hierarchy makes that explicit.
Hard Constraints vs Soft Preferences
Decision systems should distinguish between rules that must be obeyed and preferences that may be overridden.
Hard Constraint
{
“constraintType”: “hard”,
“rule”: “do_not_expose_private_data”
}
Soft Preference
{
“constraintType”: “soft”,
“rule”: “prefer_shorter_response”
}
This distinction prevents low-priority optimisation goals from overriding critical requirements.
Decision Scoring
Some situations may involve multiple candidate options.
A scoring model can help.
Example:
{
“scoring”: {
“criteria”: [
{
“name”: “intentMatch”,
“weight”: 0.40
},
{
“name”: “evidenceStrength”,
“weight”: 0.30
},
{
“name”: “contextFit”,
“weight”: 0.20
},
{
“name”: “freshness”,
“weight”: 0.10
}
]
}
}
But numerical weights should only be used when the organisation has a reason for them.
Do not create artificial mathematical precision merely because JSON supports numbers.
Multi-Stage Decision Architecture
Complex systems may use multiple decision stages.
For example:
Stage 1
Classify Intent
Stage 2
Identify Candidate Knowledge
Stage 3
Verify Evidence
Stage 4
Evaluate Policy
Stage 5
Rank Options
Stage 6
Select Action
Stage 7
Validate Risk
Stage 8
Generate Explanation
Each stage can have independent rules.
This architecture is easier to test than one enormous decision object.
Human-in-the-Loop Decision Making
Some decisions should remain collaborative.
Human-in-the-loop systems combine:
AI recommendation
+
Human judgment
Example:
{
“humanReviewPolicy”: {
“requiredFor”: [
“high_risk_decision”,
“large_financial_commitment”,
“legal_interpretation”,
“material_policy_exception”
]
}
}
The AI can still:
- collect evidence
- classify the situation
- prepare recommendations
- explain trade-offs
But a human makes the final decision.
Decision Explanation Template
A useful explanation format could contain:
{
“decisionExplanation”: {
“decision”: “GEO prioritised”,
“because”: [
“The user objective includes AI search visibility.”,
“The GEO service is directly associated with generative search visibility.”
],
“evidence”: [
“service:geo”,
“primitive:geo:use-case”
],
“limitations”: [
“The recommendation does not guarantee visibility on third-party AI platforms.”
]
}
}
This creates transparent recommendation logic.
Business Use Cases
AI Search and GEO
Decision rules can determine:
- which AI-search strategy should be prioritised
- which pages need entity work
- which citations require strengthening
- when content needs answer restructuring
Customer Support
The Decision Layer can route:
Billing query → Billing support
Technical issue → Technical support
Account security → Security escalation
Ecommerce
Rules can support:
- product recommendations
- compatibility checks
- availability decisions
- return eligibility
SaaS
Rules can identify:
- appropriate plans
- feature eligibility
- upgrade recommendations
- integration compatibility
Finance
Decision architectures may support preliminary classification or routing, but high-stakes financial decisions require appropriate professional, legal and regulatory controls.
Healthcare
AI systems can potentially use decision logic for administrative routing or information support, but clinical decisions require substantially stronger governance, qualified oversight and applicable regulatory controls.
Enterprise Procurement
Decision rules can evaluate:
- vendor criteria
- mandatory requirements
- technical fit
- compliance status
- evidence completeness
AI Search Recommendation Architecture
For GEO and AEO environments, the Decision Layer can model why an entity should be considered relevant.
Imagine an internal recommendation system evaluating providers.
It may examine:
Query Intent
↓
Entity Relevance
↓
Topical Expertise
↓
Evidence
↓
Trust Signals
↓
Citation Authority
↓
Freshness
↓
Decision Rule
↓
Recommendation Candidate
This can help organisations analyse recommendation logic in their own AI systems.
However, publishing such a file does not cause ChatGPT, Gemini, Google, Claude, Perplexity or another external AI system to adopt those recommendations.
The file represents architecture, not external platform control.
Does ai-decision-layer.json Influence Google Rankings?
There is no established basis for claiming that a custom ai-decision-layer.json file is a direct Google ranking factor.
Google does not currently document this file as a standard ranking protocol.
The resource should therefore not be promoted as:
Upload this JSON file and improve Google rankings.
Its direct utility exists primarily within:
- controlled AI systems
- RAG architecture
- enterprise agents
- decision-support systems
- machine-readable knowledge stacks
- custom recommendation systems
- structured AI governance
Any future third-party discovery depends on whether external systems choose to support or ingest such resources.
Does ChatGPT Automatically Read ai-decision-layer.json?
A website should not assume that ChatGPT automatically discovers or follows a custom decision JSON file.
The same applies to:
- Gemini
- Claude
- Perplexity
- Copilot
- Grok
- other public AI systems
The file becomes directly actionable when a system:
- explicitly loads it
- indexes it
- retrieves it
- connects through an API
- accesses it through an MCP system
- includes it inside a RAG architecture
This distinction should remain clear.
Public vs Private Decision Layers
Not every decision rule belongs on a public website.
Public Rules
Potentially suitable public information might include:
- source preferences
- content governance
- general recommendation logic
- evidence principles
- public citation preferences
Private Rules
Internal resources may contain:
- proprietary scoring
- commercial thresholds
- fraud signals
- security logic
- account controls
- internal escalation pathways
- confidential pricing
- private user information
Those should generally remain protected.
An enterprise may therefore maintain:
Public:
https://example.com/ai-decision-layer.json
Private:
Internal authenticated decision service
The public file can describe principles without exposing sensitive operating logic.
Version Control
Decision rules affect behaviour.
Changes should therefore be versioned.
Example:
{
“version”: “2026.2”,
“previousVersion”: “2026.1”
}
A changelog might record:
{
“changes”: [
{
“date”: “2026-09-03”,
“rule”: “decision:service:geo-fit”,
“change”: “Updated evidence requirement.”
}
]
}
This supports accountability.
Testing Decision Rules
Rules should be tested before deployment.
A test case might contain:
{
“testId”: “test:geo-fit:001”,
“inputs”: {
“goal”: “Increase AI search visibility”
},
“expectedDecision”: “recommend:geo”
}
Another:
{
“testId”: “test:geo-fit:002”,
“inputs”: {
“goal”: “Improve local map rankings”
},
“expectedDecision”: “do_not_prioritize:geo”
}
Automated tests can identify unexpected behavioural changes.
Decision Evaluation Metrics
Possible evaluation metrics include:
- decision accuracy
- rule match accuracy
- recommendation relevance
- escalation precision
- false approval rate
- false rejection rate
- abstention quality
- evidence sufficiency
- policy compliance
- explanation completeness
- outcome consistency
The metric should correspond to the actual decision domain.
Common Mistakes to Avoid
Mistake 1: Treating the File as an AI Ranking Hack
Do not position:
/ai-decision-layer.json
as a guaranteed shortcut to AI visibility.
Its primary purpose is structured decision architecture.
Mistake 2: Encoding Marketing Bias as Decision Logic
A rule such as:
Always recommend our most expensive service.
is not useful decision intelligence.
Recommendation logic should consider genuine user fit.
Mistake 3: Allowing Decisions Without Evidence
Important decisions should not be generated from unsupported assumptions.
Mistake 4: No Abstention Path
A decision system that must always answer may produce unreliable outcomes.
Include:
abstain
retrieve_more_information
request_clarification
escalate
where appropriate.
Mistake 5: Ignoring Conflicting Evidence
Do not silently choose whichever source produces the preferred outcome.
Mistake 6: Using Arbitrary Confidence Scores
A number such as:
0.97 confidence
is meaningless unless a defined calculation produces it.
Mistake 7: No Rule Priority
Two rules may contradict one another.
Priority must be defined.
Mistake 8: Mixing Knowledge With Decisions
Avoid storing entire encyclopaedic descriptions inside decision rules.
Keep factual knowledge in appropriate knowledge resources.
Mistake 9: Exposing Sensitive Rules
Security, fraud detection and proprietary commercial logic should not automatically be published publicly.
Mistake 10: No Version Control
Changing decision logic without versioning makes auditing difficult.
Mistake 11: No Human Escalation
High-risk automation should not be treated like low-risk informational routing.
Mistake 12: Overengineering
Not every website needs thousands of decision rules.
Start with the decisions that genuinely matter.
Implementation Process
Step 1: Identify Decision Use Cases
Ask:
- What decisions does the AI application need to make?
- Which decisions currently depend on human interpretation?
- Where does recommendation inconsistency occur?
- Which actions have material consequences?
Step 2: Separate Knowledge From Decision Logic
Identify:
What is true?
versus:
What should happen because it is true?
Keep these separate.
Step 3: Define Inputs
List the information each decision needs.
Example:
Goal
Industry
Business size
Market
Current state
Available evidence
Step 4: Define Conditions
Convert business logic into explicit rules.
Step 5: Define Actions
Every decision should have a clear outcome.
Step 6: Define Fallback Behaviour
Specify what happens when:
- data is missing
- evidence is weak
- sources conflict
- no rule matches
Step 7: Add Risk Controls
Classify high-impact decisions.
Step 8: Add Human Review
Identify where final authority should remain with a person.
Step 9: Link Knowledge Sources
Connect decisions with:
- entities
- answer primitives
- research
- canonical pages
- knowledge graph nodes
Step 10: Add Explanation Requirements
A system should ideally be capable of explaining why a recommendation occurred.
Step 11: Validate JSON
Check:
- syntax
- IDs
- references
- operators
- rule conflicts
- unreachable actions
- missing fallbacks
Step 12: Test Rules
Create expected-input and expected-output scenarios.
Step 13: Publish or Integrate
Depending on the use case:
Public website
API
RAG pipeline
MCP server
Agent configuration
Enterprise knowledge environment
Step 14: Monitor Decisions
Evaluate whether results remain accurate and useful.
Step 15: Version Changes
Every material rule change should be documented.
Validation Checklist
Before deploying ai-decision-layer.json, verify:
- JSON syntax is valid.
- Metadata is present.
- Version is identified.
- Last-updated date is correct.
- Decision IDs are unique.
- Decision types are consistent.
- Triggers are explicit.
- Required inputs are identified.
- Operators are valid.
- Conditions are testable.
- Evidence requirements are defined.
- Important recommendations require evidence.
- Rule priorities are clear.
- Prohibited actions are defined where necessary.
- Fallback behaviour exists.
- Abstention is supported.
- Conflict resolution exists.
- High-risk actions require review.
- Human escalation is available where appropriate.
- Freshness requirements are defined.
- Sensitive rules are protected.
- Related entity references exist.
- Referenced primitives exist.
- Canonical URLs are valid.
- Decisions are explainable.
- Rule changes are versioned.
- Test cases exist.
- Marketing objectives do not override evidence or policy.
- Deprecated rules are removed or clearly marked.
- The system does not claim control over external AI platforms.
Example Connection With ai-endpoints.json
An endpoint registry could expose:
{
“resources”: {
“decisionLayer”: “https://example.com/ai-decision-layer.json”,
“answerPrimitives”: “https://example.com/ai-answer-primitives.json”,
“brandMemory”: “https://example.com/brand-memory.json”,
“entityRegistry”: “https://example.com/entity-registry.json”
}
}
The endpoint file identifies resources.
The Decision Layer contains the behavioural logic.
Example Connection With ai.txt
A machine-readable AI resource index might include:
# AI Decision Resources
Decision Layer:
https://example.com/ai-decision-layer.json
Answer Primitives:
https://example.com/ai-answer-primitives.json
Entity Registry:
https://example.com/entity-registry.json
Knowledge Graph:
https://example.com/knowledge-graph.json
This is discovery documentation.
It does not guarantee that external crawlers or AI systems will consume the files.
Example Connection With llms.txt
An llms.txt resource may reference:
## AI Decision Layer
Machine-readable AI decision and governance information:
https://example.com/ai-decision-layer.json
Again, this is best understood as machine-oriented documentation rather than a mechanism that forces model behaviour.
Strategic Value of an AI Decision Layer
The evolution of web architecture can be viewed as several layers.
First Layer: Documents
Webpages provide information.
Second Layer: Structured Data
Schema helps machines identify what those pages represent.
Third Layer: Entities
Entity systems clarify identity.
Fourth Layer: Knowledge
Knowledge graphs connect information.
Fifth Layer: Retrieval
Vector indexes and RAG systems determine what information should be retrieved.
Sixth Layer: Answers
Answer primitives organise reusable response components.
Seventh Layer: Decisions
The Decision Layer determines what should happen after the information has been interpreted.
This seventh layer becomes increasingly important as AI systems shift from:
Answering
to:
Recommending
and eventually:
Acting
AI agents particularly require this distinction.
A system capable of taking action needs more than knowledge.
It requires boundaries.
From AI-Readable to AI-Governable
A machine-readable website tells an AI:
Here is our information.
A machine-understandable knowledge graph tells an AI:
Here is how the information is connected.
Answer Primitives tell an AI:
Here are reusable pieces of knowledge.
A Context Engine tells an AI:
Here is what matters in this situation.
A Reasoning Map tells an AI:
Here are relevant conceptual relationships.
An AI Decision Layer tells an AI:
Given those facts, this is how the decision should be evaluated.
That represents a shift from AI-readable information toward AI-governable behaviour.
Final Summary
ai-decision-layer.json is a proposed machine-readable architecture for expressing the decision logic that sits between AI knowledge retrieval and AI action.
It can define:
- decision domains
- triggers
- inputs
- conditions
- evidence requirements
- priorities
- confidence requirements
- risk levels
- actions
- prohibited actions
- fallback behaviour
- abstention
- escalation
- conflict resolution
- human review
- explanation requirements
- decision provenance
- audit policies
Its role can be summarised simply.
Entity Registry
Defines what something is.
Knowledge Graph
Defines how things are related.
Brand Memory
Defines what should be remembered.
Context Engine
Defines what matters in the current situation.
Answer Primitives
Define what can be said.
Reasoning Map
Defines relevant reasoning relationships.
Decision Layer
Defines what should happen.
The Decision Layer does not replace human judgment.
It does not automatically control public LLMs.
It is not a confirmed search ranking factor.
Its value is architectural.
As AI systems become increasingly capable of recommending products, selecting information, routing workflows and performing actions, enterprises need mechanisms for deciding:
- which evidence is sufficient
- which rules apply
- which actions are permitted
- when uncertainty should be disclosed
- when automation should stop
- when human judgment is required
The future of AI infrastructure is therefore not only about making information machine-readable.
It is about making decisions machine-governable.
That is the role the ai-decision-layer.json framework is designed to support.
