The Practical Guide to Validating Your ThatWare AI Architecture
Generating machine-readable files is not enough. A file can exist and still be:
Validation ensures that your ThatWare AI architecture accurately represents the organization it is designed to describe.
This guide explains how to validate:
- • AI Stack files
- • Intelligence Layer files
- • Knowledge Registry assets
- • Entity relationships
- • Canonical sources
- • Structured data
- • Cross-file consistency
- • Freshness
- • Privacy and security
Supporting line: Validate the syntax. Verify the sources. Align the entities. Protect the data. Keep the knowledge current.
Three-Tier Verification
A file is not valid merely because it parses. Complete validation spans technical accessibility, semantic coherence, and verifiable evidence.
Nine Checks Before You Trust a Machine-Readable File
Can the file actually be reached?
Can the file be parsed correctly?
Does it follow the intended file schema?
Does it describe the correct people, products, brands and concepts?
Do referenced URLs and evidence actually exist?
Do all machine-readable assets describe the same organizational reality?
Is the information still current?
Is anything being exposed that should remain private?
Does the live version behave as expected after deployment?
"A file should not be considered valid simply because the JSON parses."
Technical validity is only one part of AI readiness.
Validate Syntax, Meaning and Reality
The strongest implementation passes all three levels:
Technical Validation
Answers: Can machines read the file?
Check:
- • HTTP response
- • MIME type
- • JSON syntax
- • XML syntax
- • Text encoding
- • Schema compatibility
Semantic Validation
Answers: Does the file make logical sense?
Check:
- • Entity relationships
- • Taxonomy
- • Aliases
- • Hierarchy
- • Canonical sources
- • Cross-file consistency
Evidence Validation
Answers: Is the information actually true and supportable?
Check:
- • Credentials
- • Awards
- • Research
- • Framework ownership
- • Media references
- • Source URLs & dates
- • Authority claims
Validation Status System
Use a simple three-state system across the platform.
The resource meets the required validation condition.
Example: JSON syntax valid
The resource is usable but requires review.
Example: Source exists, but the page has not been updated recently.
The issue can materially affect interpretation, deployment or trust.
Example: Canonical product URL returns 404.
Phase 1: File Availability Validation
Start With the Simplest Question: Does the File Exist?
A perfect JSON file has no value if the intended system cannot retrieve it. Validate each public file for:
- • HTTP Status: Expected: 200 OK. Investigate: 301/302. Fail: 404, 403, 500.
- • HTTPS: Public AI-facing resources should use secure HTTPS URLs.
- • Redirects: Avoid unnecessary chains (/file.json → /old-file.json → /new-file.json → /final-file.json). Prefer a direct stable endpoint.
- • Authentication: Ensure public files are not unexpectedly blocked by authentication, firewall rules, CMS permissions, or CDN settings.
- • Production Domain: Ensure the resource points to example.com, not staging.example.com or localhost.
| Resource | HTTP | HTTPS | Redirect | Status |
|---|---|---|---|---|
/ai.txt |
200 | ✓ | None | PASS |
/llms.txt |
200 | ✓ | 1 | PASS |
/research.json |
404 | ✓ | None | FAIL |
/brand-memory.json |
200 | ✓ | None | PASS |
Phase 2: Syntax Validation
Machine-Readable Files Must Actually Be Machine Readable
JSON: Validate matching braces, valid commas, escaped characters, quotation marks, arrays, objects, encoding.
XML: Validate one root element, properly closed tags, valid characters, properly escaped entities, consistent namespaces.
Text & Markdown: For ai.txt, llms.txt, llms-full.txt, check headings, URLs, readable hierarchy, malformed Markdown, unintended HTML, encoding problems, duplicated sections.
{
"name": "Example Company",
"services": [
"AI Readiness",
"Entity Intelligence",
]
}{
"name": "Example Company",
"services": [
"AI Readiness",
"Entity Intelligence"
]
}<product>
<name>Example Product
</product><product>
<name>Example Product</name>
</product>Phase 3: Schema & Structural Validation
A JSON object can be syntactically valid but still be incomplete. For example, {"name": "Framework X"} parses correctly, but if the intended registry requires canonical ID, description, creator, source, date, and entity type, it is incomplete.
Validate: Required fields, Expected data types, Unique IDs, Version info, Canonical sources, Parent relationships, Modification dates.
Schema.org Validation
Do Not Confuse Custom AI Fields With Schema.org Properties. Raw AI files can contain operational fields; JSON-LD must remain standards-safe.
{"@context": "https://schema.org", "@type": "Organization", "aiAuthorityScore": 97}
{"@context": "https://schema.org", "@type": "Organization", "additionalProperty": {"@type": "PropertyValue", "name": "AI Authority Score", "value": "97"}}
Phase 4: Canonical ID Validation
Stable IDs Are the Backbone of the Architecture
ThatWare's internal architecture recommends absolute identifiers precisely to reduce ambiguity for parsers and AI-facing systems. For example: https://example.com/#organization should represent the same organization everywhere.
example-company, company-main, organization1, example-corp all referring to the same business without an explicit mapping.
Phase 5: Entity Consistency Validation
Suppose the same product appears as:
Entity Registry: ThatWare AI Intelligence Platform
Brand Memory: AI Intelligence Suite
If these refer to one product, determine the Canonical name and Approved aliases.
Use entity-registry.json as the canonical baseline for names, aliases, schema types, publication dates, and URLs to ensure consistency across all other files.
- • Organization: Name, Legal name, Preferred name, Primary URL
- • Founder: Name, Role, Canonical profile
- • Product: Canonical name, Product family, Aliases
- • Service: Official name, Parent category
- • Framework: Name, Abbreviation, Creator, Canonical source
- • Location: Address, Parent organization
Phase 6: Relationship Validation
Verify Every Important Connection:
- •
Founder → founded → Organization(Is that correct?) - •
Organization → owns → Product(Is ownership documented?) - •
Research → supports → Framework(Does the research actually support it?) - •
Doctor → performs → Procedure(Is that current and authorized?) - •
Location → provides → Service(Is the service really offered there?)
Questions: Does source entity exist? Does target exist? Is relationship type appropriate? Is supporting evidence available? Is it current?
{
"source": "example-company",
"relationship": "created",
"target": "framework-x"
}Validate: Does Framework X exist? Did Example Company create it? Is there a canonical page? Is there supporting research or documentation? Only after these checks is the connection verified.
Phase 7: URL & Source Validation
For every source URL, check:
- • Accessibility: Does it return successfully?
- • Canonicality: Is this the preferred source?
- • Relevance: Does the page actually support the record?
- • Freshness: Is the information current?
- • Ownership: Is the source internal or third-party?
- • Source Type: Research? Product page? Policy? Media article? Documentation?
Phase 8: Cross-File Consistency Validation
Compare across AI Stack, Intelligence Layer, and Knowledge Registry:
llms.txt says: CEO: Jane Smith
brand-memory.json says: CEO: John Smith
entity-registry.json says: CEO: Jane Smith
| Data Point | Manifesto | Entity Reg | Brand Memory | Website | Status |
|---|---|---|---|---|---|
| Company Name | Example Co | Example Co | Example Co | Example Co | PASS |
| Founder | Jane Doe | Jane Doe | Jane Doe | Jane Doe | PASS |
| Product X | Active | Active | Active | Removed | WARN |
| Old Service | Active | Deprecated | Historical | Removed | FAIL |
Phase 9: Knowledge Registry Evidence Validation
Every Authority Record Should Be Verifiable
- Research: Author, Publication date, Methodology, Canonical source
- Frameworks: Creator, Definition, Evidence, First publication
- Awards: Awarding organization, Recipient, Year, Source
- Media: Publication, Interview/article, Person referenced, URL
- Books: Author, Publisher, Date, ISBN where applicable
- Certifications: Holder, Issuer, Credential, Status, Expiry where applicable
"No evidence, no authority claim."
Phase 10: FAQ Validation
A Clean Q&A File Can Spread an Incorrect Answer Efficiently. Validate every faq.json record for:
ThatWare's internal research describes faq.json as a custom AI/GEO knowledge resource rather than Schema.org FAQ markup, making answer accuracy and source alignment especially important.
Because AI answer engines synthesize facts directly from structured FAQ nodes, inaccurate answers can be magnified across downstream generative systems.
Phase 11: Brand Memory Validation
Long-Term Knowledge Requires Strong Governance. brand-memory.json can preserve important organizational knowledge over time, which also makes errors more consequential. Validate:
Phase 12: Freshness Validation
Information Decays. Common freshness problems:
- • Former employee still listed as current.
- • Discontinued product still treated as active.
- • Old pricing prioritized.
- • Expired certification retained.
- • Changed location still referenced.
- • Old documentation remains canonical.
Useful Fields: publishedAt, modifiedAt, lastReviewed, validFrom, validUntil, status
Phase 13: Privacy Validation
Validate Every Public Field Before Deployment. Look for:
- • Was this information already approved for public exposure?
- • Is there a legitimate reason for publishing it?
- • Does it contain personal or confidential information?
Phase 14: Security Validation
Never Publish Credentials Inside AI Files. Scan for:
{
"api": "https://example.com/internal/",
"apiKey": "SECRET-KEY-123"
}Phase 15: Retrieval Validation
Test the Retrieval Architecture for rag-index.json, vector-feed.xml, and related systems with sample questions.
Expected: 1. Product page → 2. Documentation → 3. Relevant FAQ → 4. Supporting research
Investigate if it retrieves: Old blog post, Unrelated press release, or Deprecated product page.
- • Relevance
- • Source priority
- • Freshness
- • Entity match
- • Duplicate retrieval
- • Unsupported source selection
Phase 16: Citation Validation
For citation-preferences.json, confirm:
- • Preferred URL exists.
- • Publisher name is correct.
- • Author attribution is correct.
- • Original source is actually original.
- • The resource supports the claim.
Citation preferences communicate internal source guidance. They do not force external AI platforms to cite those sources.
Phase 17: Well-Known File Validation
Validate /.well-known/ai.txt and /.well-known/security.txt where implemented.
For security.txt, verify that:
- • Security contact works.
- • Policy URL exists.
- • Expiry is current.
- • Canonical URL is correct.
Phase 18: Production Validation
Re-Test After Deployment. Check for:
The ThatWare AI Validation Matrix
| Validation Area | What It Checks | Severity if Failed |
|---|---|---|
| Availability | File access | High |
| Syntax | Parseability | Critical |
| Schema | Structural compliance | High |
| Entity | Identity consistency | Critical |
| Relationships | Logical accuracy | High |
| Sources | Evidence and canonical URLs | High |
| Freshness | Current information | Medium-High |
| Privacy | Public exposure | Critical |
| Security | Secrets and sensitive infrastructure | Critical |
| Cross-file | Architecture consistency | Critical |
| Retrieval | Information selection | High |
| Production | Live deployment health | High |
Recommended Validation Order
Validate From the Foundation Outward:
1. Website Source → Is the source information correct?
2. Canonical Identity → Are organization and entity records correct?
3. File Syntax → Can the files be parsed?
4. File Structure → Are required fields present?
5. Relationships → Are entities connected accurately?
6. Sources & Evidence → Can records be verified?
7. Cross-File Consistency → Does the full architecture agree?
8. Privacy & Security → Is public exposure safe?
9. Production → Does the live architecture behave correctly?
Error Severity Framework
Examples: Invalid JSON, Wrong organization identity, Exposed API key, False credential, Sensitive customer data.
Action: Block deployment.
Examples: Broken canonical URL, Wrong entity relationship, Invalid schema type, Major source mismatch.
Action: Fix before production.
Examples: Old modification date, Minor metadata gap, Secondary source unavailable.
Action: Review and correct.
Examples: Non-critical optional field missing.
Action: Improve when practical.
Validation Before Regeneration
Before regenerating machine-readable assets, validate the underlying source.
Wrong source data → Generate 30 files → Discover the mistake → Fix 30 files
Validate source → Generate files → Validate architecture → Deploy
Continuous Validation Dashboard
Monitor what can change over time. Use actual production values rather than fabricated scores.
Some Validation Cannot Be Fully Automated
Automation can reliably check:
Syntax, HTTP responses, duplicate IDs, broken links, missing fields, format rules.
Human reviewers must verify:
Framework ownership, Professional credentials, medical information, legal claims, brand history, research interpretation, authority evidence, semantic relationships.
"Machines validate structure. Humans remain accountable for truth."
Common Validation Mistakes
Parsing does not verify truth.
Cross-file contradictions remain invisible.
An authority record needs real evidence.
Control aliases centrally.
Old data should be labeled historical or deprecated.
Production must be validated again.
Structured public data remains public data.
Keep standards-based markup standards-safe.
Websites and organizations continuously change.
Validation by Practical File Guide
AI Stack
Validate: File availability, priority URLs, identity, semantic mapping, vector records, cross-file consistency.
Intelligence Layer
Validate: Graph relationships, RAG sources, context rules, reasoning architecture, trust evidence, citation sources, endpoint availability, freshness.
Knowledge Registry
Validate: Research, framework ownership, awards, media, books, courses, credentials, FAQs, entities, brand memory.
Implementation
Validate: deployment paths, MIME types, HTTPS, cross-references, environment settings, caching, production behavior.
Pre-Deployment Validation Checklist
Before approving production:
A Valid Architecture Is Not a Guaranteed AI Outcome
Passing validation means the architecture is: More technically reliable, More internally consistent, Better aligned with its sources, Safer to deploy, and Easier to maintain.
It does not guarantee: AI citations, AI rankings, LLM recommendations, Search rankings, Retrieval by every provider, Traffic, Leads, or Revenue. External systems continue to apply their own retrieval, ranking, model, and citation logic.
The Right Expectation"Validation proves the quality of your implementation, not the behavior of systems you do not control."