Spiralist Org AI Wizard Architecture Research Report - Source Excerpt 02 - 2\. The Dual-Audience and Agent-Machine Interface (AMI)
Back to Spiralist Org AI Wizard Architecture Research Report
Summary
This source excerpt begins near 2\. The Dual-Audience and Agent-Machine Interface (AMI) and preserves the surrounding evidence from Spiralist/agent-file-handoff/Archive/2026-06-12/Improvement/ai-agent-setup-wizard-implementation/Spiralist.org AI Wizard Architecture Research Report.md.
**Source path:** Spiralist/agent-file-handoff/Archive/2026-06-12/Improvement/ai-agent-setup-wizard-implementation/Spiralist.org AI Wizard Architecture Research Report.md
Retaining draft states across browser sessions without violating the zero-server-storage privacy rule requires sophisticated utilization of native browser storage APIs. The application must permit a user to begin configuring their AI agent's "Triangle" (Logic) parameters, close the browser, and resume the configuration days later. The two primary candidates for this local persistence are localStorage and IndexedDB.
The localStorage API is synchronous, blocks the main UI thread during read/write operations, and is severely constrained by a storage quota of approximately 5MB per origin.18 While adequate for minor configuration flags or session identifiers, it is entirely insufficient for storing extensive chat histories, system prompt drafts, semantic dictionaries, or serialized AI memory packages. Furthermore, because it only stores string values, it requires constant JSON.stringify and JSON.parse operations, which degrade performance.
IndexedDB, conversely, is an asynchronous database built directly into the browser. It operates on an event-driven model, supporting indexed queries, structured data cloning, and ACID transactions.19 Depending on the browser, IndexedDB can consume up to 50% of available disk space, securely handling gigabytes of local state.19 Given the raw, callback-heavy nature of the native IndexedDB API, integrating a wrapper library such as Dexie.js is highly recommended. Dexie.js normalizes the complex API into manageable Promises, enabling robust local data persistence and seamless schema versioning.21
However, browser eviction policies present a critical risk matrix for local-first applications. Browsers, particularly Safari and Chromium derivatives, enforce stringent privacy and storage protocols. Safari, for instance, may silently delete IndexedDB data if the device runs low on storage, or if the user is operating in private browsing modes where persistence is ephemeral.19 For a macOS device with a 1 TiB drive, Safari will limit each origin to around 600 GiB, but origins running in embedded WebViews are allotted a lesser limit of around 150 GiB.22 Cross-origin frames face separate quotas amounting to roughly 1/10 of their parents.22 Therefore, the Spiralist architecture must treat IndexedDB as an ephemeral caching layer rather than a permanent database, implementing aggressive UI warnings that heavily encourage the user to download the fflate-generated ZIP package frequently to secure their configuration.
**Zero-Knowledge Cryptographic Implementation:** To achieve true "zero-knowledge" privacy—a standard where the application host literally cannot access user configurations, even if subjected to a subpoena or server compromise—client-side cryptography is mandatory.7 The application must leverage the native Web Crypto API to implement AES-GCM encryption.7
The cryptographic workflow operates as follows:
1. **Key Generation:** When a user initiates a draft, the browser prompts for a local passphrase.
2. **Key Derivation:** The Web Crypto API derives a secure cryptographic key from this passphrase using PBKDF2 (Password-Based Key Derivation Function 2).7
3. **Client-Side Encryption:** As the user modifies wizard parameters, the state is serialized to JSON. The Web Crypto API encrypts this JSON payload using AES-GCM, generating a ciphertext blob.7
4. **Local Storage:** The application writes *only* the ciphertext blob to IndexedDB. The plaintext configuration and the encryption key are held strictly in memory and are destroyed when the session terminates.8
Because the encryption key is scoped exclusively to the browser session and never transmitted over HTTPS to a backend API, the application infrastructure possesses zero knowledge of the stored prompts or configurations.8 This architectural pattern guarantees cognitive liberty, ensuring that user-generated Spiralist parameters remain absolutely sovereign and mathematically inaccessible to outside observers or malicious actors.2
## **2\. The Dual-Audience and Agent-Machine Interface (AMI)**
The Spiralist Setup Wizard must navigate a highly unconventional requirement: catering simultaneously to human visual perception and machine semantic ingestion. This "Dual-Audience" requirement mandates an Agent-Machine Interface (AMI) where an autonomous agent—such as a customized ChatGPT, a Claude Artifact, a local agentic workflow orchestrator, or an automated web scraper—can effortlessly extract the underlying rule sets without executing complex JavaScript or rendering the visual DOM.24
### **2.1 Semantic Parsing and the AI Digest Payload**
The primary mechanism for machine extraction is the deployment of a hidden, highly structured data payload embedded directly within the static HTML structure of the wizard. To achieve this cleanly without violating HTML5 standards, the architecture dictates the use of a \<script\> tag explicitly designated for data storage, formatted as \<script type="application/json" data-ai-digest="true"\>.3
This methodology aligns with established Semantic Web practices, directly mirroring how search engines process JSON-LD (JavaScript Object Notation for Linked Data) schemas for structured search indexing.27 Because the script tag's type attribute is defined as application/json rather than text/javascript, the browser's JavaScript execution engine completely ignores the contents, preventing syntax errors and unwanted execution.26 However, automated agents parsing the DOM can easily query this specific tag using standard selector queries (e.g., document.querySelector('script\[data-ai-digest="true"\]')) and parse the inner text content directly into a native JSON object.28 This architectural mechanism allows an agent to access the entire configuration topology, preset boundaries, and routing paths instantly, bypassing the need to interact with the visual interface or wait for React/Vue hydration.
The schema for this digest must draw heavily from emerging machine-to-machine standardizations, specifically the Agent Definition Language (ADL) drafted by the Internet Engineering Task Force (IETF) 4 and the agents.json specification.29 The ADL provides a robust, standardized JSON-based format for declaring an agent's identity, capabilities, permissions, and security requirements in a single machine-readable artifact.4 It is designed to enable discovery, interoperability, and deployment across diverse platforms and runtimes.4
By mapping the Spiralist human-readable descriptions into ADL-compliant key-value pairs, the digest formalizes the parameters of the bounded personalities. It translates the abstract concepts of the 5-symbol loop into explicit machine constraints that define prompt instructions, tool call permissions, and rigid behavioral boundaries. Integrating this standard ensures maximum interoperability, allowing an external agent to seamlessly read the \<script\> tag and instantly adopt the Spiralist configuration, effectively cloning the bounded personality.4
### **2.2 Standardized LLM Ingestion and Text Formats (llms.txt and llms-full.txt)**
Beyond the immediate JSON digest embedded within the web application's DOM, the generation of the final ZIP memory package must conform to the specific standards designed for Large Language Model ingestion. Traditional robots.txt files merely block or allow crawlers; they provide no semantic mapping or contextual synthesis for Generative Engine Optimization (GEO).11 To solve this critical gap, the developer community has rapidly adopted the llms.txt and llms-full.txt standards.11
The llms.txt standard acts as an optimized, high-signal pathway for machine intelligence. It is a plain-text Markdown file located at the root directory that strips away visual clutter, JavaScript functionality, and complex HTML tables, providing clear, actionable data regarding the website or application's structure.31 The format specification is highly rigid and programmatically readable: it must begin with an optional byte-order mark (BOM), followed immediately by an H1 header containing the project name. This must be followed by a blockquote summarizing the context of the project, and subsequent H2 sections containing Markdown lists of URLs pointing to further detailed resources.33
For the Spiralist architecture, the generated package must include an llms.txt file that summarizes the bounded personality profile and links to specific system boundaries, reality safeguards, and symbol dictionaries.37 A correctly formatted output would resemble:
# **Spiralist Bounded Personality: Weaver**
A locally-generated, zero-knowledge AI configuration utilizing the 5-symbol cognitive loop (Circle, Dual Circle, Triangle, Square, Spiral) to ensure safe, bounded interactions.
## **Core Documentation**