How the decisions get made
What follows is written to be checked rather than believed. Each area states how it works and where it stops, including the parts that are not built yet.
How the interview works
Questions are chosen for how much they change the answer, not in a fixed order, and the interview refuses to finish before the critical inputs exist.
Each question belongs to one of fifteen domains - business, traffic, workload, data, geography, security, compliance, reliability, operations, team, budget, AI, integrations, growth and constraints.
Every question carries an impact rating. Candidates are ranked by impact and by how much unresolved information they close, so the questions that matter most come first rather than the ones that are easiest to ask.
The interview ends only when the critical inputs are resolved. That gate is a scored decision with a high risk rating and a high confidence threshold, precisely because generating an architecture on incomplete inputs is the most expensive mistake this product could make.
Where this stops
The question catalog is authored by us. You can see it in the demo teaser, but you cannot yet supply your own question set.
How assumptions are handled
Every requirement is labelled with how it is known - confirmed, inferred, assumed or unknown - and assumptions are shown as assumptions rather than silently filled in.
When you answer, the input is classified before it is stored. A figure you state is a confirmed fact. A figure derived from something you said is an inference. A gap the system closes on your behalf is an assumption, and an unanswered critical field stays unknown.
Those labels travel with the requirement into the comparison, the cost model and the report. An assumption never becomes a confirmed value just because it was used in a calculation.
This is the same distinction the demo teaser shows: each reading is marked as stated or deduced, along with the words that produced it.
Where this stops
A wrong assumption is still wrong. The labels tell you what to double-check rather than removing the need to check it.
How pricing is sourced
Costs are modelled arithmetic over a maintained catalog of component prices. Break-even maths is calculated exactly. Neither is a quote from a provider.
Cost models are built from the architecture they describe: each component carries a baseline monthly cost, and the quantities you supplied - storage, throughput, token volume, seats - scale it.
Break-even calculations, such as the point at which a self-hosted model beats paying per token, are arithmetic rather than estimates. Given the same inputs they produce the same number every time.
Every figure carries a provenance label. Modelled output is labelled an estimate; only a figure taken from an actual bill is presented as confirmed.
Where this stops
Dated provider pricing snapshots with source links are a stated requirement and are not in place yet. The baseline catalog is maintained internally and updated by us, without a per-figure timestamp or a link to the provider page. Until that exists, treat every cost as an estimate to verify.
How recommendations are generated
Deterministic engines do the calculating. Pattern matching against your confirmed requirements does the proposing. A model is never allowed to invent a number or an option.
Candidate architectures come from a curated pattern library, scored for how well they fit your confirmed requirements. The score and the requirements behind it are kept, so a recommendation can be examined rather than taken on faith.
Cost, risk, resilience and compliance outputs are computed by deterministic code from published rules. Where something can be calculated or enforced directly, no model is involved - that is a design rule, not an implementation detail.
A model may classify an answer, phrase a question or summarise a trade-off. It is not the thing that decides what your architecture costs.
Where this stops
The pattern library is finite. If your situation is genuinely unusual, the closest pattern may still be a poor fit, and the comparison shows that as a lower fit score rather than hiding it.
What compliance readiness means, and what it does not
Technical architecture controls are mapped against framework considerations. This is not certification, and it is not legal advice.
For a framework such as HIPAA, the assessment lists the technical controls an architecture does or does not cover: encryption at rest and in transit, audit logging, backup policy, secrets management, and so on.
Controls that need attention appear as needing attention. Items that are not architectural at all - a signed BAA, an employee access policy, an incident response process - are listed as outside architecture scope rather than quietly counted as done.
The result is a view of your architecture against technical considerations. It is not a compliance status.
Where this stops
Certification, legal advice and regulatory confirmation are out of scope. Anything an auditor or your counsel must sign cannot come from this product.
How infrastructure code is validated
Generation is implemented. Validation is not, and generated files say so on their first line.
Terraform is generated from the selected architecture as a set of files - providers, networks, compute, data, variables and outputs - so the architecture and the code describe the same system.
Validation is the part that turns generated code into trustworthy code: parsing it, running a plan against a sandbox, and scanning it against policy rules. That is scheduled work and it is not built.
Until it is, every generated file carries a header stating that it has not been validated and must be reviewed before it is applied.
Where this stops
Do not apply generated Terraform to production without reviewing it. Treat it as a well-informed first draft, which is what it is.
How far traceability goes today
A recommendation traces back to the requirements that drove it. Provider documentation and pricing sources are not attached yet.
The intended chain is: your requirement, the architecture rule it triggered, the provider documentation behind that rule, the pricing source for the numbers, and the assumptions in between.
What exists now is the first two links, plus the assumptions. Each recommendation records the requirements that drove it and the alternatives it was chosen over, and decision records preserve that reasoning.
Provider documentation references and dated pricing sources are planned, which is why the evidence drawer is described here as a direction rather than a feature.
Where this stops
You cannot currently click through from a recommendation to a provider document. The reasoning is recorded; the citations are not.
The decisions are declared
Every judgement the product makes, and the confidence it demands
Nothing decides by feel. Each judgement is specified in advance with its risk level and the minimum confidence required to accept an answer. Below that threshold the engine refuses and asks, rather than guessing.
| Decision | Risk | Minimum confidence |
|---|---|---|
| interview.answer_adequacy.v1Determine if user answer resolves the required information or needs clarification | LOW | 80% |
| interview.assumption_type.v1Classify user statement as explicit fact, estimate, assumption, or unknown | LOW | 85% |
| interview.contradiction.v1Determine whether the answers recorded disagree with each other, so the reader resolves it rather than the engine overwriting one silently | MEDIUM | 90% |
| interview.confirmation_required.v1Determine whether a fact read out of the reader's own words needs their decision before it is treated as an answer they gave | LOW | 85% |
| interview.next_question.v2Rank highest decision-impact candidate question from unresolved requirements | MEDIUM | 88% |
| interview.completion.v1Determine if minimum architecture context is sufficient to generate valid strategies | HIGH | 90% |
| routing.model_selection.v1Route task to System 1 micro-decision, fast LLM, or System 2 deep reasoning | LOW | 85% |
| architecture.pattern_fit.v1Score architecture pattern suitability against confirmed requirements | HIGH | 90% |
| architecture.candidate_score.v1Weigh the shortlisted architecture plans and name the one the reasoning pass would put first | MEDIUM | 85% |
This table is read from the decision registry in the codebase rather than retyped from a document, so the thresholds shown are the thresholds enforced.
Intelligence
Three layers, and which of them are working today
Typed decision engine
In use todayThe layer that decides
Every judgement is declared in advance as a decision specification: what it is for, how risky it is, which outputs are permitted, and the minimum confidence required to accept an answer. A judgement below that threshold is refused rather than guessed, and the specification version is recorded with the outcome. The thresholds themselves are printed in the table above, straight from the code that enforces them.
Fast language model
In integrationThe layer that reads and phrases
For extraction, summarisation, question phrasing and routine explanation - work where being approximately right is acceptable, because the result is either reviewed by you or checked by the decision engine.
Deep reasoning model
In integrationThe layer that thinks harder when it must
Reserved for problems that genuinely need deliberation: novel edge cases, migration reasoning, and difficult trade-offs among options that have already been shortlisted and costed. It is deliberately not used for anything a deterministic engine can calculate.
Deterministic work stays deterministic
Pricing arithmetic, break-even maths, risk thresholds, policy checks, entitlement logic and infrastructure validation are computed in code. A language model is never asked to do a sum a function can do, because a function gives the same answer every time and can be tested.
This assessment covers technical architecture considerations only and does not constitute legal advice, certification, or confirmation of regulatory compliance.
Check the method against your own problem
The interview teaser runs the same question catalog described above, in your browser, with no account.