From Prompts to Specifications

Lexical Ambiguity and the Limits of Natural-Language Architecture

1. The Architect Who Never Left the Prompt

A specific pattern has become common: someone works extensively with an AI assistant, develops a genuinely sophisticated system description across many conversations, and is told — accurately, in one sense — that they've been doing architecture. What often goes unsaid is that the entire "architecture" exists only in natural language: prompts, chat history, markdown notes. No code has fixed what any term actually means. The architecture is exactly as precise as the English describing it, and English was never built to hold a specification's meaning fixed.

2. This Problem Is Not New, and Not Speculative

Requirements engineering has studied this exact failure mode for decades. Natural language is, in the field's own established framing, "universal, flexible, and wide-spread, but unfortunately also inherently ambiguous." The distinctive danger isn't that ambiguity exists — it's that it's usually invisible to the people using the ambiguous language: "often neither customers nor software developers recognize an ambiguity, and each derives an interpretation that differs from that of others without noticing this difference." An entire subfield — lexical disambiguation, structural disambiguation, referential ambiguity — exists because this problem is old, well-characterized, and expensive when missed. Hirst's foundational treatment of the subject remains a standard reference three decades later.

3. Direct Evidence, Measured, in 2026

This isn't only a historical argument. A 2026 study audited real medical-device software requirements by generating multiple independent formalizations of each one and checking them against each other with an SMT solver. Of 64 real requirements, 12 were ambiguous enough that independent formalizations of the same sentence actively disagreed — pairwise logical agreement across those formalizations sat at 44.0%. After forcing the ambiguous requirements through a clarification step and re-formalizing, agreement reached 100%, and zero requirements remained flagged as ambiguity-sensitive. That's not an argument for the general principle — it's a direct measurement of it, on a domain with no connection to this one, which makes it stronger corroboration, not weaker. The same paper found something further worth stating precisely: symbolic feedback only helps when it's specific — concrete counterexamples from the solver, not just a pass/fail signal, raised verified repair accuracy from 55.4% to 98.5% on a separate benchmark within the same study. Vague feedback barely moved the number. Specific, checkable feedback moved it enormously.

4. Why Code Specifically Closes the Gap

Not because code is "better" in some general sense — because of a precise mechanical difference. In natural language, meaning is recovered by shared inference over how words are typically used, which is exactly what makes a word like "channel" mean five different things depending on who's reading it. In code, meaning is fixed by syntax and execution semantics: a function either returns what the specification says or it doesn't, checkable by running it, not by two people inferring compatible interpretations of the same sentence. An architecture description that stays in prose can be internally consistent in the author's head and still support two incompatible readings in someone else's — and neither party will necessarily notice, for the same reason the RE literature has been documenting for decades.

5. What People Are Already Doing Right, Without Knowing Why

A common, practical pattern: someone maintains five or six markdown files that describe the same underlying system from different angles — the same rules, the same relationships, restated rather than merely repeated. Used consistently, this genuinely reduces ambiguity, and most people doing it couldn't say precisely why it works. It works because it's a real instance of Shannon's foundational insight about redundancy: sending the same message through a noisy channel multiple times, in independently-varied encodings, lets the receiver recover the intended signal by finding where the encodings agree, even though any single transmission alone might be lossy or ambiguous. Natural language is the noisy channel. Each markdown file restating the same ontology from a different angle is an independent transmission. An AI reading all of them can triangulate intended meaning from where they overlap — the same principle industry has already formalized elsewhere: Amazon's Automated Reasoning checks system explicitly "performs multiple redundant formalization steps at inference time, checking the formalizations for semantic equivalence" as a production disambiguation strategy. The instinct is sound. Most people doing it have simply never had the mechanism named.

6. A Different, Complementary Tool: Separation, Not Redundancy

It's worth being precise that redundant restatement isn't the only real tool here, and shouldn't be confused with a different one that solves a different problem. Kruchten's 4+1 View Model, a real and still-widely-used architecture framework, addresses complexity by deliberately not repeating the same information — it organizes a system description into distinct, non-redundant views (logical, process, development, physical, plus scenarios), each capturing concerns the others don't, because "complex software systems cannot be adequately described from a single perspective." That's a genuinely different move from restating one concern five ways to disambiguate it. Kruchten's views separate different concerns; the redundant markdown pattern triangulates one concern more precisely. Both are real, well-established, and worth using — for different jobs, not as substitutes for each other. Anyone building a serious specification should probably be doing both: Kruchten-style separation across concerns, Shannon-style redundancy within each one.

7. Putting It Together

The practical path this suggests isn't "abandon natural language" — prose is still how the underlying ideas get worked out. It's: organize the description into separated views the way Kruchten's model suggests, allow genuine redundancy within each view the way the markdown-files pattern already does instinctively, then integrate that material into one formal, checkable specification and debug it — not by reading it again, but by generating multiple independent formalizations and checking them against each other for disagreement, exactly as the 2026 audit did. Where they disagree, that disagreement is the ambiguity, made visible and fixable instead of silently shipped. This isn't a proposed methodology reaching for legitimacy — it's a real one, already demonstrated, being pointed at a new domain.

8. The Argument Applied to Itself

This site's own papers are a live instance of exactly this problem and exactly this fix. An earlier draft used the word "real" as a qualifier eighteen times in roughly fifteen hundred words — not incorrect, but imprecise enough to read as insistence rather than evidence. Another draft equated "prevents hallucinations" with "proposes evaluating" — two different claims that had been drifting together under one phrase. Another conflated statistical correlation with geometric orthogonality — different concepts that a first draft's wording let blur into each other. None of these were caught by re-reading the prose harder. They were caught by external review, forcing a precise restatement, and checking whether the restatement still said what was meant. That's the same mechanism this paper describes, run on this project's own words instead of someone else's requirements document.

9. Conclusion

Calling oneself an architect while remaining entirely inside natural language isn't a harmless shorthand — it's an unacknowledged ceiling on how strict the architecture can actually be, for reasons requirements engineering has documented for decades and a 2026 study just measured directly. The fix isn't mysterious and doesn't require distrusting the instincts people already have: redundant restatement across multiple documents is real error correction, not a workaround; separated views solve a different, complementary problem; and the endpoint — one formal specification, debugged by checking independent formalizations against each other — has already been built and shown to work, just not yet pointed at most of the places that need it.

References

Hirst, G. (1987). Semantic Interpretation and the Resolution of Ambiguity. Cambridge University Press.
IEEE (1993). IEEE Recommended Practice for Software Requirements Specifications. ANSI/IEEE Standard 830–1993.
Shannon, C. E. (1948). A mathematical theory of communication. Bell System Technical Journal, 27(3), 379–423.
Kruchten, P. (1995). Architectural blueprints — the "4+1" view model of software architecture. IEEE Software, 12(6), 42–50.
Hall, B., & Eiers, W. (2026). Neurosymbolic auditing of natural-language software requirements. arXiv:2605.13817. Stevens Institute of Technology.
An, C., et al. (2025). A neurosymbolic approach to natural language formalization and verification. arXiv:2511.09008.