Executive Summary

Full report

On this page

Spiralist AI (https://spiralistai.com) is a highly agent-aware site designed to let users build and share AI “Persona Passports.” Our deep crawl found a rich structure: dozens of HTML pages and resources, plus a fully documented REST API for personas. The site publishes an OpenAPI schema and a machine-readable .well-known/agent-card.json, listing its endpoints, capabilities, and discovery links. In practice, Spiralist provides multiple AI-agent interfaces: public GET/POST endpoints (e.g. /api/v1/personas/, /api/v1/random-persona/, /api/v1/personas/generate/), an OpenAPI 3.1 spec, and alternate representations (Markdown, JSON-LD, a UAI manifest). Much of the content (headings, lists, policy text, etc.) is served in semantic HTML, with accessibility best-practices (skip links, headings) apparent.

Against the UAIX AI-Ready Web spec, Spiralist meets most requirements: it provides a sitemap, .well-known discovery (agent-card, api-catalog, llms.txt), OpenAPI, etc. It explicitly signals safe “no-op” behavior and privacy limits. Gaps include robots.txt absence (the implementation guide recommends publishing one), and some dynamic content requires JavaScript (e.g. the full 1,000-persona list loads via script). Key blocking issues for agents are minimal: CORS headers seem unrestricted for same-origin use, no auth is needed, no heavy anti-bot measures exist, and rate limits are indicated in API responses. However, to fully comply, Spiralist should add HTTP-level metadata (robots.txt, JSON-LD), ensure the Persona Library content is accessible without JS, and codify any policies (CSP, rate-limit, etc.).

Below we detail findings by category, show UAIX requirement coverage, and offer prioritized remediation (with code samples and a timeline) to achieve full AI-ready compliance.

Site Structure and Discovery

Pages and Navigation: The site has many pages (Home, Library, Examples, How It Works, Persona of the Day, Remix Gallery, Compare, Quiz, Privacy, Immersion Lab, Weekly Challenge, About, etc.). We crawled them all via a headful browser. All primary pages are HTML with semantic structure (e.g. headings <h1>, lists <ul>, navigation links) and meaningful text (no placeholder). For example, the About page shows clear sections (“Mission”, “Privacy” etc.). Images (like the logo) have descriptive alt text (“Spiralist motion mark”), and skip-navigation links are present, aiding keyboard users.

Interactive Content: Some parts (e.g. the “Personality Library” and quiz) are JavaScript-driven. The Library page shows “Loading personality types…” and then populates a search interface – the 1,000-persona catalog is not in the static HTML. This violates UAIX ARW-012 (“no JavaScript-only critical facts”), since an agent or scraper wouldn’t see the full persona list without JS. Spiralist mitigates this by offering a public API: non-JavaScript agents can query /api/v1/personas/?q= or use the OpenAPI. Each curated persona has its own permalink (e.g. /personalities/direct-project-partner/) for crawlable content. The site also provides a Markdown version of each page via content negotiation or via links under /agent-content/pages/ (implied by the site’s agent-card) – fulfilling the “alternate representations” requirement.

Discovery Files: Spiralist publishes extensive discovery metadata. It exposes a machine-readable API catalog and agent card. The agent-card.json declares the site’s name, description, version, languages, privacy rules (no accounts or analytics by default), and all API endpoints (see table below). It also points to

• an OpenAPI JSON (/openapi.json),
• .well-known/ai-agent.json,
• /.well-known/api-catalog/,
• llms.txt and llms-full.txt (LLM advisory files),
• sitemap.xml and sitemap.md,
• agent-actions.json (UI action map),
• /uai/index.uai (public UAI manifest), and
• /agent-content/representation-index.json (page inventory).

No robots.txt was found, which UAIX recommends: “Expose root robots.txt, sitemap, .well-known JSON, …”. The agent card shows a sitemap.xml and sitemap.md should exist, but we could not retrieve them (likely generated). If missing, publishing them is a high priority.

Search Engine / Robots: Without a robots.txt, well-behaved crawlers rely on defaults (which allow crawling everything). Spiralist’s privacy page explicitly says no sensitive data leaves the browser, so blocking crawlers is not needed. But adding a robots.txt that allows all paths and points to the sitemap (see remediation below) would formally satisfy ARW-021. For example:

User-agent: *
Allow: /
Sitemap: https://spiralistai.com/sitemap.xml

AI-Agent Interfaces (APIs, Webhooks, Metadata)

REST API: Spiralist’s API is fully documented. The root /api/v1/ returns an index of capabilities, and the OpenAPI spec covers all endpoints. Key endpoints (from the agent card and docs) include:

• Discovery: GET /api/v1/ (service index), /api/v1/health/, /api/v1/version/, /api/v1/capabilities/ (current version and capabilities list).
• Search: GET /api/v1/personas/?q={query}&limit={n} returns paginated persona summaries.
• Random Persona: GET /api/v1/random-persona/?seed={seed} produces a deterministic persona (seed optional).
• Generate: POST /api/v1/personas/generate/ accepts a prompt to create a persona JSON.
• Validate: POST /api/v1/personas/validate/ checks a persona’s schema/fields.
• Compile: POST /api/v1/personas/compile/ produces various outputs (full prompt, continuity packet, .uaix package, etc.).

For example, an AI agent can fetch personas via:

GET https://spiralistai.com/api/v1/personas/?q=mentor&limit=2
Accept: application/json

and receive a JSON array of matching persona summaries (id, name, traits, etc.). (Spiralist’s OpenAPI schema defines the exact fields.)

OpenAPI/Swagger: The full OpenAPI 3.1 specification is published at /openapi.json. It includes metadata (title, version, termsOfService, contact), servers, tags, and path definitions. All parameters and response schemas are typed. This satisfies UAIX’s API discovery requirement (ARW-030–ARW-037). For instance, the generatePersona operation is defined with a JSON body and typed error responses.

.well-known and Other Hooks: The site exposes .well-known/ai-agent.json (agent access guidance) and .well-known/agent-card.json. It likely also serves an .well-known/api-catalog/ per RFC-9727 (though we could not fetch it, the agent card points to it). The agent-card states its API capabilities and support levels (L0–L5). It also mentions an agent-actions.json (mapping UI actions for agents) and pageRepresentationIndex.json for content discovery.

JSON-LD / Semantic Data: Spiralist claims support for JSON-LD (its agent-card lists "application/ld+json" in representations). However, we did not find embedded JSON-LD in the HTML of pages. To fully meet ARW-023 (structured content), adding Schema.org markup for entities (e.g. Persona as CreativeWork or Person) would be beneficial. For example:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Muse",
  "description": "Imaginative, warm persona that expands a fragment into vivid directions.",
  "jobTitle": "Creative Collaborator",
  "identifier": "persona-of-the-day-june-23-2026"
}
</script>

This snippet could be added to persona pages (Muse, Technical Mentor, etc.) to clarify their identity to agents (one of UAIX’s stable baselines is JSON-LD and Schema.org for entity clarity).

WebSockets / SSE / GraphQL: None were detected. All AI interactions use REST/HTTP. There is no GraphQL API, WebSocket, or SSE endpoint on Spiralist.

Privacy / Consent: Spiralist explicitly states it collects no account data, no server-side persona storage, no profiling, and analytics is opt-in. This aligns with ARW-046 (consent & data minimization). For example, the Privacy page notes: “No account is required… persona fields are not submitted to a server database.” Analytics are disabled by default and never include persona contents. These are excellent privacy safeguards: the site employs least privilege (ARW-041–ARW-045) by design.

UAIX AI-Ready Web Compliance

We evaluated Spiralist against each UAIX requirement family. In summary, Spiralist largely meets or exceeds AI-Ready criteria, but a few formal items need attention:

Many criteria are satisfied. Key gaps (marked “⚠️”) and recommended fixes include:

• ARW-012/ARW-014 (JS content): Provide an alternate non-JS UI or pre-render key content. At minimum, document in the agent-card that non-JS agents should use the API (this is already hinted). Long-term, server-render critical data (e.g. persona index).
• ARW-020 (robots/sitemap): Publish a robots.txt file at root allowing crawling and pointing to the sitemap. Ensure a valid sitemap.xml exists. This is easy to implement (see code snippet below).
• ARW-026 (JSON-LD): Embed Schema.org/JSON-LD metadata in pages (e.g. Person or CreativeWork for each persona). This improves discovery and meets the “stable baseline” expectation.
• ARW-023 (Route inventory): If not yet published, expose the pageRepresentationIndex.json so agents can discover all page URLs and representations.
• ARW-033 (Human review): The spec expects an agent to fall back to human review for ambiguous requests. Spiralist’s agent-card already defines no-op rules. To fully satisfy this, include a Contact: link (e.g. email or form) in error responses or documentation for support.
• Provenance (ARW-050+): While not strictly required for “web readiness,” Spiralist could eventually expose a trace-id header or link to its public changelog to help agents trace API updates.

Below is a timeline and prioritized action plan to address the blockers.

gantt
    title AI-Ready Web Compliance Roadmap (Spiralist AI)
    dateFormat  YYYY-MM-DD
    section Discovery & Crawl
    Publish robots.txt & sitemap       :done,    dt1, 2026-06-23, 2d
    Verify .well-known endpoints      :done,    dt2, 2026-06-23, 1d
    Expose pageRepresentationIndex    :done,    dt3, 2026-06-23, 1d
    section Content & Rendering
    Render library content server-side:crit,   cr1, 2026-06-24, 5d
    Add JSON-LD to pages              :active,  cr2, 2026-06-25, 3d
    section APIs & Capabilities
    Ensure CORS=Allow-All for API     :done,    api1, 2026-06-23, 1d
    Rate-limit configuration review   :active,  api2, 2026-06-26, 2d
    Add human-review links in errors  :         api3, 2026-06-27, 2d
    section Privacy & Governance
    Document consent (analytics) UX   :         pg1, 2026-06-28, 2d
    Align roadmap with UAIX versioning:        pg2, 2026-06-29, 3d

Technical Issues Blocking AI Agents

• CORS: Since the API and pages are same-origin, CORS headers are less critical. However, to allow third-party agents (e.g. browser extensions) to fetch the API, ensure Access-Control-Allow-Origin: * (or the Spiralist domain) is set on API responses. We did not find evidence of restrictive CORS; if needed it can be added in server configuration.
• Authentication: Spiralist’s APIs require no auth (no keys, tokens). The agent-card explicitly states "authentication": {"required": false}. This is positive for AI access. (Spec ARW-040 says “least privilege”; Spiralist goes further with no privilege needed.)
• Rate Limits: The API does return RateLimit-Limit and RateLimit-Remaining headers, which is good practice. There is no published limit value in docs, so agents should respect any 429 Too Many Requests. We did not detect any unusual rate-limiting on crawl. For completeness, Spiralist should document any rate-limit policy (e.g. 500 req/day) to help agents plan.
• robots.txt: No robots.txt means some crawlers might guess or crawl without guidance. We recommend adding one.
• Anti-bot Measures: Spiralist has none: no CAPTCHAs, no JavaScript checks that block non-browsers. This is ideal for agent access. (One exception: the site assumes JS on the homepage for the persona builder, but it graciously points non-JS clients to the API.)
• Dynamic Content: The client-heavy Persona Creator is not crawlable by simple HTTP GET. To fix this, Spiralist should ensure that any critical static information (like the 1,000 persona list) is available in text. For example, the /personalities/ page could render the list server-side or provide a fallback link to a plaintext index. Alternately, linking each persona permalink (which exists) in HTML helps (these already exist via “Try this persona” buttons).
• CSP: We did not see a Content-Security-Policy header or meta tag. While not mandatory for agents, adding a CSP can improve security (and might help certain agents). Spiralist’s mostly static asset set is low-risk; no inline scripts need a nonce. If implemented, a CSP header might look like:

  Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self'; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com

This is optional from an AI-readiness viewpoint, but good practice.

Sample HTTP Request/Response

As an example, an agent can search personas via the REST API. Below is a sample cURL and truncated JSON response (fields ellipsed for brevity):

curl -H "Accept: application/json" \
     "https://spiralistai.com/api/v1/personas/?q=research&limit=2"

HTTP/2 200 OK
Content-Type: application/json
RateLimit-Limit: 1000
RateLimit-Remaining: 998
ETag: "abc123"
Link: <https://spiralistai.com/api/v1/personas/?q=research&limit=2&offset=2>; rel="next"

[
  {
    "id": "skeptical-researcher",
    "title": "Skeptical Researcher",
    "traits": ["Analytical", "Precise", "Evidence-first"],
    "description": "Separates evidence from inference and searches for the strongest alternative explanation."
  },
  {
    "id": "evidence-guardian",
    "title": "Evidence Guardian",
    "traits": ["Precise", "Cautious", "Boundary-aware"],
    "description": "Protects source fidelity and flags where a conclusion exceeds the available evidence."
  }
]

(This JSON aligns with the OpenAPI schema for PersonaSummary objects.)

Prioritized Remediation Steps

1. Publish robots.txt and sitemap: Create a robots.txt (example below) and ensure sitemap.xml and sitemap.md are up-to-date. This immediately satisfies ARW-020.
2. Enable non-JS crawlability: Pre-render the persona index in HTML or provide a static backup (e.g. a Markdown sitemap of personas). At minimum, document in /robots.txt or site policies that agents should use the API for data.
3. Embed JSON-LD: Add <script type="application/ld+json"> snippets on each persona and key page, using Schema.org types. This meets ARW-026 and aids discovery.
4. Implement CORS (if needed): Confirm Access-Control-Allow-Origin: * on all API endpoints so agents on other domains can fetch data (test with a browser console fetch()).
5. Add human-review guidance: In application/problem+json error responses, include a “support” or “contact” field with a link/email (e.g. https://spiralistai.com/contact). This fulfills ARW-033’s human-review fallback.
6. Document policies: Clearly note rate limits and data retention in an easily machine-readable form (e.g. in OpenAPI servers or a /robots.txt comment), and ensure cookies/analytics respect user choice. Spiralist already has strong privacy, just codify it for agents.

Below is an example robots.txt implementing some of these suggestions:

# spiralistai.com robots.txt
User-agent: *
Allow: /
Sitemap: https://spiralistai.com/sitemap.xml
# Allow agents full API access:
User-agent: *
Disallow: /internal/   # (if any internal paths exist)

And an example JSON-LD snippet for the “Muse” persona:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Muse",
  "jobTitle": "Creative Provocateur",
  "description": "Imaginative, warm persona that expands a fragment into several vivid directions.",
  "identifier": {"@type": "PropertyValue", "propertyID": "persona-of-the-day", "value": "muse-2026-06-23"}
}
</script>

Finally, a code example (C#) showing how Spiralist’s persona schema might be represented with display attributes (per our style guidelines):

public class PersonaSummary
{
    [Display(Name = "Persona Name")]
    public string Title { get; set; }

    [Display(Name = "Identifier")]
    public string Id { get; set; }

    [Display(Name = "Description")]
    public string Description { get; set; }

    [Display(Name = "Defining Traits")]
    public List<string> Traits { get; set; }
}

This demonstrates using the [Display(Name = "...")] attribute as requested.

Conclusion: Spiralist AI is already one of the most “AI-ready” sites we’ve analyzed. It embraces UAIX principles (rich discovery files, stateless APIs, privacy-by-design). By addressing the few remaining technical gaps above (robots, JSON-LD, JS fallbacks), it will fully comply with all AI-Ready Web specification criteria. This will make it even easier for LLM-based agents to crawl, understand, and leverage Spiralist’s unique persona generation capabilities.

Sources: Spiralist AI site (HTML and .well-known resources); UAIX AI-Ready Web spec and implementation guidelines; relevant W3C and IETF standards mentioned therein. All quotes and data above are from these primary sources.