The Problem: Detection Without Comprehension
We recently ran an experiment. We asked several AI systems to analyze RecipeAlchemy.ai — a product that makes specific, differentiated claims about how it handles nutrition data. The results were instructive.
Every AI system we tested detected that RecipeAlchemy had an llms.txt file. But none of them actually parsed its contents deeply. The reviews were generic: "AI recipe tool with nutrition features." This classification could apply to any of a hundred competitors.
The actual differentiator — that RecipeAlchemy architecturally prevents its LLM from generating nutrition numbers, sourcing all values exclusively from USDA FoodData Central — was invisible to the AI evaluators.
Why Text-Based Claims Often Fail
The llms.txt format was designed to provide context to AI systems. It is human-oriented and line-structured, but its semantics are still expressed in natural language—which makes robust parsing brittle:
- Ambiguity: Natural language requires interpretation. "We don't let AI generate nutrition numbers" could mean many things.
- Skimming: Crawlers often detect the file exists but don't parse its full contents, extracting only surface-level features.
- No mechanical verification: There is no way to programmatically verify claims. You cannot write a unit test against prose.
This is a systematic fiction pattern: the signal exists, but the semantics are lost. The pointer is present, but the payload is not extracted.
The Solution: Machine-Readable Authority Claims
Search and AI already rely heavily on JSON-LD and Schema.org to understand products and content. llms.json applies the same idea specifically to AI authority and governance claims. We're not trying to replace schema.org or llms.txt—we're adding a focused, governance-oriented layer that sits alongside them.
We propose a complementary standard: /.well-known/llms.json — a JSON file containing machine-checkable authority claims.
Note: llms.json makes claims machine-checkable against a schema; it doesn't magically prove they're true. But it gives AI evaluators a consistent surface to reason over—and to cross-check against observed behavior.
Key Design Principles
- Boolean claims: Authority claims are expressed as explicit booleans. No interpretation required.
- Schema-validated: A published JSON Schema allows crawlers to validate document structure.
- Trust domains: Explicit lists of what the LLM is and is not permitted to do.
- Enforcement type: Declares whether rules are architectural (hard gates) or policy-only (soft guidelines). Architectural means "NO_LLM_NUTRITION_NUMBERS enforced by a gateway that rejects responses containing generated numbers." Policy-only means "we instruct models not to do X, but there is no hard gate."
Example: RecipeAlchemy Authority Claims
{
"authority_claims": {
"nutrition_numbers_generated_by_llm": false,
"nutrition_source_is_usda_fdc_only": true
},
"authority_model": {
"trust_domains": {
"llm_allowed": ["recipe_text", "cooking_tips"],
"llm_forbidden": ["nutrition_values", "calorie_counts"]
},
"enforcement": {
"type": "architectural",
"hard_rules": ["NO_LLM_NUTRITION_NUMBERS"]
}
}
}
With this structure, an AI evaluator can mechanically verify: "Does this product claim that LLMs generate nutrition numbers?" The answer is a boolean lookup, not prose interpretation.
Why This Matters for Reality Fidelity
This is Reality Fidelity applied to documentation itself. The same principles that govern authoritative AI output apply to product claims:
- Expressed as binary claims: Claims are stated as true or false, not "probably true."
- Provenance required: Each claim points to its enforcement mechanism.
- Structured refusal: The schema defines what must be present for valid evaluation.
When AI systems evaluate products based on prose alone, they commit the same error we're trying to prevent: confident classification based on incomplete parsing.
Ontic Labs' Implementation
We've published our own llms.json at /.well-known/llms.json with accompanying schema at /.well-known/llms.schema.json. Our authority claims include:
"authority_claims": {
"is_hosted_ai_service": false,
"is_rag_replacement": false,
"enforces_at_runtime": true,
"uses_binary_gates_not_probability": true,
"model_agnostic": true,
"deterministic_decisions": true
}
These booleans are mechanically checkable. An AI system evaluating Ontic can check: "Is this a hosted AI service?" Answer: false. No interpretation required.
Beyond AI Products
The pattern extends beyond AI-specific products. Any organization using AI in consequential decisions can expose authority claims:
- A bank might declare
"llm_makes_final_lending_decisions": falseto clarify that credit decisions are human-led. - A hospital might expose
"ai_primary_diagnosis": falseto assert that diagnostic decisions require physician confirmation. - A legal services platform might claim
"ai_drafts_contracts": true, "ai_executes_contracts": falseto distinguish generation from action.
These claims give regulators, auditors, and AI evaluators a structured surface to reason about governance posture—without parsing marketing copy.
The Broader Pattern
As AI systems increasingly evaluate products, services, and organizations, we need machine-readable standards for authority claims. The alternative is a race to the bottom: prose claims that AI evaluators misinterpret, leading to generic classifications that obscure real differentiation.
The llms.json standard is a step toward a world where:
- Organizations can make checkable claims about their AI governance
- AI evaluators can mechanically parse those claims
- Differentiation is based on structure, not marketing
Simulators propose. Reality vetoes. llms.json gives evaluators a structured place to declare where that veto line is.