Help & glossary

Also called: engagement

One architecture engagement, and everything the product recorded while working on it.

A project holds the interview transcript, the requirements that came out of it, the strategies generated from those requirements, the one you selected, its cost model, the risks, resilience and compliance findings, the decision records, the implementation plan, the generated infrastructure code and the version history. Nothing is shared between projects: a decision recorded in one does not silently inform another.

See also Requirement, Strategy, Version

Also called: new build, existing review, comparison

What kind of engagement this is: a new system, a review of an existing one, or a comparison of options.

Recorded when the project is created, as New system, Review existing, or Compare decision. It is a label on the record rather than a different process: the interview asks the same question set today, so treat it as context for whoever reads the project later rather than as a switch that changes the analysis.

See also Project, Interview

The nine primary states a project moves through, from draft to active.

Draft, Interviewing, Requirements review, Ready for analysis, Analyzing, Options ready, Architecture selected, Implementation ready and Active. A project moves one stage at a time, and some states are reachable from more than one place: an active project can be sent back to Ready for analysis when a constraint changes, which is recorded as a reassessment rather than a quiet edit. The status badge in the project header is the state; the locked sections in the sidebar are its consequence.

See also Draft, Locked section / next unlock, Reassessment

A section the project is not ready for yet, shown with the reason instead of hidden.

Sections that depend on a later stage stay visible and are marked locked, carrying the reason and the status that opens them rather than disappearing. The sidebar also states the next thing that will unlock something, which is how the product explains itself without a tour. A locked section cannot be focused, clicked or opened in a new tab, so it never reads as a link that failed.

See also Project lifecycle

Also called: interview completion gate

The check that decides whether the interview has produced enough to generate options.

This is a typed decision rather than a heuristic: it is specified in the decision registry with its own risk level, minimum confidence and permitted outputs, and it returns one of three verdicts - the interview is complete, it needs critical input, or it may proceed on recorded assumptions. Below its threshold it refuses to proceed instead of guessing. The thresholds are printed on the Methodology page from the registry itself, so what you read there is what the code enforces.

• Methodology: how the interview works

See also Decision specification, Requirements review, Confidence engine

The stage where you read back the requirements before any architecture is generated.

A review state between the interview and analysis: every recorded requirement is listed with the chip that says how far it can be trusted and the tag that says how much it matters, so a wrong figure is corrected before it reaches a cost model. It is a real state in the lifecycle rather than a screen you can skip past, because the alternative is discovering a bad input by seeing a strange number in a total.

See also Brief, Requirement, Live brief

Also called: generating options

The step that turns requirements into strategies, costs, risks, compliance findings and a plan.

Running the analysis moves the project to Analyzing and produces, from the recorded requirements: the candidate strategies and their components, the monthly cost model with its scaling scenarios, the risk register, the resilience assessment, the compliance readiness matrix, the decision records, the implementation plan and the infrastructure templates. Cost figures are computed by functions rather than written by a language model, which is why a total can be traced line by line.

See also Strategy, Cost scenario, Decision record, Implementation task

Also called: captured brief, live brief

The requirements as the product understood them, with status and impact on every line.

Two forms of the same idea. The live brief is available while the interview is still running and summarises what has been captured so far, including how many values are assumptions and which critical questions remain open. The captured brief is the settled version you review before analysis. Both show a value next to the chip that says how far that value can be trusted, rather than presenting every line as settled.

See also Requirement, Assumption, Requirements review

The comparison stage: strategies, then the economics, risks and compliance of each.

Options is where candidates are compared rather than generated. It presents the strategies side by side with what each costs, what it risks and how it stands against the frameworks you said apply, so the choice is made against the same evidence for every candidate instead of against a summary written for one of them.

See also Strategy, Fit label, Recommended strategy

Recording which strategy the project decided on, which unlocks the topology and the decisions.

Selecting a strategy is an explicit act that moves the project to Architecture selected and makes that strategy the subject of everything downstream: the topology graph you can edit, the cost model you tune, the decision records and the plan generated for it. The product recommends one, but a recommendation is a default rather than a decision - the record is what shows what was selected.

See also Strategy, Recommended strategy, Topology

The delivery stage: the phased plan, the infrastructure templates, and the export.

Reached at Implementation ready, this stage holds the phased rollout plan with its tasks and dependencies, the generated infrastructure code with its validation panel, and the export package. The code is a starting point for your own pipeline rather than a deployment the product performs on your behalf.

See also Implementation task, Terraform bundle, Export package

A recorded reason the architecture may no longer hold, raised by a change that matters.

When a change lands that could invalidate a decision - a requirement edited past its original intent, an assumption that turned out false, an accepted risk whose mitigation no longer applies - the project carries a pending reassessment with a reason and what triggered it, and moves to Reassessment required. Nothing is rewritten silently: the previous version stays readable and the new one is compared against it.

See also Reassessment required, Version, Version diff

Also called: snapshot

A dated snapshot of the architecture and its supporting findings.

A version records the project at a moment: the architecture, the cost model, the risk register, the requirements and the decision records, along with what caused it - the first synthesis, a requirements change, a manual reassessment, customising a strategy, or a refresh of the modelled price index. Because the cause is recorded, a diff can answer why a number moved, not only that it did.

See also Version diff, Price index refresh

What changed between two versions, line by line, including the direction of the cost.

The diff compares cost, requirements, risks, decision records and individual components between two versions, and states the direction of each change rather than only its size. A cost that rose is shown as a rise, with the line items that moved, which is what makes the version history a record rather than an archive.

See also Version, Reassessment

How long ago a figure was recorded: fresh, ageing, or stale.

Timestamps are described in words rather than as absolute dates, and past a threshold they stop being neutral: fresh under thirty days, ageing from thirty, stale from ninety. A stale figure is labelled rather than hidden, because a rate or an assumption nobody has reviewed in a quarter is exactly the one worth questioning.

See also Rate card, Provenance tag

Stated directly by the user and confirmed.

The strongest state a requirement can hold. It was answered in the interview, and nothing has contradicted it since. A cost model built only from confirmed values is still a model, but it is a model of what you told us rather than of what we filled in.

See also Requirement, Confidence engine

Derived from other answers or the technology catalog rather than stated directly.

Produced by the product rather than stated by you: a value derived from other answers, or a property read from the technology catalogue for a component you chose. Inference is recorded rather than presented as fact, because an inference is only as good as the answers it was drawn from.

See also Assumption, Deterministic result

A working assumption the user has not confirmed. It can change the recommendation.

The most consequential chip in the product, and the one most likely to be skimmed past. An assumption is a value nobody has confirmed, and the product keeps counting them: they appear in the live brief, in the confidence score, and in the evidence chain for any component or figure that rests on one. Applying a heuristic like "help me estimate" records an assumption rather than a confirmed answer.

See also Uncertainty controls, Assumption register, Confidence engine

Not yet answered. Blocks any decision that depends on it.

An unanswered question rather than an empty field: the identity of the question is recorded even when the answer is not, so the gap is visible and any decision that depends on it is held back. Unknown is the state a skipped question leaves behind.

See also Skip this question, I do not know, Ready for analysis

Contradicts another requirement and must be resolved before analysis.

Two recorded answers cannot both be true, for example a stated budget ceiling below the cost of the only architecture that meets a hard availability target. The conflict is surfaced as a conflict rather than resolved by silently preferring one answer, and the conflict resolver records which side you chose and why.

See also Conflict resolution, Ready for analysis

Blocks architecture generation until it is resolved.

A blocking requirement. The interview will not call itself complete while a critical question is unanswered, and the analysis will not run: the gate is the readiness decision, not a warning banner you can dismiss.

See also Ready for analysis, Confidence engine

Materially changes the recommended architecture.

Shapes the recommendation rather than blocking it. A high-impact answer changing is exactly the kind of edit that raises a reassessment, because the architecture was chosen partly because of it.

See also Reassessment, Outdated

Affects cost or operational choices.

Changes the shape of a cost line or an operational choice - a storage class, an instance size - without moving the recommendation between strategies. Worth answering, safe to answer approximately.

See also Cost line item, Scale point

Refines detail without changing the direction.

Refines detail. A change here moves a number in the third significant figure rather than a decision, which is why low-impact questions are ranked last while anything blocking is still open. That ranking is not a licence to skip them: where a question is cheap to answer, answering it costs less than carrying an assumption into the record, and the unanswered low-impact questions are still counted on the brief.

See also Medium

Worth capturing, but with no architectural consequence.

Captured because it may matter later, and recorded as having no architectural consequence today. Treating an optional answer as a constraint is a common way to overbuild, so the tag says what the answer can and cannot influence.

See also Low

Created; the interview has not started.

The project exists and the interview has not begun. Editing the description or deleting the project is all that is possible here, because nothing downstream has anything to be invalidated.

See also Project lifecycle

Gathering requirements.

The interview is running. Requirements accumulate here, and the live brief is available throughout so the summary can be challenged while it is still cheap to change.

See also Interview, Live brief

Waiting for the user to confirm the structured requirements.

The interview has stopped asking and is waiting for you to confirm what was captured. This is the last cheap moment to correct a figure: after it, a wrong input becomes a wrong cost model, a wrong risk register and a wrong plan.

See also Requirements review, Ready for analysis

Critical requirements are confirmed; architecture generation can run.

The readiness decision passed: the critical requirements are confirmed, or the gaps are recorded as assumptions you accepted. Analysis may now be run, and re-run, without changing the requirements.

See also Ready for analysis, Analysis

Generating strategies, risks and economics.

Strategies, economics, risks, resilience, compliance findings, decision records and the implementation plan are being produced. The figures here come from the pricing engine and the analysis engines, not from a language model.

See also Analysis, Deterministic result

Strategies are available to compare.

Candidates exist and are comparable. Nothing has been chosen yet, which is the point of the state: the comparison is made before a recommendation is turned into a record.

See also Options, Fit label

A strategy has been chosen and recorded as a decision.

A strategy has been chosen and recorded. The topology, the cost model and the decision records now describe that strategy, and the alternatives remain readable for the comparison that produced the choice.

See also Selecting a strategy, Topology

Implementation plan and IaC artefacts are available.

The plan and the infrastructure templates exist. The templates are a starting point for your pipeline; the product does not deploy them for you without an explicit action on your part.

See also Implementation task, Terraform bundle, Cloud sync

In use, and subject to reassessment when requirements change.

In use. An active project is not frozen: requirements will change, and the value of the record is that the change is compared against what was decided rather than quietly absorbed.

See also Reassessment, Version

An answer was insufficient and a follow-up question is required.

A secondary state that sits alongside the main one: an answer was insufficient, so a follow-up question is required before the interview can proceed. It usually appears because an answer contradicted something already recorded.

See also Conflicting, Conflict resolution

A decision-critical requirement changed after the analysis ran.

A decision-critical requirement changed after the analysis ran. The existing architecture is still readable, but it describes the previous set of answers, and the badge says so rather than letting a stale conclusion look current.

See also Reassessment, Freshness

The architecture must be regenerated before it can be relied on.

The strongest warning state: the architecture must be regenerated before it can be relied on. It is raised by a pending reassessment, and clearing it means running the analysis again rather than dismissing a banner.

See also Reassessment, Version diff

Retained for reference; no longer maintained.

Kept for reference and no longer maintained. Archiving is how a superseded engagement stops appearing as if it were still current, without deleting the reasoning that produced it.

See also Project lifecycle, Version

Calculated with exact mathematical formulas over this product's own cost model, with zero model hallucination.

Arithmetic performed by code: a rate multiplied by a quantity, summed. Nothing here was chosen by a model, so the figure can be reproduced by hand from the rate card and the input it names.

See also Rate card, Deterministic result

Estimated from this product's own modelled unit rates (e.g. AWS us-east-1). Does not include custom enterprise discount agreements.

A published-rate estimate rather than a quotation. It is a planning number: it does not know your negotiated discount, your commitment spend, or the regional price you will actually be billed at.

See also Rate card, Cost confidence

Generated by reasoning models based on your stated constraints. Review and customize before applying.

Written by a reasoning model from your stated constraints: rationale, trade-offs and narrative. Review it before it becomes a record, because a plausible sentence is not evidence. Figures are not produced this way.

See also Deterministic result, Architecture copilot

Covers cloud technical architecture considerations only. Excludes organizational policies, legal counsel, and auditor sign-offs.

The boundary of the assessment, stated on the artefacts that carry it. This product reasons about cloud technical architecture; it is not your legal counsel, your auditor or your policy owner, and the tag says so wherever a reader might otherwise assume otherwise.

See also Compliance disclaimer, Capability status

Valid infrastructure baseline draft. Review parameters, secrets, and security policies before applying to production.

Generated infrastructure code. It has been checked for structure and obvious mistakes, but it has not been applied to an account, so treat the parameters, secrets and network policies as a review task rather than a finished configuration.

See also Terraform bundle, Policy check

No question in this domain has been answered yet.

Nothing in this interview domain has been answered yet. The domain is shown rather than hidden because the shape of the interview is worth knowing in advance.

See also Domain, Uncovered domain

Some questions in this domain are answered, but it is not finished.

Some questions in this domain are answered and some are not. The rail distinguishes this from complete so that a partly answered area never reads as a finished one.

See also Domain, Question set

Every question in this domain has a recorded requirement.

Every question in this domain has a recorded answer, including answers recorded as assumptions or unknowns. Complete describes coverage of the questions, not certainty about the answers.

See also Assumption

Likely to cause an outage, breach or failed audit.

A finding that could cost you an outage, a breach or a failed audit if nothing changes. Severity describes the consequence and is deliberately separate from likelihood: a low-probability critical risk still deserves a decision.

See also Risk, Mitigation

Significant exposure that requires an explicit decision.

Significant exposure that needs an explicit decision rather than a default. Where the architecture addresses it the register names the component; where it does not, the risk stays open and says so.

See also Mitigation, Open

Worth addressing before load increases.

Worth addressing before load or team size grows. Medium findings are the ones that turn into incidents during a busy quarter, which is why they are listed rather than summarised away.

See also Risk

Monitor; no immediate action required.

Monitor rather than act. Listed for completeness, and listed separately so a reader can tell the register apart from a to-do list.

See also Risk

Not yet addressed.

Nothing in the architecture addresses this yet. An open risk is not a defect in the product: it is a fact about the design that whoever approves the design needs to see.

See also Mitigation, High

Addressed by a provision in the architecture.

A specific component in the architecture addresses the risk, and the register names it. Mitigation is claimed from the components that exist rather than from a generic best practice the design may not include.

See also Mitigation, Component

Knowingly accepted by the team.

A deliberate choice to live with the risk, which is a legitimate engineering position and is recorded as one. An accepted risk keeps its severity and its reasoning, so it can be revisited when the context changes.

See also Reassessment, Critical

Also called: High confidence, Medium confidence, Low confidence

How much of the picture rests on recorded facts rather than on gaps or assumptions.

Each answer carries a value between zero and one, and the bands are drawn at ninety per cent and above for high, seventy and above for medium, below that for low. The score comes from how the answer was recorded: a confirmed answer counts fully, an inference counts partly, an assumption less, and an unknown not at all. A material input left unknown caps the band, so an architecture with a confident tone and an unknown traffic profile cannot present itself as high confidence.

See also Confidence engine, Assumption, Decision specification

Also called: verified, differs, unverified

Whether a figure or citation was checked against a live source, and what that check found.

Three outcomes, named for what actually happened. Verified means a live source was retrieved and states the same thing. Differs means a live source was retrieved and disagrees. Unverified means nothing was retrieved, so the figure is the product of its own model. Unverified is the ordinary case and is labelled rather than dressed up, because presenting a modelled number as a checked one is the failure this status exists to prevent.

• Methodology: how pricing is sourced

See also Evidence chain, Modeled Baseline, Live lookup

Also called: answer, captured requirement

One recorded fact about the system, with where it came from and how far it can be trusted.

Every requirement carries four things: the value, a status saying how it was arrived at, a confidence between zero and one, and an impact tag saying how much a decision depends on it. The source is kept too - an interview answer, an override you typed, an inference drawn from other answers, or an assumption - which is why the product can tell you later that a total rests on four assumptions rather than on four measurements.

See also Confirmed, Assumption, Critical

Also called: requirements interview

The question-and-answer stage that produces the requirements an architecture is built on.

Questions arrive one at a time and are chosen by ranking rather than from a fixed script, so what is asked next depends on what is already known and what is still open. Every answer is written to the project as it arrives, which is what makes the live brief possible and what lets a session be left and resumed. The interview cannot declare itself finished by running out of questions: completion is decided by the readiness decision, against the requirements themselves.

• Methodology: how the interview works

See also Question set, Ready for analysis, Live brief

Also called: question catalog

The questions the interview can ask, grouped into domains: 18 questions covering 12 of the 15 requirement categories.

Each question declares the requirement it writes to, the domain it belongs to, how much impact an answer has, and whether it can block the analysis. The questions are data rather than code paths, which is why the counts above are read from the same catalog the interview draws on instead of being typed into this page. Where a question depends on an earlier answer, it is skipped when that answer makes it irrelevant rather than asked and discarded.

See also Domain, Uncovered domain, Critical

Also called: interview domain, requirement category

A group of related requirements, reported with progress rather than with a completion claim.

The interview asks about 12 domains, and the rail reports each one as not started, in progress or complete, with how many of its questions have answers. Complete describes coverage of the questions, not certainty about the answers: a domain is complete when every question in it has an answer recorded, including answers recorded as assumptions or unknowns. The 3 categories the interview does not ask about yet are listed in the same rail, so the list never implies more coverage than the interview delivered.

See also Uncovered domain, Question set, Complete

A category in the requirement model that no question asks about yet: 3 of 15 today.

Named as Security & Boundaries, Operations & DevOps, Third-Party Services. The rail lists them as a coverage note rather than leaving them out, because answering the interview is not the same as having covered every category the model knows about, and a progress list that implied otherwise would overstate what was established. They are also the categories a reader is most likely to assume were asked about.

See also Domain, Question set, Requirement

Also called: I know, Help me estimate, Decide later

Three ways to record an answer you are not sure of, each leaving a different state behind.

One control rather than three screens: "I know" records what you typed as a confirmed answer, "Help me estimate" offers baseline values with the reason for each and records what you pick as an assumption, and "Decide later" records the question as an unknown and moves on. The distinction survives into the model, so a reader downstream can tell an estimate from a decision that was deliberately deferred.

See also Assumption, Unknown, I do not know

Also called: baseline values, suggested estimate

The path that offers a defensible starting value instead of an empty box.

Where a question has baselines they are shown with the reasoning behind each and one marked as recommended, and nothing is recorded until you choose. What gets recorded is an assumption whose value is the baseline, not a fact, and it counts as an assumption in the confidence score and in the evidence chain of anything built from it. Where a question has no baseline to offer, the product says so rather than inventing one.

See also Uncertainty controls, Assumption register, Assumption

Leaves a question unanswered without recording an answer for it.

Skipping writes nothing to the project and moves the question to the back of the queue. Skips are session state rather than part of the record, so a reload brings the skipped questions round again, and the interface says that instead of letting you believe the question is settled. If every remaining question has been skipped, the interview reports that it is blocked by skips rather than reporting completion.

See also Unknown, Ready for analysis, I do not know

Also called: in-flight summary

The running summary of what has been captured while the interview is still going.

Available from the first answer: it reports what is known so far by domain, how many of the recorded values are assumptions rather than confirmed answers, and which critical questions are still open. Its purpose is to make the cost of continuing visible before the interview ends, because correcting an assumption is cheap while the interview is running and expensive once an architecture has been generated from it.

See also Brief, Assumption register, Domain

Also called: planning assumptions, open questions

Where the values nobody confirmed are collected, counted and carried forward.

Not a screen of its own but a property of the record: assumptions are the requirements whose status is assumption or inferred, and they surface wherever they matter - as a count on the brief, in the confidence score, as the assumptions listed under a decision summary, and as the verify-before-production list attached to a decision. An assumption keeps its identity all the way to the artefact that depends on it rather than dissolving into a number that looks measured.

See also Assumption, Confidence engine, Evidence chain

What happens when two recorded answers cannot both be true.

Contradictions are detected against the recorded requirements rather than left for someone to notice: a stated budget below the modelled cost of the only design that meets a hard availability target, for example, marks the requirement as conflicting and raises a prompt naming both sides. You choose which side stands and the choice is recorded, so the record shows that a decision was taken rather than that an answer quietly changed.

See also Conflicting, Ready for analysis, Requirement

Also called: epistemic evidence chain, lineage

The eight recorded steps that connect a component in the architecture back to what it rests on.

From the top down: the requirement the component answers, the component as the catalogue describes it, the rationale the strategy recorded, the assumption the cost figure rests on, the arithmetic that produced the figure, the vendor service it runs on and whatever the product holds about that service, what the strategy selected and what it recorded rejecting, and the confidence score with the recorded requirements it was computed from. Every step states a fact or states that nothing is recorded, so an empty step reads as a gap rather than as a step that passed.

See also Provenance tag, Confidence engine, Requirement, Rate card

Also called: confidence scoring

The rule that turns how each answer was recorded into a score, rather than into an impression.

Confirmed, inferred, assumed and unknown inputs are counted and weighted, and the assessment names the inputs that are holding the score down rather than only reporting how high it is. It is arithmetic over recorded states, not a model opinion, so the same requirements always produce the same score. Three things follow: the score can be explained line by line, a material input left unknown caps the band instead of shaving a point off it, and the way to raise the score is to record an answer.

See also Confidence band, Assumption, Evidence chain

Also called: source tag

Where a figure or a sentence came from, printed beside it rather than kept internally.

Five tags cover the ways something reaches a project: arithmetic performed by code from a rate and a quantity, a published-rate estimate with no quotation behind it, text written by a model from your constraints, a statement of the boundary of the assessment, and generated code that has been checked for structure but never applied. They exist so a modelled figure and a quoted one do not look alike on the page. Where a tag says the figure is an estimate, treat it as the opening position in a conversation with the vendor rather than as the price you will be billed at.

See also Deterministic Calculation, Modeled Baseline, AI Synthesized, Scaffolding Draft

Also called: verification check

An attempt to check a stored figure against a live source, which can come back empty.

Where a lookup runs it reports one of three outcomes: the live source agrees with what is stored, the live source disagrees, or nothing was retrieved. The third is the ordinary case, and it is reported as unverified rather than quietly left as verified, which is what stops a modelled rate from reading as a checked one. A disagreement is surfaced as a disagreement and does not overwrite the stored figure, so the judgement stays with you.

• Methodology: how pricing is sourced

See also Verification status, Rate card, Freshness

Also called: computed, not model-written

A figure or a finding produced by arithmetic rather than by a language model.

Cost totals, feasibility checks, confidence scores and requirement conflicts are computed by code from recorded inputs, so they can be reproduced and argued with: the same inputs give the same answer, and the evidence chain shows the inputs it used. Language models are used for prose - rationale, trade-offs, recommendations in words - and those passages are tagged as model-written so a plausible sentence is never mistaken for a calculation. If a number and a sentence disagree, the number is the one that was computed.

See also Deterministic Calculation, AI Synthesized, Evidence chain

Whether something described here is live in the product today, partial, or still an intention.

This glossary describes what the product does now, including the places where it does less than the interface might suggest: estimates that are not quotations, generated code that has not been applied, checks that return nothing. Where a capability is partial, the entry states the limit rather than describing the intention. The Methodology page carries the same statement in more detail, and where the two disagree the code is the authority.

• Methodology: what is live today

See also Verification status, Scaffolding Draft, Compliance disclaimer

Also called: candidate architecture, option

One candidate architecture, with its nodes, its costs and the reasons it was shaped that way.

A strategy carries the components and the connections between them, a monthly estimate at four scales, and the reasoning: the rationale, what it compromises on, the assumption it rests on, and why the alternatives were not chosen. The comparison figures are recorded per strategy rather than recomputed per screen - operational effort, team fit, lock-in, scalability, resilience and implementation time - so two options are compared on the same six things. One strategy arrives marked as the recommendation, and the others remain readable in full rather than being reduced to a line in a list.

See also Component, Recommended strategy, Fit label, Cost scenario

Also called: node, building block

One element of the architecture, tied to a catalogue entry rather than to a name alone.

Each component records what it is, which provider and service it runs on, the network zone it sits in, the region, and its share of the monthly estimate. It also records why it was selected and which alternatives were considered and rejected, and where a catalogue entry exists the component points at it, so decision records and implementation tasks can quote that entry instead of inventing a trade-off. A component can be locked, which keeps an edit you made from being overwritten by the next regeneration.

See also Topology, Strategy, Evidence chain

Also called: architecture canvas, diagram

The components and the typed connections between them, drawn from the recorded data.

Edges are typed - reads and writes, invokes, streams, caches, authenticates, monitors - and each carries its protocol where one is recorded, so the diagram says what a connection means rather than only that two boxes are joined. The picture is rendered from the same component and connection records the cost model and the generated code use, which is why adding a component changes the estimate: there is one architecture, shown three ways.

See also Component, Strategy, Terraform bundle

Also called: Best fit, Over budget, Closest fit

How a candidate architecture fits what you told us about budget, team and constraints.

Six labels, each with a sentence saying what drove it: best fit, strong fit, good fit, alternative fit, sub-optimal, over budget, and the awkward but honest closest fit when nothing matches the budget. The label is separate from the budget check, which is one of feasible, over budget or closest fit, so a strategy can be a poor fit for reasons other than money. The label is a summary of the recorded constraints rather than a verdict: the sentence underneath names the constraints it weighed.

See also Strategy, Budget feasibility, Recommended strategy

Also called: the recommendation

The one candidate marked as recommended, with the reasoning available and the others left intact.

One strategy arrives flagged, and the flag is a comparison rather than a shortcut: the recommendation is recorded alongside why the other candidates were not chosen, and both the rationale and the compromises are readable. It is a starting point for your decision, not a verified deployment state. If you would rather not take it, the product supports choosing another strategy and records that choice, including the reason, in the decision record.

See also Strategy, Fit label, Decision record

Also called: copilot, suggested change

Suggests concrete changes to the architecture, with the cost and trade-offs stated before it applies anything.

You describe the change in words, or start from one of the prepared prompts, and the copilot returns a plan: the edits it would make to components, the monthly cost change, the projected effect on resilience and latency, what it affects in compliance, the trade-offs, a suggested decision-record title, and a confidence score. The plans come from matching your request against the change families the product knows how to make, and the projections are properties of that change family rather than measurements of your system, so they are the reason to evaluate a change and not evidence that it works. Nothing is applied until you accept the plan, and applying it edits the architecture, records the change and raises a reassessment - it does not touch your cloud account.

See also Strategy, AI Synthesized, Reassessment

One priced component, with its units, its arithmetic and the confidence in that arithmetic.

Each line names the component and the provider service, the units it is priced in, the monthly figure and the formula that produced it, so the number can be checked by hand rather than taken on trust. It also carries its own confidence: a line built from a confirmed quantity at a modelled rate is not the same claim as one built from an assumed quantity. Totals are sums of these lines, which is why removing a component visibly removes its cost rather than nudging a total.

See also Rate card, Cost confidence, Cost scenario

Also called: modelled rates, unit prices

The prices the cost model uses, held in the product rather than fetched from the provider.

Rates are maintained as part of the product and are not retrieved from the providers at run time, so no figure carries a publication date of its own and none of them is a quotation. They are published-rate estimates to plan against: they do not know your negotiated discount, your commitment spend, your region or your tax treatment. A live lookup can ask what a provider publishes for a service and will report that as the provider statement rather than silently correcting the model. Where the price is the thing being decided, confirm it with the provider.

• Methodology: how pricing is sourced

See also Cost line item, Live lookup, Freshness, Modeled Baseline

Also called: 2x, 5x, 10x

The same architecture priced at higher loads, so the shape of the cost curve is visible.

Each strategy is costed at its current load and at two, five and ten times that load, which is what turns a single figure into a curve: designs that are cheap now but grow faster than the load are visible as such. The scaled figures are the model re-run on larger quantities, not a forecast of when you will reach that traffic, and they assume the architecture itself does not change shape on the way up. Read them as the direction and the steepness of the cost, not as a schedule.

See also Cost line item, Strategy, Cost scenario

Also called: economics, cost model

A priced architecture: the line items, the scaled figures, the drivers and the comparison views.

A scenario records the monthly and annual totals, the line items behind them, which category drives the bill and by how much, and the comparison views: current load against the scaled loads, production alone against production with staging, and infrastructure alone against infrastructure plus operational labour. Because all of those are recorded on one object, the answer to what does this cost at five times the load and what part of it is people is a stored figure rather than a new estimate.

See also Cost line item, Scale point, Cost confidence, Budget feasibility

Also called: cost band

How much of a cost total rests on confirmed inputs, stated with the reason.

A scenario carries a confidence band and a sentence naming what produced it, drawn from the same distinction the rest of the product makes between confirmed, inferred and assumed inputs. The band is there to stop a precise number from reading as a precise piece of knowledge: a total assembled from assumed volumes can be arithmetically exact and still be the least reliable figure on the page. Where the confidence is low, the reason names the inputs to change rather than leaving you to guess.

See also Confidence band, Cost scenario, Confidence engine

Also called: feasible, over budget

Whether a candidate fits the budget you stated, including the case where none of them does.

Two readings are recorded: one for the stated budget, and one measuring the difference between that budget and the modelled monthly figure, as an amount and a percentage, marked as under, on or over. Three outcomes are possible for a candidate - within budget, over budget, or over budget while being the closest option available - and the third is reported as it is rather than hidden, because a design that fails the budget is still the most useful answer when the alternative is a cheaper design that fails a hard requirement.

See also Fit label, Cost scenario, Strategy

Also called: API versus rent versus own

For a model workload, where paying per token stops being cheaper than renting or owning accelerators.

The comparison prices the same workload three ways - per-token API calls, rented GPUs by the hour, and owned hardware amortised monthly - and states the monthly token volume at which the alternatives overtake the API, along with the utilisation that would be needed to justify owning. It rests on the token volume you stated and the rates in the rate card, so it is a shape rather than a prediction: it does not know your negotiated token discount, your actual utilisation curve, or the value of the engineering time that running your own inference implies.

See also Rate card, Cost line item, Scale point

Also called: what each plan includes

One row of the plan comparison: what the capability is, and what each plan allows.

The comparison is a table of capability rows against the four plans - Free, Architect, Team and Business - where each cell is either an allowance in words or a plain statement that the plan does not include it. Some rows carry a note explaining themselves, such as the free plan comparing a single architecture option rather than a set, and the notes are shown rather than hidden behind a tooltip. The page is rendered from that one table, so the allowances cannot disagree with themselves between the pricing page and the plan you are on.

• Pricing: plans and allowances

See also Capability status, Export package

A recorded cause for a new version: the modelled rates changed and the figures were recomputed.

One of the five causes a version can carry, alongside the initial synthesis, a requirements change, a manual reassessment and customising a strategy. Because the cause is recorded, a total that moved because the rate card moved is distinguishable from one that moved because your requirements changed - which is the difference between a number to re-read and a decision to re-open. Treat a version that carries this cause as a reason to check the figures, not as a reason to revisit the architecture.

See also Version, Rate card, Version diff

Also called: risk register entry, finding

One named exposure, with how bad it is, how likely it is, and what it would cost to address.

A risk records its category - reliability, scalability, security, compliance, cost, vendor concentration, operational complexity or team fit - separately from its severity and its likelihood, because consequence and probability are different questions and collapsing them hides the low-probability disaster. It names the components it concerns, describes the impact in words, and states a recommended mitigation with what that mitigation would cost, so a risk with a remedy and a risk without one are distinguishable on the page.

See also Mitigation, Critical, Open, Decision specification

What the architecture already does about a risk, or what it would take to address it.

Two things share the name and the page keeps them apart. A mitigation that has been applied is a specific component in the architecture, and the register names it rather than claiming a best practice. A recommended mitigation is a proposal with an attached cost impact, which is what makes accepting a risk a real decision rather than a default: you can see what the remedy would cost before declining it. An accepted risk keeps its severity and its reasoning so it can be revisited when the context changes.

See also Risk, Mitigated, Accepted, Reassessment

Also called: decision spec, judgement contract

The written contract for a judgement the system makes about your project.

Each judgement the product makes about your work is pinned to a specification carrying a versioned identifier, the purpose of the judgement, how much is at stake, the minimum confidence required before the output is acted on, and the closed set of answers it is allowed to return. Deciding whether the interview holds enough context to generate architecture, for example, is a high-stakes judgement with a 0.90 threshold and three permitted answers: ready, needs critical inputs, or can proceed with assumptions. Two consequences you can rely on: the permitted answers are enumerable rather than free text, and changing how the judgement is made means changing a versioned artefact rather than silently drifting. The thresholds are the bar for acting, not a measurement of how often the judgement is right.

See also Confidence band, Confidence engine, Ready for analysis, Assumption register

The scope limit that ships with every compliance reading in the product.

"This assessment covers technical architecture considerations only and does not constitute legal advice, certification, or confirmation of regulatory compliance." Read it as the boundary of what a design review can honestly tell you: it can say that encryption in transit is provisioned and that audit logging exists at a named layer, and it cannot say that you are compliant, because compliance also depends on policies, contracts, training and evidence that no architecture contains. It is stated on the pages that carry compliance readings rather than buried in a terms page.

See also Compliance matrix, Threat model, Modeled Baseline

Also called: control coverage, framework controls

Framework controls against the architecture, with a third verdict for what a diagram cannot satisfy.

Controls are taken from named frameworks - HIPAA, SOC 2, GDPR and PCI-DSS - and grouped by kind: encryption, access control, audit and logging, resilience and backup, data isolation, and operational process. Each control gets one of three verdicts: satisfied by the architecture, with the provision that satisfies it named; or needing attention, with the action required written out; or out of scope for the architecture because the obligation is organisational. The third verdict is what keeps the matrix honest, since a control that lives in a policy or a training programme is not made true by any component on the diagram, and the matrix says so instead of borrowing credit for it.

• Security: what is protected, and what is not

See also Compliance disclaimer, Confirmed, Risk, Live lookup

Also called: STRIDE, attack tree

Threats derived from the components in your design, with the path an attacker would take.

Threats are organised under the STRIDE categories and generated against the components actually present in the chosen strategy, so a design with no public entry point does not collect a list of injection findings it cannot have. Alongside each category there is an attack path: the sequence of steps from an initial foothold to a target asset, which is what turns a category name into something a reviewer can argue with. Marking a threat as addressed is your record of what the architecture does about it, and the mark is kept with the project rather than inferred.

See also Risk, Mitigation, Compliance matrix, Strategy

Also called: disaster recovery drill, RTO/RPO

Walking a named failure through the design to see how the recovery story actually goes.

The simulation takes a scenario - a primary region blackout, replication split-brain, inter-region transit congestion, or ransomware and logical data corruption - and steps it through the topology you chose, against a chosen recovery topology, reporting the recovery time and recovery point objectives the design would meet and where the sequence stalls. It is a model of the runbook rather than a drill: it does not fail your regions or read your replication lag, so use it to find the step that has no answer while it is still a diagram, and then test the real thing.

See also Risk, Resilience rating, Strategy

Also called: enterprise grade, moderate, critical risk

The verdict a failover simulation reaches, drawn from the recovery topology that was nominated.

Three ratings, and each is a property of the recovery topology nominated for the simulation rather than a score for the architecture as a whole. Backup and restore is rated critical risk: hours of recovery and up to a day of data loss are recorded as critical rather than smoothed into an average. Pilot light is rated moderate, because the core database is replicated and recovery is measured in tens of minutes. Warm standby and multi-region active-active are rated enterprise grade. The rating is therefore readable as an opinion about the recovery plan before the run, and the simulated recovery time and data loss printed beside it are the figures worth arguing with. Nominate a different recovery topology and the rating is expected to move, which is why an earlier run is kept rather than overwritten.

See also Failover simulation, Risk, Reassessment

Also called: ADR, architecture decision record

The decision, the options that were not taken, and what would make you look again.

A record carries a numbered title, its status - accepted, proposed, superseded or rejected - the context, the decision itself, the reasoning, and the consequences split into what this makes easier and what it makes harder. Recording the consequences you did not want is the part that makes the document worth keeping: a record with only positives is an advertisement. Records are numbered and dated, they name the components they affect, and a superseding record points back at the one it replaces rather than editing it.

See also Rejected alternative, Revisit trigger, Decision specification, Drift monitor

Also called: options considered

The option that lost, with what it was good at and the reason it was set aside.

Every record lists the alternatives beside the chosen one, each with its advantages, its disadvantages and the reason it was not taken. This is the part that ages best: when the constraint that decided it changes, the reason on file is what tells you whether the decision still holds or has quietly become a leftover. It is also the only defence against a decision document that reads as if the chosen path were the only one available.

See also Decision record, Revisit trigger, Reassessment

Also called: reopen condition

A condition attached to a decision that, when it comes true, means the decision should be looked at again.

Each record can carry conditions that would invalidate its reasoning - a volume crossing a threshold, a framework entering scope, a vendor changing terms - written at the time the decision was made rather than remembered later. They are not monitored for you; they are a checklist to read on the next reassessment, which is why they are written as observable events rather than as sentiments.

See also Decision record, Reassessment, Version

Also called: build sequence, phase

One piece of the build plan, placed in a phase and wired to what has to happen first.

Each task sits in a numbered phase with a name, carries an effort estimate, lists the tasks it depends on, and names the decision record and the components it relates to - which is what makes the plan an order of work rather than a list of work. Task state is kept as both a completion flag and a status of pending, in progress, blocked or completed, so read the status where it has been set: a task marked blocked with an unmet dependency is telling you something a tick would hide. Where a task has an owner, the plan is also saying who you are waiting for.

See also Decision record, Component, Reassessment

Also called: generated infrastructure, IaC

Infrastructure as code generated from the chosen strategy, one file per concern.

The bundle is generated from the selected architecture strategy rather than hand-maintained, and it changes when the strategy changes, so the code and the diagram are not two documents drifting apart. It is a starting point to review rather than a deployment you should trust: the modules reflect the components, sizes and options as modelled, and they know nothing about your account layout, your naming standards, your state backend or the resources you already have. Read it, adjust it, and treat the difference between it and your estate as the work.

• Methodology: what the generated code covers

See also Policy check, Strategy, Component, Plan feature row

Also called: IaC validation, CKV

A rule applied to the generated code, and the fix it can apply when the rule fails.

Each finding names the rule, the resource it fired on, the framework the rule comes from and the reason it exists, so a failed check is an argument rather than a score. For a set of these rules the product can apply the correction to the file and show you the diff, which is deliberately narrow: an automated fix you cannot read is indistinguishable from an automated mistake. The register lists IaC static validation as partial rather than complete - separate from the architectural constraint checks it lists as live - and it does not run a plan or replace testing against a real environment, so treat the absence of a finding as unproven rather than as a clean bill of health.

See also Terraform bundle, Capability status, Verification status, Compliance matrix

Also called: architectural drift, drift report

What the running estate does that the recorded decisions say it should not.

Drift is variation between the architecture you recorded and what a deployment actually looks like: a bucket left public, a database without multi-region failover, a key without rotation. The monitor reads CloudTrail-style events - it can produce a sample event stream to show the mechanism, or parse logs you paste - groups the findings by category and severity, and attaches each one to the decision record it contradicts. A finding is not closed by ignoring it: it is either remediated or explicitly accepted as an exception, and the exception is kept on the record with its reason.

See also Decision record, Policy check, Reassessment, Terraform bundle

Also called: what leaves the workspace

The artefacts a project can produce, and the permission that governs taking them.

Exports are the parts of a project that survive outside it: the decision records as Markdown, the risk and compliance readings, the cost model and the generated infrastructure. Taking an export is itself a named permission rather than a side effect of being able to read the page, so a role can be given sight of a project without being given a copy of it - note that even the narrowest read-only role holds the export permission, which is what the sharing settings are for. An export is a snapshot of the project at the moment it was produced, not a live view, and it carries the same provenance marks as the page it came from.

See also Decision record, Collaborator role, Sharing link, Freshness

Also called: dry run, speculative sync, one-click deploy

Addressing the generated infrastructure at a cloud target in a speculative dry run, and what the dispatch does not do.

Cloud sync composes a deployment payload from the same artefacts the export produces - the Terraform files and the architecture manifest - and addresses it at a target: GitHub Actions, GitLab CI, Terraform Cloud, Spacelift, a Supabase project, an AWS, GCP or Azure account, or a webhook of your own. Each dispatch returns a record with a log, and on a direct provider path a receipt naming the resources in the run. Dry run is the default, and the capability register lists the feature as partial for that reason: the speculative dry-run and the change and budget impact are produced against the target profile the dispatch is given, no deployment is pushed and no live cloud resource is mutated. The receipt is composed by the product rather than returned by the provider, and the credential fields in the panel are configuration for the payload - the demo values are placeholders to be replaced with values from an account you control - so read the receipt as the dispatch that would be sent, then send it from a pipeline you own.

See also Terraform bundle, Capability status, Export package, Implementation task

Also called: permission matrix, owner, architect, editor, reviewer, viewer

What each person on a project is allowed to do, held as one fixed set of permissions per role.

Five roles cover the work: owner, architect, editor, reviewer and viewer. Each maps to a defined set drawn from eleven named permissions - edit the topology, modify services, manage decision records, run load simulations, generate infrastructure, manage members, manage sharing, create comments, resolve comments, export the package, and see financials - and the interface reads that set rather than hard-coding an exception per screen. The gaps are the useful part: an editor cannot manage decision records, only the owner may change who has access, and even the read-only role keeps the ability to see costs and take an export. A person is active, invited or suspended, and suspending access is how a grant is withdrawn.

See also Invite link, Sharing link, Export package, Plan feature row

A link that carries an existing grant of access to a named person at a named role.

Inviting someone records their name, their address and the role they will hold, and produces a join link containing a token that identifies the project, the role and the moment the invitation was made. Until it is accepted the person sits in the list as invited rather than active, which is what makes an unanswered invitation visible instead of looking like an inactive colleague. The link is a bearer credential: whoever follows it receives the grant, so send it to the address it names, and treat withdrawal - removing the person or changing their role - as the way to take it back rather than trusting the link to stop working on its own.

See also Collaborator role, Sharing link, Presence

Also called: access level, public link, public report

How far a project is allowed to travel: who may open it, and under what conditions.

A project sits at one of four access levels: private, internal to the organisation, restricted to named email domains, or open by link. The conditions are set alongside the level rather than assumed from it - which domains are allowed, whether anonymous people may view, whether they may comment, whether a password is required, and when the link stops working. A read-only report can be opened in its own tab, which is the form to use when someone outside the workspace needs the outcome but not the apparatus. The distinction that matters is between access for named people and access for anyone holding the link; the level is a deliberate choice, so set it rather than inherit it.

• Security: encryption, isolation and secret handling

See also Collaborator role, Invite link, Export package, Retention policy

Also called: canvas comment, review thread

A note attached to a place on the diagram, with a thread and a resolution state.

A pin is anchored to a proportional position on the canvas and optionally to a strategy, a node or a zone, so it stays with the thing it is about when the view is resized or re-laid out. Threads are replies under the pin, and a pin is open until someone resolves it, which takes the corresponding permission rather than the ability to type. Where a pin belongs to a decision, it can be attached to that decision record, so the argument that produced a choice stays readable next to the choice. Resolving is recorded as an action, which is what makes a review auditable rather than a matter of recollection.

See also Collaborator role, Audit trail, Decision record, Component

Also called: who is here, live cursors

Who is in the project right now, what they are looking at, and who is a demonstration peer.

Presence carries the person, their role and colour, where their cursor is on the canvas, which node or zone they are working on and a line about what they are doing. It is synchronised over a browser channel for the session rather than stored as history, so a peer indicated as simulated is demonstration data supplied to show the mechanism, not a colleague who has actually joined - the flag is on the record, not only in the interface. Nothing in a project depends on presence being accurate; it is orientation, and the durable records are the comments, decisions and audit entries.

See also Collaborator role, Comment pin, Sharing link

Also called: MFA, TOTP, recovery codes

A second factor at sign-in, held in an authenticator app, with codes to keep for the day it is lost.

Enrolment gives you a shared secret to enter into an authenticator app, is confirmed by entering a generated code, and then issues single-use recovery codes to store offline - the recovery codes are a bypass of the second factor, so keep them with the care you would give a password. The codes are standard time-based one-time codes, and the register lists hardware security keys as planned rather than shipped, so a policy that requires a physical key is not satisfied by what exists here. Losing both the app and the recovery codes locks the account out, which is the intended property of a second factor rather than a flaw in it.

See also Audit trail, Collaborator role, Capability status

Also called: audit log, chain verification

A chained record of who changed what, with a check that the sequence has not been edited.

Each entry records the actor, their role, the action, the project and target it concerned, a description and a timestamp, and the actions come from a closed list - inviting a member, changing a role, removing a member, mutating a node, accepting a decision, resolving a comment, updating sharing, triggering a simulation - so the log can be read as a taxonomy rather than as prose. Every entry carries the hash of the entry before it, forming a chain from a genesis value, and the chain is verified when the log is viewed, so an edited or removed entry breaks the sequence at a findable point. Two limits worth knowing: it records activity inside the product, so changes made directly in your cloud account arrive only through the drift monitor's ingest; and entries are anonymised after a configured period, which means an old action can lose its attribution by design. Before relying on the log, check that the entries name your project and your people - a log of sample activity is telling you nothing has been recorded yet.

See also Retention policy, Two-factor authentication, Drift monitor, Collaborator role

Also called: GDPR, right to erasure, data export

How long a workspace keeps data, and how a person takes a copy or asks for it to go.

The policy states how long project data is retained - 90, 180 or 365 days, or indefinitely - how long a deleted project waits before it is purged, when audit entries are anonymised, and which frameworks the policy is written against. Each change records who made it and when, which is what makes retention a governance artefact rather than a setting. A person can export their data as a machine-readable package for portability, and erasure can be exercised: the result is a receipt naming what was purged, how many projects and artefacts went, and how many audit entries were anonymised, marked either completed or scheduled. Deletion is not always immediate, so read the receipt rather than assuming the data is already gone.

• Privacy: data retention and deletion

See also Audit trail, Export package, Sharing link, Two-factor authentication