A common assumption about a tool like this is that a model reads your idea and invents the answer. That is not how the Architect works, and the distinction is worth stating plainly, because it changes how much you should trust each part of what you read.
The application pattern is chosen by rules. Your description is matched against the signals behind six patterns — Discover, Decide, Assist, Understand, Investigate, Predict — and the highest-signal match wins, with a stated confidence. Because it is deterministic, the same description always produces the same pattern, and a shared blueprint link rebuilds the identical result for the person you sent it to. Architecture decisions that change depending on when you asked are not architecture decisions.
The reason for rules is not distrust of models; it is that the pattern is the load-bearing decision. It determines the screens, the actions, the data you need, and the failure modes you should worry about. A choice that stable belongs to logic you can read and argue with, and you can override it yourself from the refine row whenever your judgement differs.
AI does one narrower job: it grounds the blueprint in your actual subject area. It names the domain in a few plain words, suggests realistic entities and questions a practitioner in that field would recognise, and describes honestly what makes the problem hard — data quality, privacy, regulation, or human trust. That is real work a rules engine cannot do, because it requires knowledge of hospital scheduling or freight logistics or school attendance that no pattern table contains.
Every one of those suggestions is labelled as a starting point to verify, and for good reason. A model can produce a plausible entity name for a domain it has only read about, and a plausible question no practitioner actually asks. Two minutes with someone who does the work daily is worth more than any confident-sounding list.
So verify in this order: does the intended user match a real role; does the decision or action match something that person actually decides; do the suggested tables map to systems you can really get data from; and would the listed questions be worth someone's time to answer. Anything that fails those checks should be cut before you build, not after.
The blueprint also degrades honestly. If the AI layer is unavailable — out of credits, switched off, or busy — a short note says so and the rest of the blueprint is unchanged and complete. Nothing in the architecture, scope, or starter prompt depends on a model being reachable at the moment you pressed the button.
That split is the whole design philosophy in one sentence: deterministic where the decision must hold, AI where context genuinely helps, and labelled everywhere the output should be checked before anyone builds on it.