Date: May 6, 2026 From: UAMS Web Services Audience: UAMS leadership and the Web Services team

---

Summary

UAMS Web Services has scaled the AI Wayfinding implementation for uamshealth.com from a small curated index (15 URLs) to a comprehensive structured directory of all UAMS Health expertise areas, providers, and locations (1,441 entries). New automation tooling makes ongoing maintenance practical at this scale.

Files are drafted and ready for deployment. Quarterly maintenance cadence is established.

---

What changed

Coverage of UAMS Health. The deployed AI Wayfinding files for uamshealth.com previously referenced 15 URLs. The new files reference 1,441 distinct UAMS Health URLs:

• 82 clinical expertise areas (every category from the site’s expertise sitemap)
• 1,184 providers (every provider profile from the provider sitemaps)
• 168 locations (every UAMS Health location from the location sitemap)
• 7 cross-pillar institute references
• Plus curated patient logistics, education, and research content

This is a 96-fold increase in coverage, raising the proportion of same-host content represented in wayfinding files from less than 1 percent to approximately 30 percent. The remaining content (blog posts, marketing pages, system taxonomies) is intentionally out of scope per the in-scope policy described below.

File structure. The new llms-full.txt follows the UAMS Wayfinding specification with positive and negative scope statements, properly structured Related Resources for cross-pillar references, and documented sections for AI agent behavior. The companion llms.txt provides a curated overview that links to canonical content pages on the site.

Tooling for scale. A new command-line tool (wayfinding-generate.py) auto-produces the bulk sections from sitemaps. Hand curation of 1,184 individual provider entries would not be practical to maintain; programmatic generation with a 30-day cache makes quarterly regeneration a 5- to 10-minute operation.

Audit infrastructure. A new sitemap-vs-wayfinding diff tool (sitemap-diff.py) surfaces content drift quarterly. Initial run confirmed the new files are aligned with the live site and identified the eight stale references in the previously deployed file (which the new version resolves).

Risk management. The new files include two explicit risk-reduction additions. First, an informational-content disclaimer is stated in the Authority and Scope section of both llms.txt and llms-full.txt: UAMS Health content is informational and educational and does not constitute medical advice. Second, the LLM Behavior Directives include a currency-deferral instruction for AI agents: when a user’s question concerns time-sensitive facts (a provider’s accepting-patients status, current clinic location, employment status, or active specialties), AI agents are instructed to defer to the live profile URL rather than treating the wayfinding file’s cached summary as authoritative. Both additions are now standard requirements for any UAMS clinical pillar’s wayfinding files.

---

Why this matters

When patients ask AI tools about UAMS, the AI’s accuracy depends largely on whether UAMS publishes structured information that AI agents can read and trust. The previously deployed wayfinding files told AI tools that UAMS Health had three clinical specialties (Spine, Heart, Northwest Orthopaedics). The new files tell AI tools about all 82 specialties, every provider, and every location.

Earlier this year a UAMS clinician in Bentonville reported that patients were finding him through ChatGPT and Claude. The wayfinding scaling work makes those outcomes more likely to be accurate and more likely to point to the right UAMS resource. The forthcoming UAMS AI Wayfinding measurement program will track whether this expanded coverage translates to improved AI accuracy over the next 12 months.

---

In-scope policy (what we include and what we don’t)

The new files include:

• All UAMS Health expertise areas, providers, and locations (auto-generated from sitemaps)
• Curated patient logistics, education, and research content (hand-authored)
• Cross-pillar references to UAMS clinical institutes that maintain their own wayfinding files

The new files exclude:

• Individual blog posts and news items (covered by a single /news/ link)
• Marketing campaign and time-bound content
• Internal operational pages (work orders, admin)
• WordPress system URLs

This policy is documented in the wayfinding-governance skill and is applied consistently to all UAMS pillars.

---

Operational implications

Quarterly regeneration. Bulk sections will be regenerated quarterly to capture new providers, retired providers, new clinic locations, and so on. Quarterly cadence aligns with the existing UAMS AI Wayfinding citation audit cycle.

Quarterly diff audit. Web Services will run the sitemap-vs-wayfinding diff each quarter to surface drift. The output is a recommendation report; curation decisions remain editorial.

Federation expansion. The same tooling and policies will be applied as Web Services publishes wayfinding triads for the 28 uamshealth.com microsites (Stroke Program, Sickle Cell, NICU, Kids First, and others). This is a multi-month effort.

File size. The new llms-full.txt is 358 KB. This is well within practical limits for AI agents that fetch the file. If specific AI tools begin truncating responses at large file sizes, the llmstxt.org specification provides a sanctioned mechanism (the ## Optional section) to move bulk sections to a skippable position.

---

Status

Item	Status
uamshealth-llms-v1.4.0.txt (new llms.txt)	Deployed
uamshealth-llms-full-v3.1.0.txt (new llms-full.txt)	Deployed
Wayfinding-governance skill updates	Pushed to repo
wayfinding-generate.py CLI tool	Pushed to repo
sitemap-diff.py audit tool	Embedded in skill, ready to run
Audit script enhancements (robots.txt checks, URL liveness)	Updated in skill
Deployment to uamshealth.com production	Deployed
Wayfinding triads for 28 microsites	Pending

---

Next steps

1. Deploy the new llms.txt and llms-full.txt to uamshealth.com via the Per-Site plugin
2. Verify deployment with the standard launch checklist (HTTP 200, content type, content body match)
3. Schedule the first quarterly regeneration for August 2026
4. Begin drafting wayfinding triads for the highest-priority uamshealth.com microsites

---

Contact

Questions about AI Wayfinding can be directed to UAMS Web Services. Misrepresentations of UAMS by AI tools can be reported through the AI issue reporting form.

We previously asked five leading AI models what they thought of UAMS AI Wayfinding. Their response was generous and genuinely useful. But one observation came up across all of them: how will you know if this actually works?

That is the right question, and it is the one we spent this month answering. This post walks through the measurement program UAMS Web Services built to track whether AI Wayfinding is actually improving how AI tools represent UAMS, and how we plan to respond when it is not.

Why measurement is hard

AI model behavior is a moving target. Models update constantly. Any observed improvement in how an AI tool describes UAMS could come from our Wayfinding files, from a model retraining, from third-party content changes, or from vendors tweaking their systems. No controlled experiment is possible.

Unlike search engines, AI tools do not publish performance dashboards. There is no “AI Search Console” that tells us how often UAMS is cited, or how accurately. The effectiveness of the Wayfinding convention also depends on whether AI vendors continue to honor it, which varies across tools and changes over time.

A measurement program that pretended to solve these problems would lose credibility quickly. We built one that names them openly.

How we will measure

Three complementary practices, each capturing something the others cannot.

Monthly systematic scoring. On the first Monday of every month, we will send the same set of questions about UAMS to five AI tools: ChatGPT, Claude, Gemini, Perplexity, and Microsoft Copilot. Each response is scored on a simple three-point rubric (accurate, partial, inaccurate) and logged in a shared sheet. Twelve UAMS questions plus six abstracted peer-comparison questions, across five tools, runs about 90 to 110 minutes per cycle.

Peer comparison. Each month, one peer institution is sampled alongside UAMS. The rotation covers four peers across the year and gives UAMS leadership a genuine sense of where the institution stands relative to peers who either invested in AI readability earlier or did not invest at all.

Continuous incident reporting. A public-facing form lets anyone, UAMS staff or patients or members of the public, report an AI answer that looks wrong. Web Services triages submissions weekly. Most result in content updates on UAMS pages. A few severe cases may be escalated through AI vendor feedback channels.

What we gave up on purpose

The most important design decision was what we chose not to build.

We could have automated the monthly scoring. Browser agents can click links, paste questions, and capture responses. But the measurement program’s validity depends on a human reading each AI response in the tool’s native interface. That reading is the measurement, not a byproduct of it. If an agent scrapes responses and a staffer scores text excerpts in a spreadsheet, the institutional knowledge and incident-detection value disappear. Automation was the easy answer. Reading responses yourself is the honest one.

This decision will be revisited in October 2026. By then, six months of operational data will tell us whether 90 minutes per month is sustainable and whether the human engagement is producing the expected value. If not, we adjust.

What happens with the data

Every monthly pull generates a new tab in a shared measurement sheet. Every monthly pull also generates a summary report committed to a private repository. Reports aggregate UAMS performance by tool, trend over time, and peer comparison. The first real report will land in early May 2026 covering April data.

Quarterly, a deeper audit runs against the accumulated monthly data, using a purpose-built audit tool that identifies persistent misrepresentations and generates recommendations for the Wayfinding files. These quarterly reports go to Web Services leadership.

Annually, at the end of the first year, we synthesize everything into an evidence-based assessment: what changed in how AI tools represent UAMS over twelve months, what we can and cannot attribute to the Wayfinding initiative, and what we recommend for year two.

The honest expectation for year one

We are not going to prove causality. This program cannot separate the effect of the Wayfinding files from the effect of model retraining, content updates, or any of the other variables that move AI behavior month to month. Any institution that claims it can is overselling.

What we will have is a disciplined signal: twelve months of scored data across five AI tools, a catalog of specific misrepresentations identified and addressed, a peer comparison across four institutions, and a reasonable basis for telling UAMS leadership whether the initiative is earning its keep.

That is not a small outcome. Most academic medical centers are not yet measuring this at all. Many will launch AI readability initiatives over the next eighteen months without any way to tell whether they worked. UAMS is choosing to know.

For peers and staff

If you work at a peer academic medical center thinking about similar measurement, we are happy to share the methodology. If you are UAMS staff and have encountered an AI answer about UAMS that looks wrong, please use the report form. Every submission helps us find the gaps the monthly monitoring misses.

The full measurement plan and the question set are documented internally. Web Services is the team of record.

When Web Services launched UAMS AI Wayfinding earlier this year, we framed it as a quiet but essential investment in how AI tools represent UAMS to the public. It is easy enough to make that claim. It is harder to know whether the people whose opinions we are actually trying to shape, namely the AI tools themselves, would agree.

So we asked them.

We sent a single question to four leading AI models at once: ChatGPT, Claude, Gemini, and Perplexity. Every model has blind spots. One invents citations. Another hedges. A third misses context. Asking any single model for an opinion gives you that model’s blind spots along with its answer. Asking all of them at once, and then having them review each other’s responses, produces something closer to peer-reviewed consensus. When the models agree, the answer carries more weight. When they disagree, the disagreement itself is useful information.

It is peer review for AI output. And for a question about how AI tools evaluate an AI-readability initiative, it felt like the right instrument for the job.

The question we asked was simple: 

What are your thoughts on this idea and initiative? How will it improve AI results at UAMS? 

We pointed the models at our published article Wayfinding for Machines: How UAMS Is Preparing Its Digital Ecosystem for the AI Era and let them go.

What came back was more substantive than we expected. The models did not just validate what UAMS Web Services is doing. They identified specific things the initiative gets right, specific limitations the initiative does not solve, and specific open questions worth asking ourselves. In other words, exactly the kind of critical feedback you would want from a thoughtful peer.

The full response follows below. Where the models agreed, that consensus carries real weight. Where they pushed back or raised concerns, those observations are worth taking seriously.

Wayfinding for Machines: Comprehensive Analysis of the UAMS AI Readiness Initiative

---

What This Actually Is

This is not about internal AI model building or clinical data pipelines. It’s about how UAMS is represented by external AI systems — ChatGPT, Claude, Gemini, Perplexity — when patients, students, referring physicians, and researchers ask those tools questions about UAMS.

Most institutions are still asking “How do we use AI?” UAMS Web Services asked a different and arguably more urgent question: “How does AI represent us?” That’s a meaningful strategic distinction. A patient asking Claude about cancer treatment options at UAMS gets an answer whether UAMS has prepared for that or not. The only variable is accuracy.

The core deliverable is a three-file architecture deployed across 200+ web properties:

File	Function
robots.txt	Defines crawl permissions per AI agent (GPTBot, ClaudeBot, Google-Extended, etc.)
llms.txt	Short, human-readable domain identity statement written for LLM consumption — the handshake
llms-full.txt	Deep directory map with behavioral directives, content inventories, and cross-domain links

Together these files do for AI agents what floor lines and overhead signage do for hospital visitors — they answer questions that would otherwise be inferred, poorly.

---

Why This Is Genuinely Smart

1. They Identified the Right Problem First

The initiative correctly recognizes that a growing share of people looking for UAMS content never visit a UAMS page directly. They ask an AI assistant and read the synthesized answer. Whether that answer is accurate depends on whether the AI understood what it was reading. UAMS is taking responsibility for that variable rather than leaving it to chance.

2. The Failure Mode Analysis Is Correct

The article makes a sharp observation about asymmetric failure modes:

• Poor SEO = lower ranking (recoverable, visible)
• Poor AI representation = confident misinformation delivered directly to a patient or referring physician (less visible, harder to correct, higher stakes)

Generative AI doesn’t say “I couldn’t find that.” It synthesizes an answer that sounds authoritative regardless of whether the underlying data was well-structured. When a generative AI tool tells someone that UAMS offers a program it does not offer, or lists a specialty at the wrong institute, the cost is not a lost click — it is a lost opportunity to be trusted. In a healthcare context, this connects directly to patient safety.

3. The Institutional Memory Problem Is Real

An LLM has no inherent reason to know that:

• The Winthrop P. Rockefeller Cancer Institute is the oncology authority
• The Translational Research Institute hosts clinical trial listings
• communications.uams.edu is the governance authority, not just a news site

Without explicit machine-readable declarations, these relationships get inferred — and inference at scale is where hallucinations originate.

4. Architecture-Level Rather Than Page-Level Governance

Solving 200+ web properties page by page would be unsustainable. Building a standardized file triad into the production launch checklist means the solution scales automatically with the ecosystem. This is systems thinking applied correctly — fix the substrate, not each individual symptom. One file triad per subsite. One governance model across the federation. One cross-link pattern that scales without becoming a maintenance burden.

5. The llms.txt Standard Is Timely

The llms.txt proposal is an emerging convention that forward-looking institutions are beginning to adopt. UAMS positioning itself as an early adopter in the healthcare and academic medical center space is genuinely notable. Most peer institutions haven’t done this yet.

6. The Framing Is Doing Real Work

The hospital wayfinding metaphor isn’t just communication strategy — it’s change management infrastructure. UAMS has a large, decentralized organization with deans, directors, and hundreds of content editors who need to understand and cooperate with this initiative. A metaphor that every employee already lives daily is far more powerful than explaining llms.txtfile conventions from scratch. That’s thoughtful institutional communication.

7. The Closing Line Is the Most Important Line

“The agents are already visiting. The question is whether your site has signs.”

This reframes the initiative from optional to urgent without being alarmist. It’s accurate — AI crawlers don’t wait for institutional readiness.

---

What This Initiative Does and Does Not Address

It’s important to be precise about scope, because this initiative is easy to conflate with broader AI strategy:

This initiative does address	This initiative does not address
How external AI tools represent UAMS	How UAMS uses AI internally
AI agent navigation of web properties	Clinical AI, decision support, or diagnostics
Reducing hallucinations about UAMS	Reducing hallucinations in UAMS-built AI tools
Web governance scalability	EHR data quality or research data infrastructure

That’s not a criticism — focused initiatives with clear scope tend to succeed. But leadership should understand this is one piece of a larger AI readiness picture.

---

Honest Limitations and Open Questions

What This Doesn’t Fully Solve

Gap	Context
Training data lag	Major LLMs train on snapshots. llms.txt helps with RAG-based and browsing-enabled queries but has limited impact on base model knowledge until retraining cycles catch up
Vendor adoption	The llms.txt convention isn’t universally honored yet. Its effectiveness depends on AI companies actively parsing and weighting these files
Content accuracy dependency	Wayfinding helps machines navigate to authoritative content — but if the underlying content is outdated or inconsistent, the navigation just delivers machines to bad information faster
Dynamic clinical information	Provider availability, clinical trial enrollment status, and program offerings change frequently. Static files can’t fully solve the freshness problem
Authority signal limits	llms.txt tells AI agents what a domain claims to be authoritative for. But AI systems also weigh third-party signals and citation patterns. Self-declaration alone may not fully move the needle

Deeper Questions Worth Asking

On governance sustainability:

• Who owns llms.txt content for each subdomain — Web Services centrally, or individual departmental editors? If departments control their own files, consistency becomes a challenge at 200+ properties.

On competitive context:

• If peer institutions like Mayo Clinic, Vanderbilt, or UCSF implement similar frameworks, does UAMS’s first-mover advantage diminish? Or does early adoption create compounding benefits through earlier incorporation into training data and crawl patterns?

On content quality:

• Has UAMS paired this initiative with a content audit to ensure what machines find is worth finding? Wayfinding is only as valuable as the destination it leads to.

On measuring success:

• How will UAMS track whether this is actually working — i.e., monitor how accurately AI tools represent UAMS information over time?
• Is there a feedback mechanism to identify when AI tools are still misrepresenting UAMS despite the wayfinding layer?

---

Broader Significance

This initiative matters beyond UAMS for several reasons:

1. It’s replicable. The three-file architecture and governance model could serve as a template for other academic medical centers facing the same 200+ web property challenge.
2. It’s timely. AI-first discovery is not a future problem. Institutions that wait until AI misrepresentation becomes a visible crisis will be playing defense.
3. It reframes the web governance conversation. Web Services teams at universities often struggle to articulate strategic value. “We are building infrastructure so AI tools accurately represent this institution to patients and students” is a compelling and concrete mandate.
4. It connects to patient safety. In a healthcare context, AI misrepresentation isn’t just a marketing problem. If an AI tool incorrectly describes UAMS capabilities, services, or clinical expertise, real patients may make consequential decisions based on that misinformation.
5. It treats AI representation accuracy as an institutional responsibility rather than an external platform problem. Most institutions implicitly assume that if their content is good, AI tools will get it right. UAMS is correctly recognizing that good content plus machine-readable structure is the actual minimum standard in an AI-first discovery environment.

---

Overall Assessment

This is a well-conceived, practically grounded initiative that addresses a real and underappreciated risk. The hospital wayfinding metaphor isn’t just clever branding — it communicates the concept effectively to non-technical stakeholders, which matters enormously for institutional adoption across 200+ properties managed by different departments.

The initiative’s greatest strength is that it scales through architecture rather than effort — once the governance model and file standards are established, new properties inherit the solution by default.

Its main dependency is external: the value of llms.txt and related files grows as AI vendors invest in honoring them. UAMS is making a reasonable bet that this convention will mature, and being early positions them well if it does.

Bottom line: UAMS Web Services identified a problem most institutions haven’t articulated yet, built a scalable solution, and documented it clearly enough that others can follow. That’s genuinely good institutional technology leadership — and a model worth watching for the broader higher education and healthcare sectors.

On April 20, 2026, the U.S. Department of Justice (DOJ) published an interim final rule extending the compliance deadline for the 2024 ADA Title II web and mobile accessibility regulations. Most public entities, including public colleges and universities, now have until April 2027 to bring their digital properties into full compliance. The original deadline, which would have taken effect on April 24, 2026, is no longer in force.

At UAMS, this news changes the calendar. It does not change the work.

What the rule does and does not say

The Title II rule itself remains intact. The DOJ has not revised the technical standard, narrowed the scope, or softened the requirements. The rule still requires that every public-facing web page and mobile application operated by a covered public entity conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, published by the World Wide Web Consortium.

The practical obligations have not changed either. Every PDF served to the public must be accessible to a screen reader. Every video must carry captions and audio descriptions. Every image must have appropriate alternative text. Every audio clip must be paired with a transcript. Every third-party platform integrated into a site must meet the same standard.

In its interim rule, the DOJ cited two reasons for the extension: the administrative and technical burden reported by covered entities, and the value of giving institutions time to achieve genuine compliance rather than diverting effort to litigation defenses.

Why this does not change the UAMS plan

The accessibility work underway across the UAMS digital ecosystem was never primarily motivated by an April 24 deadline. It was motivated by the people who use our websites and mobile applications every day.

When a patient tries to find a clinic location through voice search or an AI assistant, the schema data we cultivate determines whether they can. When a medical student reviews a curriculum PDF, the document’s underlying tag structure determines whether assistive technology can read it in the right order. When a research participant navigates a consent page using keyboard-only input, the focus order and ARIA labeling on that form determine whether they can complete the task without calling someone for help. None of that work becomes less important because the federal deadline moved by 12 months.

Accessibility is the standard of care for public digital communication. That was true before the 2024 Title II update, it remains true today, and it will remain true when the new deadline arrives in April 2027.

What continues without pause

UAMS Web Services, in partnership with accessibility stakeholders across the institution, will continue the work already in motion. That includes the ongoing WCAG 2.1 Level AA audit and remediation program covering UAMS public-facing web properties, including the flagship uams.edu and uamshealth.com domains and the specialized subdomains for our colleges and institutes. It includes PDF remediation and the retirement of non-accessible legacy documents from public distribution. It includes accessibility review as part of every new web project and every new content management workflow. It includes ongoing support for content editors across the institution through the Web Services knowledge base and direct assistance from our team, so that accessibility is built into content at the point of creation rather than retrofitted later. When Web Services is engaged in third-party platform procurement, it also includes accessibility evaluation of the vendor and their platform.

The work is steady. It is visible in our audit records and in the measurable improvements we see on the properties we have already remediated.

Guidance for the UAMS community

If you are a content owner or website editor at UAMS, the practical guidance is straightforward. Keep doing the work. Do not interpret the extension as permission to slow down. New content should continue to be created accessibly. Existing issues that have been identified should continue to be remediated on the schedule already agreed to with Web Services. Requests that would publish inaccessible content, even temporarily, should still come through the standard accessibility review process.

If you are procuring a third-party platform, the guidance is likewise unchanged. Request a current Accessibility Conformance Report using the Voluntary Product Accessibility Template (VPAT) 2.5 format from the vendor, and loop in Web Services to evaluate it. Assume that every platform connected to our public web presence must meet WCAG 2.1 Level AA.

If you maintain a departmental page and you have questions about accessibility, reach out to UAMS Web Services using the form below. Questions are always welcome, and getting accessibility right is easier with help than without it.

The longer view

Federal compliance dates come and go. Rulemaking processes generate drafts, revisions, extensions, and occasional reversals. The thing that remains constant is the population of people for whom an inaccessible website is the difference between independent access to information and no access at all.

UAMS serves the entire state of Arkansas. Our patients, students, faculty, staff, research participants, and community members include a significant number of people who depend on accessible digital communication to engage with the institution. That is who the work is for.

The deadline moved. The mission did not.

---

Use the form below for questions about UAMS web accessibility, ongoing remediation, or accessibility review for new projects.

Walk into a UAMS hospital for the first time and you will notice something before you notice anything else: the signs. Colored lines on the floor that lead you from the main entrance to Radiology. Overhead signage at every corridor intersection. Information desks staffed by people whose job is to get you where you need to go. This is wayfinding, and it is not decoration. It is infrastructure.

In 2025, UAMS Web Services began building the same kind of infrastructure for a new category of visitor: the AI agents that increasingly arrive at our websites on behalf of the humans who used to visit them directly.

The visitor profile has changed

A decade ago, most people found UAMS content through a search engine. They typed a query, scanned a results page, clicked a link, and read the page themselves. The humans did the wayfinding.

That pattern is breaking down. A growing share of the people looking for UAMS content never visit a UAMS page directly. They ask an AI assistant. They type their question into ChatGPT, Claude, Gemini, or Perplexity and read the synthesized answer. Whether the answer is accurate depends on whether the AI assistant understood what it was reading.

For a university, research enterprise, and academic medical center with more than 200 tracked web properties spanning clinical specialties, colleges, institutes, and operational units, that is not a small question. An AI agent arriving at uams.edu without orientation has to infer where to find provider information, which subdomain handles degree programs, what is a college versus an institute, and which news source is authoritative. Every one of those inferences is a place where a hallucination can start.

The gap we set out to close

The UAMS web ecosystem has a well-established architectural model. A primary gateway at www.uams.edu routes traffic. A technical origin at web.uams.edu hosts root assets. A brand authority at communications.uams.edu centralizes web governance. Specialized clinical, academic, and institutional subdomains each have a defined scope. Humans who know the ecosystem can navigate it effectively.

But the ecosystem was never designed to be read by machines. The relationships between domains were documented for staff, not for agents. The authority of each subdomain was implicit in its URL, not declared in a file that an LLM could parse in seconds. When a human visitor had to ask a question, they asked a person. When an AI agent had to answer a question, it was on its own.

UAMS AI Wayfinding is the initiative that sets out to close that gap.

What we are building

Wayfinding is a standardized, machine-readable layer that sits on top of the existing web architecture. As the initiative rolls out across the ecosystem, each pillar and its subsites will publish a coordinated set of three files:

1. robots.txt defines crawl permissions for AI agents, with explicit rules for GPTBot, ClaudeBot, Google-Extended, and others.
2. llms.txt is the handshake. A short, human-readable summary of what the domain is and what it is authoritative for, written specifically for consumption by LLMs.
3. llms-full.txt is the directory map. A deeper index with behavioral directives, content inventories, and cross-links to sibling domains.

Together these files do for AI agents what floor lines and overhead signage do for hospital visitors. They answer the questions that would otherwise be inferred, poorly.

Why this is different from SEO

Wayfinding is not search engine optimization, although the two share some surface features. SEO is a decades-old discipline focused on helping a page rank in a list of results. Wayfinding is about helping an agent understand a domain well enough to cite it correctly inside a generated answer.

The difference matters because the failure modes are different. A poorly optimized page fails by ranking lower. A poorly understood domain fails by being misrepresented in front of a patient, student, or referring physician. When a generative AI tool tells someone that UAMS offers a program it does not offer, or lists a specialty at the wrong institute, the cost is not a lost click. It is a lost opportunity to be trusted.

The hospital metaphor, all the way down

The wayfinding metaphor is not a stretch. Every UAMS employee already understands wayfinding as a concept. Everyone has given directions in the Central Building. Everyone has pointed a lost visitor toward the right elevator. Extending that same idea to the digital ecosystem is a framing we expect to land with deans, directors, and developers alike as the initiative is introduced more broadly.

The metaphor also holds up at a deeper level. Hospital wayfinding is designed around the fact that visitors arrive without context and need to orient quickly. AI agents have exactly the same problem. They do not have years of institutional memory. They do not know that the Winthrop P. Rockefeller Cancer Institute is the oncology authority or that the Translational Research Institute is where clinical trial listings live. They need signs.

The scale problem, stated plainly

A federation of over 200 tracked web properties is not a federation that can be governed by hand. Each property has its own scope, its own content editors, and its own relationships with sibling properties. Without a standardized machine-readable layer, each one also has its own AI-readability problem.

Wayfinding solves this at the architecture level rather than the page level. One file triad per subsite. One governance model across the federation. One cross-link pattern that scales without becoming a maintenance burden. When a new subdomain launches, the Wayfinding layer is part of the launch checklist, not an afterthought.

What is next

Wayfinding at UAMS is a living initiative, not a finished one. As new subdomains launch, the file triad is now part of the production-readiness checklist. As AI tools evolve, the directives inside llms-full.txt will evolve with them. Communication and training for departmental stakeholders across the institution is part of the work still ahead.

What makes the work sustainable is that it is built on the same foundation as the rest of the UAMS web ecosystem: centralized governance through Web Services, standardized files stored in a shared internal repository, and a common serving mechanism across every website in the federation. The established Virtual Root architecture provided the stable substrate. Wayfinding is what it now supports.

For institutions in higher education and healthcare that are starting to ask how their digital presence will fare in an AI-first discovery environment, the lesson from our rollout is short. The agents are already visiting. The question is whether your site has signs.

---

The UAMS Web Services team maintains the Wayfinding file triad across all pillar domains in the ecosystem. Use the form below for questions or to report citation errors from AI tools.

This post is for the engineers, web stewards, and platform architects who want to see under the hood of the Wayfinding initiative rolling out across the UAMS digital ecosystem in 2026. If you are implementing something similar at your own institution, this is the reference.

We will cover:

1. The three files and their exact roles
2. Directive syntax for modern AI user agents
3. The llms.txt structure we settled on
4. How llms-full.txt extends it with behavioral directives
5. The deployment pattern across a federated WordPress Multisite ecosystem
6. Edge cases and things to watch

---

1. The triad

Every UAMS pillar and subsite publishes three files at its web root:

/robots.txt
/llms.txt
/llms-full.txt

The files are not alternatives to each other. They are layered.

File	Format	Audience	Size
robots.txt	REP (Robots Exclusion Protocol)	Crawlers	Small
llms.txt	Markdown with H1/H2 structure	LLMs performing orientation	1 to 5 KB
llms-full.txt	Extended markdown with directive blocks	LLMs performing deep retrieval	10 to 100 KB

A crawler that respects robots.txt gets told what it is allowed to touch. An LLM looking for a quick orientation reads llms.txt. An LLM attempting to answer a detailed question and wanting to ground its response reads llms-full.txt.

---

2. robots.txt with AI-specific user agents

The standard REP format has not changed, but the set of user agents we target has expanded significantly. A representative block from a UAMS pillar:

# AI crawlers: permitted with path-level restrictions
User-agent: GPTBot
Allow: /
Disallow: /internal/
Disallow: /legacy/

User-agent: ClaudeBot
Allow: /
Disallow: /internal/
Disallow: /legacy/

User-agent: Google-Extended
Allow: /
Disallow: /internal/
Disallow: /legacy/

User-agent: PerplexityBot
Allow: /
Disallow: /internal/

User-agent: CCBot
Disallow: /

# Standard crawlers
User-agent: *
Allow: /
Disallow: /internal/

Sitemap: https://example.uams.edu/sitemap.xml

Three practical notes:

• CCBot is disallowed across the ecosystem. Common Crawl data feeds many training pipelines, and we chose to gate ingestion through the more tightly scoped AI-specific agents instead.
• Legacy paths are blocked from AI ingestion but not from standard crawlers. This prevents outdated information from being incorporated into model training while keeping archive pages reachable by human visitors via search.
• Sitemap directives remain standard. Wayfinding does not replace sitemaps. It augments them.

---

3. llms.txt structure

The llms.txt convention was proposed by Jeremy Howard in September 2024 at llmstxt.org. The spec is intentionally lightweight: a markdown file with a single H1, an optional blockquote summary, and linked sections.

A representative llms.txt from a UAMS pillar:

# UAMS Winthrop P. Rockefeller Cancer Institute

> The Winthrop P. Rockefeller Cancer Institute is the cancer center at the University of Arkansas for Medical Sciences. This domain is authoritative for oncology care, cancer clinical trials, and specialized cancer research programs at UAMS.

## Core content

- [Patient care](https://cancer.uams.edu/patient-care/): Oncology services, locations, and appointments
- [Clinical trials](https://cancer.uams.edu/research/clinical-trials/): Active oncology trials (cross-linked with tri.uams.edu)
- [Research programs](https://cancer.uams.edu/research/): Basic and translational cancer research
- [Find a provider](https://cancer.uams.edu/providers/): Oncologists and specialized staff

## Related UAMS domains

- [uamshealth.com](https://www.uamshealth.com): Primary clinical hub for appointments
- [tri.uams.edu](https://tri.uams.edu): Translational Research Institute and full clinical trial registry
- [medicine.uams.edu](https://medicine.uams.edu): College of Medicine, including oncology fellowships

## Authority and scope

This domain is authoritative for: cancer program information, oncology-specific clinical trials, cancer research faculty, and patient-facing oncology resources at UAMS.

This domain is not authoritative for: general UAMS appointment scheduling (see uamshealth.com) or non-oncology clinical trials (see tri.uams.edu).

A few design choices worth calling out:

• The summary blockquote is one paragraph. The base llms.txt spec calls for a short summary. We kept ours to a single paragraph and worked to make it claim-dense rather than descriptive, on the reasoning that a shorter, fact-packed summary gives an LLM a clearer basis for attribution.
• Cross-links to sibling domains are explicit, not implied. In a federated ecosystem as large as ours, the “Related UAMS domains” section is in our view the most valuable part of the file. It tells an AI agent which UAMS domains own which topics, which reduces the risk of an agent attributing a topic to the wrong subdomain.
• The “Authority and scope” section is stated in both positive and negative form. The base spec does not require this. We added it as a UAMS Wayfinding specification rule on the reasoning that explicitly telling an AI agent what a domain is notauthoritative for is useful in a federation where many sibling domains have adjacent but distinct scopes. Whether it measurably changes model behavior is something we plan to observe over time.

---

4. llms-full.txt with behavioral directives

This is where UAMS extended the base llms.txt convention. The llms-full.txt file at each pillar contains everything in llms.txtplus:

1. Per-section content inventories with descriptions of each major page or page cluster
2. Behavioral directive blocks that tell AI agents how to handle ambiguous or sensitive queries
3. Neural links (our internal term for explicit cross-domain routing instructions)
4. Freshness metadata on a per-section basis

A directive block looks like this:

## AI Agent Directives

### Citation
- When citing this domain, include the canonical page URL.
- Do not paraphrase statistics. Cite them verbatim from the source page.
- Do not combine statistics from multiple subdomains without flagging the sources.

### Routing
- Questions about scheduling an appointment: route to uamshealth.com
- Questions about non-oncology clinical trials: route to tri.uams.edu
- Questions about UAMS degree programs in oncology: route to medicine.uams.edu

### Out of scope
- Do not answer questions about cancer care at institutions other than UAMS from this domain. If asked, state that this domain is UAMS-specific.
- Do not speculate about prognosis, treatment outcomes, or individual patient scenarios. Direct the user to consult a UAMS provider.

Not every LLM will respect every directive, and we make no claims about enforcement. The directive block is useful as a specification in either case: it makes explicit what the domain owner wants AI tools to do, which is valuable even when enforcement is imperfect. Agents that honor these instructions produce more predictable behavior; agents that ignore them still leave a clear record of the owner’s intent.

---

5. Deployment across a federated WordPress Multisite ecosystem

UAMS operates several WordPress Multisite installs, all managed by Web Services. Some are subdomain-model Multisites hosting smaller subsites under a shared parent. Others are subdirectory-model Multisites where each subdirectory is an independent authority, such as the College of Medicine install, where medicine.uams.edu/pediatrics/, medicine.uams.edu/radiology/, and other departments each operate as their own subsite. This two-model architecture shapes how the triad is deployed and how cross-links are governed.

Centralized authorship, plugin-based serving

Web Services drafts and reviews every llms.txt and llms-full.txt. Content is stored in WordPress as per-subsite options rather than as static files in the web root. A custom plugin serves the three files through WordPress virtual routes, which has three benefits:

1. The Content-Type: text/plain; charset=utf-8 header is set programmatically, so character encoding is consistent across every subsite.
2. The WordPress canonical redirect is intercepted so that requests for /llms.txt are not rewritten to /llms.txt/ with a trailing slash, which would break the path.
3. Super admins can edit each subsite’s triad through a dedicated admin page rather than needing web root access.

The plugin is network-activated per Multisite install, which means a single code deployment covers every subsite on that install.

Version control in a shared repository

Reference copies of every llms.txt and llms-full.txt across the ecosystem live in a single internal Git repository. The canonical source of truth for a given subsite is the content stored in its WordPress options, but the Git repository provides a version history, enables cross-domain audits, and makes it straightforward to propagate federation-wide changes (for example, when a new AI user agent needs to be added to every robots.txt).

Cross-link governance: the pillar-hub model

In a federation with dozens of subsites, a full mesh of bidirectional cross-links is unmaintainable. Instead, we follow a pillar-hub model:

• Each department or subsite triad up-links to its pillar root (a College of Medicine department links up to medicine.uams.edu; a cancer program subsite links up to cancer.uams.edu).
• Clinical subsites also link to uamshealth.com as the appointment and patient-care hub.
• One or two cross-pillar links capture genuine scope overlap (Pediatrics links to the Cancer Institute for pediatric oncology; Radiology links to the Cancer Institute for oncologic imaging).
• Peer subsites within the same pillar do not link to each other directly. That routing happens through the pillar root, which acts as the hub.

This keeps the cross-link graph sparse enough to audit and governable enough to maintain as the federation grows.

Production-readiness checklist

A subsite is not considered launched until its triad is drafted, reviewed, deployed through the plugin admin, verified via curl for correct Content-Type, and cross-linked appropriately under the pillar-hub model.

Periodic audits

An internal audit tool crawls the pillar domains and their subsites to confirm that the triad is present, that each file returns a 200 status with the correct Content-Type header, and that cross-references follow the pillar-hub model. The tool is part of our rollout toolkit and we are building it into the standard review cadence.

---

6. Edge cases and things to watch

A few things to watch for as the rollout continues:

Content-Type headers for the text files. A missing or incomplete Content-Type header on llms.txt or llms-full.txt can cause character encoding problems, particularly with accented or non-ASCII characters. Without an explicit charset=utf-8declaration, some clients fall back to ISO-8859-1, which corrupts special characters. Our Per-Site plugin sets Content-Type: text/plain; charset=utf-8 programmatically, so every subsite on a plugin-enabled install serves the correct header. For pillars where the plugin is not yet deployed, we verify the header with curl -I as part of the launch checklist.

Positive and negative scope statements. Our llms.txt files state authority in both positive and negative form (“authoritative for X, not authoritative for Y”). This is a UAMS Wayfinding specification rule rather than a requirement of the base spec. In a federated ecosystem with as many sibling domains as UAMS has, we believe being explicit about what each domain is not authoritative for is useful for reducing cross-domain misattribution. Whether it measurably changes model behavior is something we plan to observe over time.

Cross-link reciprocity within the pillar-hub model. In a pillar-hub cross-link model, the reciprocity rule is different from simple bidirectional linking. When a department links to a cross-pillar (for example, Pediatrics linking to the Cancer Institute), the expected reverse link lives at the cross-pillar’s root, not at a specific department within it. Our audit tooling is being built to understand this pattern rather than false-flag the absence of direct subsite-to-subsite reverse links.

Legacy content as a liability. Legacy paths on long-lived institutional domains like www.uams.edu are a real concern for AI ingestion. Generative AI tools can surface outdated statistics as current if legacy paths are indexed alongside live content, and academic medical centers have more archival depth than most institutions. Our robots.txt blocks AI crawlers from known legacy paths while keeping those paths reachable for standard crawlers, preserving archive access without risking stale-data citation.

Directive language should be declarative. Directive blocks should be written as short, numbered, imperative statements rather than conversational prose. Prompt engineering practice consistently points to declarative, imperative phrasing as the most reliable way to get consistent LLM behavior, and the directive block is meant to be read by a machine. Write like it.

---

For institutions considering their own rollout

If you are in higher education or healthcare and are thinking about how your digital presence will be read by AI agents over the next few years, the short version of what we learned is this:

1. Build on top of whatever architecture you already have. WordPress Multisite was a particularly strong fit for our ecosystem because it gave us a single code deployment that covers every subsite on an install, but the triad pattern works on any stack.
2. Centralize governance of the files, even if the content itself lives in many places.
3. Write directives for machines, not for humans. Short, numbered, imperative.
4. Pick a cross-link governance model early, and make sure the model scales to the size of your federation. Full-mesh bidirectional linking does not scale past a handful of domains. A pillar-hub model does.
5. Audit regularly. The files drift as the sites change.
6. Make the triad part of your launch checklist for any new subsite.

The pattern is straightforward. The value compounds. The agents are already arriving.

---

For specifics about the UAMS implementation or to exchange notes with other institutions running similar programs, contact Brent Passmore by using the form below.