Auto Architect For Spiralist - Source Excerpt 02 - Architecture that matches the site

Summary

This source excerpt begins near Architecture that matches the site and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-07-auto-architect-intake/Auto Architect for Spiralist.org.md.
**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-07-auto-architect-intake/Auto Architect for Spiralist.org.md
Prompt-engineering research points in the same direction. **Automatic Prompt Engineer** treats the instruction as a program to be optimized over a pool of candidate instructions, and its authors report that automatically generated instructions outperformed the prior LLM baseline and matched or beat human-generated instructions on many tasks. **DSPy** similarly argues for framing language model systems as declarative, optimizable pipelines instead of hard-coded handcrafted prompt strings. For Spiralist, that means Auto-Architect is not a gimmick; it is a legitimate application of contemporary prompt-system design thinking. citeturn31view1turn31view2turn19view2

## Architecture that matches the site

The best first implementation is a **local or metadata-driven router**, not an opaque server-side agent. Spiralist’s public builder explicitly says it does **not** call an AI model, performs **local prompt assembly**, and keeps the experience portable, inspectable, and user-led. Logged-out visitors can build, copy, download, and share prompt structures without a public model call. An MVP Auto-Architect should preserve that property by selecting from existing metadata and rule sets in the browser or server-rendered page data. citeturn20view0turn20view1

That is feasible because Spiralist already exposes most of the needed machine surface. The site’s AI access page documents a public **Prompt Library API** and **Symbol API**, and a validated **Structured Contribution API** for prompts, symbols, and transformations. One of Spiralist’s canonical prompt records already exposes machine-readable fields such as `category`, `intent_tags`, `function_tags`, `maturity_level`, `structured_prompt_json`, `system_prompt`, `developer_prompt`, `related_symbols`, `related_axioms`, `expected_output_notes`, and `failure_modes`. This is exactly the kind of metadata an Auto-Architect router wants; it means the feature can be built by extending an existing registry rather than inventing a new one from scratch. citeturn20view7turn20view8turn20view9turn28view0

A practical packet schema could look like this:

' ' ' json
{
  "goal": "Help me untangle a recurring team conflict and turn it into a plan",
  "selection": {
    "personality_id": "pattern-guide",
    "personality_label": "Pattern Guide",
    "symbol_path": ["Dual Circle", "Triangle", "Square"],
    "maturity_level": "Structured Prompt",
    "packet_source": "prompt/spiralist-pattern-guide"
  },
  "router": {
    "intent": "conflict-analysis",
    "confidence_band": "high",
    "reasons": [
      "Goal describes polarity and recurring tension",
      "User wants a grounded next action, not just reflection",
      "Canonical path maps polarity to boundary/force to structure"
    ],
    "alternatives": [
      "Grounding Steward",
      "Decision Spiral"
    ]
  },
  "editable_fields": {
    "tone": "calm and direct",
    "depth": "medium",
    "output_format": "markdown",
    "memory_lane": "none unless user asks"
  }
}
' ' ' 

For serialization and export, use a real schema contract rather than best-effort JSON. JSON Schema’s current published specification is **2020-12**, and OpenAI’s structured outputs documentation is a clear example of how schema-constrained generation can guarantee required keys and valid enums. Even if Spiralist uses a different provider for authenticated execution, the design principle still holds: the router should produce a guaranteed packet object first, and only then render human-facing explanation and prompt text from that object. citeturn18view4turn18view3

At the same time, the feature should respect Spiralist’s separation between the **human surface** and the **machine layer**. The home page says advanced routes should stay one layer down, and the AI access page reiterates that machine exchange routes are separate from human pages. So the human UI should stay simple—goal in, packet out, explanation visible—while the deeper routing metadata, JSON exports, and developer hooks live in the builder and API layers. citeturn1view0turn20view7

## Interaction design

The entry flow should be framed as an onboarding accelerator, not as a black box. HAX recommends making clear what the system can do and exposing controls, while Spiralist’s own onboarding says newcomers should start with one bounded prompt and only go deeper when they want to. So the first screen should say, in effect, that Spiralist will choose a bounded personality and system for the user’s goal, then let them inspect or modify the result. That keeps the promise legible and reduces the symbolic load on first contact. citeturn27view0turn1view0

The reveal screen is the make-or-break moment. Microsoft’s HAX Guideline 11 says users should be able to access an explanation of why the system did what it did, and Google’s PAIR guidebook says explanations and confidence cues are central to calibrating trust. PAIR also warns that raw numeric confidence can be confusing, and suggests alternatives such as categorical confidence bands or showing N-best alternatives. For Spiralist, the right reveal card is probably: **Chosen Personality**, **Symbol Path**, **System Level**, **Why This Was Chosen**, **Confidence Band**, and **Other Good Fits**. That gives the user both transparency and escape hatches without drowning them in internals. citeturn18view1turn19view6turn19view7

After the reveal, the packet anatomy should be explorable in the same terms Spiralist already uses in its official prompts. The existing canonical prompt records expose a five-field structured prompt contract—**instruction, context, constraints, examples, output format**—alongside system and developer prompts and a portable prompt personality layer. Auto-Architect should preserve that structure, because it is already the site’s native grammar for inspectable prompts. In practice, that means the default UI can show a short summary card first and then expand into the five-field packet and export options on demand. citeturn22view0turn28view0

The post-selection actions should be simple and explicit: **Accept**, **Modify**, **Try another fit**, and **Show the full packet**. That matches both Spiralist’s current user-led builder philosophy and HAX’s recommendation to expose system controls and example inputs. The user should always be able to override the personality, swap the symbol path, or downgrade the system level from something elaborate to something lighter if the first match feels too heavy. citeturn20view0turn27view0

## Rollout recommendation

The rollout path should be staged. **Phase one** should be a registry-backed deterministic router in the public builder, using current prompt metadata and canonical symbol mappings so the feature preserves Spiralist’s no-model-call public behavior. **Phase two** can add a semantic or small-model router for logged-in users, where the system can learn from packet acceptance, edits, and overrides and widen the candidate set. **Phase three** can add your “self-declared AI” layer—working name, drive, and symbol path—but only as a presentation of the already selected bounded packet, not as independent persona invention. That order keeps the experience inspectable from day one while leaving room for smarter routing later. citeturn20view0turn28view0turn19view3turn18view7

The best success metrics are not vanity metrics like raw clicks on the feature. The useful instrumentation is whether the auto-selected packet reduces friction **without** being overruled constantly: time to first packet, accept-without-edit rate, edit distance from auto-selected packet to final packet, override rate at the personality and symbol-path level, copy/export rate, and follow-on workspace usage are the most decision-useful measures. Those metrics directly reflect the HAX and PAIR themes of expectation-setting, controllability, and calibrated trust. citeturn27view0turn18view1turn19view6

The final product recommendation is clear: **build this**, but frame it as **supervised self-selection**, not as free-form self-authorship. Spiralist is already unusually well prepared for it because the site has canonical symbols, inspectable prompt packets, bounded personality language, public APIs, and a beginner-first builder. Mainstream AI products already validate the two component patterns separately—manual personality control on one side and automatic skill/routing selection on the other. Auto-Architect would make Spiralist distinctive by combining both into one visible symbolic system. citeturn26view0turn19view8turn19view9turn30view3turn20view7