The Wayfinding File Triad

Audience: Web stewards, content editors, and anyone responsible for the technical health of a UAMS web property.

Purpose: Operational reference for the three files that make up UAMS AI Wayfinding: what each one does, where it lives, how it is served, and how it is maintained.

Overview

As the Wayfinding rollout proceeds, each UAMS pillar will carry the same three files. Together these files are the Wayfinding triad. Each one has a distinct job.

File	Role	Analogy
robots.txt	Gatekeeper	The security desk that decides who gets in
llms.txt	Handshake	The information desk that greets visitors
llms-full.txt	Directory map	The detailed wall directory with every department listed

All three files appear at the root of each domain and resolve via normal HTTP requests. For example, on communications.uams.edu:

https://communications.uams.edu/robots.txt
https://communications.uams.edu/llms.txt
https://communications.uams.edu/llms-full.txt

How the files are served

The files are not static files sitting on the filesystem. They are served by a custom plugin that is network-activated on every UAMS Multisite install. The plugin intercepts requests for /robots.txt, /llms.txt, and /llms-full.txt and returns content on a per-site basis.

This matters for web stewards because:

1. You will not find these files via SFTP or server-level file browsing. They do not exist on disk.
2. Edits are made through the admin panel on each site, not through a code or file deployment process.
3. The plugin automatically sets Content-Type: text/plain; charset=utf-8 on every response, which prevents character encoding issues.
4. The plugin intercepts the CMS canonical redirect so that /llms.txt does not get rewritten to /llms.txt/ with a trailing slash.

If a static robots.txt, llms.txt, or llms-full.txt file exists in the web root, it will bypass the plugin and be served directly by the server. For Wayfinding deployments, no static files should exist at the root of a subsite managed by the plugin.

File 1: robots.txt

What it does. Defines which automated agents are permitted to crawl which parts of the domain. This is the same robots.txt that has existed on the web for decades, extended to cover modern AI crawlers.

What is new in 2026. The file now includes explicit directives for AI-specific user agents such as GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot, and others. Each pillar has a reviewed allowlist and blocklist.

Who maintains it. UAMS Web Services.

Key rules at UAMS.

• AI crawlers are generally permitted on modernized subdomains.
• Legacy sections of www.uams.edu are blocked from AI ingestion to prevent outdated information from being incorporated into LLM training.
• Any path that serves PHI-adjacent or internally scoped content is disallowed for all user agents.
• CCBot is disallowed across the ecosystem. Common Crawl feeds many training pipelines, and we have chosen to gate AI ingestion through the more tightly scoped AI-specific agents instead.

File 2: llms.txt

What it does. Provides a concise, human-readable summary of the domain written for consumption by large language models. The file follows the llms.txt convention proposed by Jeremy Howard at llmstxt.org in September 2024.

Structure (UAMS Wayfinding specification). An llms.txt file at UAMS contains the following sections in this order:

1. Single H1 with the domain’s display name
2. Blockquote summary — one paragraph describing what the domain is authoritative for
3. ## Metadata — Version, Last Updated, Status, and optional Update Frequency fields
4. ## Targeted Content — 3 to 6 bulleted links pointing into anchors in the companion llms-full.txt
5. ## Related Resources — cross-links to sibling UAMS properties under the Option C governance model (see below)
6. ## Authority and Scope — two statements, one positive (“authoritative for…”) and one negative (“not authoritative for…”)
7. ## Full Index — link to the companion llms-full.txt

Why this file exists. When an AI agent arrives at a UAMS domain and needs a quick orientation, llms.txt is what it reads first. It is the handshake. The file’s purpose is to make the domain’s scope and structure immediately legible to an agent without requiring the agent to crawl and infer from HTML.

Who maintains it. The UAMS Web Services team drafts, reviews, and deploys every llms.txt for every pillar. Content owners can suggest edits, but the files themselves are edited Brent Passmore.

File 3: llms-full.txt

What it does. The deep-data companion to llms.txt. Where the handshake file is a short greeting, llms-full.txt is the full directory map with per-section content inventories, behavioral directives, and cross-links to sibling domains.

Structure (UAMS Wayfinding specification). An llms-full.txt file at UAMS contains:

1. Single H1 with the domain’s display name (same as llms.txt)
2. Blockquote summary (same as llms.txt)
3. ## Metadata (same fields as llms.txt)
4. ## Content Sections — numbered subsections (### 1., ### 2., etc.) that each describe a major area of the domain in 1-3 sentences. The anchors generated from these headings are what the ## Targeted Content bullets in llms.txt reference.
5. ## Related Resources — same Option C cross-links as in llms.txt
6. ## Authority and Scope — same positive and negative scope statements as in llms.txt
7. ## AI Agent Directives — three subsections: ### Citation, ### Routing, and ### Out of Scope. Each contains numbered, imperative instructions.

Why this file exists. LLMs produce more reliable answers when they have structured context about the source they are citing. llms-full.txt provides that context at a depth that llms.txt cannot.

Who maintains it. Web Services owns the file. Updates typically happen when new content sections are added to the domain, when a sibling domain changes its scope, or when the cross-link governance model is refined.

Option C cross-link governance

Cross-links between UAMS pillars and their subsites follow the pillar-hub model, internally referred to as Option C:

1. Up-link to the pillar root. Every subsite triad links up to its pillar root (e.g., a Pediatrics triad under the College of Medicine links to medicine.uams.edu).
2. Clinical destination link. Clinical subsites also link to uamshealth.com. Non-clinical subsites skip this.
3. One or two topic-specific cross-pillar links. Departments that genuinely overlap with another pillar’s scope link to that pillar (e.g., Pediatrics to Cancer Institute for pediatric oncology).
4. No peer-department links within the same pillar. Peer routing flows through the pillar root.

Reciprocity under this model works differently from simple bidirectional linking. When a subsite links to a cross-pillar (e.g., Pediatrics → Cancer Institute), the expected reverse link lives at the cross-pillar’s root, not at a specific subsite within it. Web Services’ audit tooling is being built to understand this pattern.

Adding a new domain to the Wayfinding network

New UAMS subdomains are uncommon, and the current institutional direction is toward consolidating the existing federation rather than expanding it. When a new subdomain is launched, however, the Wayfinding triad is part of the production-readiness checklist.

The rollout process:

1. Web Services drafts the three files based on the domain’s scope and content inventory.
2. Files are reviewed by Web Services for cross-domain consistency.
3. Files are deployed on the new subsite.
4. The domain is added to the UAMS Digital Ecosystem document as the canonical registry.
5. Cross-links are added to sibling pillar-root triads as needed to maintain Option C reciprocity.

Web Services’ stated intention is that new subdomains should carry the Wayfinding triad before they are considered production-ready. This intention is expected to move toward a formally enforced policy as the rollout matures.

Auditing an existing domain

If you are reviewing a UAMS subdomain and want to confirm its Wayfinding status, check:

• Does /robots.txt exist and include current AI user-agent directives?
• Does /llms.txt exist and resolve with a 200 status?
• Does /llms-full.txt exist and resolve with a 200 status?
• Does curl -I [url]/llms.txt return Content-Type: text/plain; charset=utf-8?
• Do the files reference the correct sibling domains under Option C?
• Is the content in the files still accurate given any recent site changes?

If any of these fail, contact Web Services. Formal intake for Wayfinding change requests will move to ServiceNow as demand warrants. Until then, reach out directly to Brent Passmore.

Common questions

Will this affect our SEO? Wayfinding is separate from traditional SEO, but the two reinforce each other. Clean robots.txt rules and structured content summaries help both search engines and LLMs. The rollout is too recent to have SEO impact data, but any signals we observe will inform future guidance.

Can a department write its own llms.txt? No. Wayfinding files are edited only by Web Services. Department administrators do not have access to edit these files even on their own subsite. Department input on content and scope is welcome, and should be directed to Brent Passmore.

What if an AI tool cites us incorrectly? Report it to Web Services. Observing citation errors systematically is something Web Services is considering building into its ongoing work. Individual reports from content owners are a useful input regardless of whether a formal monitoring cycle is in place.

Where can I see the full ecosystem map? The UAMS Digital Ecosystem is an internal document that serves as the current registry of pillars and their relationships.