TL;DR

Architectural feasibility assumptions are provisional inputs used when a project decision must be explored before every fact is confirmed. A reliable assumptions register records the source, owner, confidence, effect, sensitivity, validation route, expiry condition, and approval status of each assumption, while keeping it separate from verified facts and design choices.

What are architectural feasibility assumptions?

Architectural feasibility assumptions are explicit, provisional statements that let a team test whether a site or brief could support a viable design. They fill a temporary evidence gap. Examples include an unconfirmed setback interpretation, an estimated net-to-gross factor, a working unit mix, a parking ratio, a likely floor-to-floor height, or a preliminary structural grid.

An assumption is not the same as a fact, target, decision, or risk.

• A fact is supported by the source and verification level required for the decision.

• A target states what the project aims to achieve.

• An assumption states what the team will provisionally treat as true.

• A decision records a chosen course of action.

• A risk describes an uncertain event or condition and its potential effect.

Those records may be related, but combining them hides responsibility. A target of 100 homes does not prove that 100 homes fit. An assumed parking ratio does not become a confirmed regulation because it appears in a polished model. A chosen massing option does not validate the site inputs that produced it.

The UK government's AQuA Book defines an assumptions log as a register of assumptions that have been risk assessed and signed off. It says the log should describe each assumption, quantify its effect and reliability, state when and why it was made, and identify who made and approved it. Although the guidance is written for analytical models, the discipline maps directly to feasibility work. (The AQuA Book)

Why do feasibility assumptions need their own register?

Feasibility assumptions need a register because the model will otherwise make them look settled. A boundary offset becomes a crisp line. An efficiency factor becomes an exact area. A notional parking bay becomes a count. Visual precision can outrun evidence quality very quickly.

The register restores the missing context. It lets a reviewer answer five questions without reconstructing the project history:

1. What is being assumed?

2. Why is the assumption necessary now?

3. Which outputs depend on it?

4. What would change if it is wrong?

5. Who must validate or replace it, and when?

This separation also makes change easier to manage. If the setback interpretation changes, the team can find every option that depended on it. If the unit-mix target changes, the geometry can be retested without rewriting the record of what was previously approved.

See how an efficiency factor can remain an explicit feasibility input rather than a hidden correction.

Explore Snaptrude with one live feasibility model and a short assumptions register beside it, then test which conclusions survive a change in inputs.

How should architectural feasibility assumptions be structured?

Architectural feasibility assumptions should be structured so a reviewer can identify the claim, evidence gap, model effect, and resolution path. A sentence alone is not enough. Each record needs fields that support review and later replacement.

Use the following minimum structure:

Give each assumption one clear statement. If the record contains two claims joined by “and,” split it. A parcel boundary assumption and a setback assumption may affect the same geometry, but they have different sources, owners, and validation routes.

Confidence should be tied to use, not expressed as a vague feeling. “Medium for concept screening” is more useful than “medium.” If a low-confidence assumption has high impact, escalate it early. A high-confidence assumption with limited impact may simply stay on the watch list until the next stage.

How do you build an architectural feasibility assumptions register?

Build the register before the first option is treated as a result, then update it at every material decision. The objective is not exhaustive administration. It is to preserve the small number of uncertain inputs that could change the answer.

1. Start from the decision

State what the study must decide and the date of that decision. A land-screening exercise, design competition, capital approval, and planning submission need different levels of assurance. Define which assumptions are acceptable at the current stage and which must be resolved before the next one.

2. Extract assumptions from every input layer

Review site geometry, planning controls, program, unit mix, area definitions, parking, circulation, structure, core planning, cost, phasing, and delivery. Ask where the team has substituted a working value for missing or unresolved evidence.

3. Link every assumption to the model

Record the parameter, object, formula, or scenario that expresses it. “Parking under review” is too broad. “Scenario B uses one space per unit until the local schedule is confirmed” can be found, tested, and replaced.

4. Test sensitivity before polishing the option

Change the assumption within a credible range and observe the outputs. Some assumptions barely move the result. Others cause a step change in yield, access, area, or cost. The latter belong at the top of the review agenda.

5. Assign an owner and expiry condition

Every unresolved item needs one accountable owner and a concrete trigger. Dates help, but events are often stronger: before bid submission, before consultant appointment, after survey receipt, or before the option is presented as preferred.

6. Record approval and retirement

When the team accepts provisional use, record who accepted it and for what purpose. When evidence arrives, do not delete the old record. Mark it validated, superseded, or invalidated, link the new source, and identify affected options.

The UK Infrastructure and Projects Authority's cost-estimating guidance says assumptions should be clearly communicated across stakeholders and continuously reviewed as the project develops. It also places the assumptions register alongside scope, schedule, risk, and project-leadership sign-off. The architectural lesson is straightforward: a feasibility number is more useful when its basis and ownership travel with it. (UK government cost-estimating guidance)

Which assumptions should be tested first?

Test assumptions according to decision impact and cost of late discovery. A simple probability score is not enough. Some items are uncertain but easy to absorb. Others are reasonably likely to be correct yet catastrophic if wrong.

Prioritize an assumption when it affects:

• Legal or physical site extent

• Access, fire service movement, or accessible routes

• Buildable envelope and height

• Total developable or qualifying area

• Unit count, unit mix, or program fit

• Parking geometry rather than parking area alone

• Core, egress, or vertical circulation

• A pass/fail planning or client requirement

• A large cost or schedule commitment

Use alternate scenarios for discrete interpretations. Use a range for continuous variables such as efficiency. Use a hard stop when professional confirmation is required before the decision can responsibly proceed.

Read how the site-to-program-to-envelope-to-massing sequence can keep assumptions connected.

How should feasibility assumptions appear in a decision pack?

Show the few assumptions that could change the decision, not a data dump. Each option summary should identify its controlling assumptions, confidence, alternate case, and next validation action. Put the complete register in an appendix or linked working record.

Avoid a single disclaimer that says all numbers are preliminary. That language is accurate but not useful. A decision-maker needs to know whether the largest uncertainty affects site area, permitted geometry, program demand, parking fit, or cost. Show the output range caused by each critical assumption and the point at which the project must revisit the decision.

The AQuA Book also calls for documentation of scope, methods, inputs, verification, validation, limitations, and the conditions under which an analysis remains valid. A feasibility model should meet the same standard of explainability even when it is visually simple.

How does Snaptrude support assumption-led feasibility?

Snaptrude provides connected Program, Design, BIM, and Present modes in a browser-based environment. Program Mode supports AI-assisted space planning, area calculations, adjacency planning, and a direct connection from program data to 3D design. Design Mode supports site modeling, massing, and parametric concept work. BIM Mode supports building elements, quantities, drawings, schedules, and IFC export.

These capabilities make it possible to keep program, geometry, and measurable outputs close to one another as options change. The project team still has to define, own, and validate its assumptions. The useful workflow is not automatic certainty. It is a model where a provisional input can be located, changed, compared, and retired without losing its decision history.

Learn how design options can be iterated without multiplying files.

References

The AQuA Book: UK government guidance on quality analysis. It specifies the content of assumptions, decisions, and data logs and connects them to verification, validation, reliability, ownership, and sign-off.

Cost Estimating Guidance: UK Infrastructure and Projects Authority guidance. It explains why assumptions must be documented, communicated, reviewed, related to risk, and included in project-leadership sign-off.

Housing and economic land availability assessment: UK planning guidance. It distinguishes assessment from allocation and provides a public example of testing site suitability, availability, achievability, constraints, and development potential.

FAQ: Architectural Feasibility Assumptions

Q: What are architectural feasibility assumptions?

A: They are provisional inputs used to test a design or development question before all evidence is confirmed. Common examples include working setbacks, efficiency factors, unit mixes, parking ratios, floor heights, and structural grids. Each assumption should have a stated basis, owner, confidence, model location, impact, validation route, and trigger for review or expiry.

Q: What is the difference between an assumption and a risk?

A: An assumption is something the team provisionally treats as true so work can continue. A risk is an uncertain event or condition that could affect objectives. They can be linked: if an assumed easement position proves wrong, the resulting loss of buildable area is a risk. Keep separate records so the team can validate the claim and manage its consequence.

Q: How many assumptions should a feasibility register contain?

A: Include every unresolved input that could materially change the decision, plus any assumption required to explain the model. The right number depends on project complexity and stage. Avoid recording trivial statements that create noise, but do not hide high-impact uncertainty inside generic notes. A short, actively reviewed register is usually more useful than a long, unattended one.

Q: How should assumption confidence be scored?

A: Tie confidence to the intended decision and evidence quality. Use clear categories with definitions, such as high for current-stage reliance, medium for scenario testing, and low for screening only. Pair confidence with impact. A low-confidence, low-impact item may wait, while a medium-confidence assumption that controls capacity or access should be escalated immediately.

Q: When does a feasibility assumption become a fact?

A: It becomes a verified input only when the required authority, evidence, and reviewer have confirmed it for the stated purpose. Receiving a new document is not enough if applicability or interpretation remains unresolved. Preserve the assumption's history, link the validating source, record who accepted it, and identify which models or options were updated as a result.

Q: Can Snaptrude manage architectural feasibility assumptions automatically?

A: Snaptrude can connect site, program, design, quantities, and presentation work so assumption effects are easier to test and communicate. It does not decide which inputs are authoritative or approve a project team's assumptions. Users should maintain explicit ownership, evidence, confidence, and validation rules, then use connected model outputs to compare the consequences of credible scenarios.

Explore Snaptrude with one decision-critical assumption, model its credible alternate, and make the difference visible before choosing an option.