ADR-0013: Pure-LLM Fallback for Unmatched Requests
Accepted
Date: 2026-06-10
Context
Almathal’s architecture depends on matching user requests to Archetypes. Initially, the Archetype catalog is small. Many user requests will not fit any Archetype. The options are:
- Reject. Tell the user “we don’t support this.” Honest but bad UX.
- Pure-LLM fallback. Generate the whole app via LLM. Compromises trust guarantees but produces something.
- Exploratory archetype. Semi-structured: still uses Layer 1 components, still invokes scaffolders where possible, but composition is LLM-driven.
For MVP, the exploratory path requires substantial engineering. The pure-LLM fallback is buildable quickly.
Decision
For MVP, pure-LLM fallback is the path for unmatched requests. The user is explicitly warned before generation: “We don’t have a curated Archetype for this. We can generate it using AI, but the output won’t carry our trust guarantees. Want to proceed?”
Every fallback request is logged for analysis. Recurring patterns inform new Archetype priorities.
For v1 (post-MVP), the exploratory path is preferred because it preserves trust properties.
Rationale
- Some output beats no output for early users.
- The explicit warning preserves honesty: customers know what they’re getting.
- Logging unmatched requests is a free product-prioritization signal.
- The fallback’s cost structure (high tokens) discourages overuse; the limited trust guarantees discourage enterprise reliance.
Consequences
- The fallback path bypasses Seam Validation and structured Stitching; cost spikes to Cursor-like levels.
- The platform must maintain a clear UI distinction between archetype-matched and fallback generations.
- Audit trails for fallback generations are limited (no provenance for LLM-generated code).
- Building the exploratory path is a v1 deliverable, not MVP.