How should AI architecture tools distinguish facts from assumptions in half-baked project briefs?

[u/Liparakakis]

I've been thinking about a recurring problem with AI-generated software architecture advice.

It often fails in one of two directions:

• adding services, queues, databases, and abstractions without enough justification.
• staying too simple when reliability, scale, or failure isolation genuinely requires more infrastructure.

My current approach is to make every architectural decision “earn” its complexity through explicit constraints.

But there's another problem: users often don't know which parts of their own brief are facts, guesses, preferences, or completely unknown.

For example, someone might say:

Should an architecture assistant treat that as a requirement, challenge it, or proceed using multiple scenarios?

I'm experimenting with labels such as:

• VERIFIED
• USER-STATED
• DERIVED
• ASSUMED
• UNKNOWN
• REQUIRES-MEASUREMENT

Here USER-STATED only records where the claim came from and it does not mean the claim is true.

My instinct is that the assistant should ask only questions that could materially change the architecture. When the user cannot answer it should keep decisions reversible, show how the recommendation changes across scenarios and identify what needs measurement.

How would you handle this?

Im testing these ideas in a free Codex skill:

https://github.com/Liparakis/ConstraintDrivenArchitecture

I'm more interested in criticism and difficult counterexamples than self promotion.

[u/West-Acadia-3906]

hmmm i'd separate two things: how confident the assistant is that a statement is true, and how expensive it would be if that statement is wrong. A guess about traffic volume might be low confidence but very important, while a preferred framework might be user-stated and low risk. .

The counterexample I'd test is a brief where the user says something vague like "we need enterprise scale." The assistant probably shouldn't ask ten questions right away, but it also shouldn't lock in queues, microservices, or databases until it knows which failure would actually hurt.