An early feasibility model is often asked for one answer: “What can we build here?”
That question sounds simple. It is not. At the start of a site decision, some facts are verified, some are working assumptions, and some are still unknown. A model becomes dangerous when it presents all three as if they have the same level of certainty.
The useful output is not only a number. It is a clear view of what the number depends on.
Three states are better than one confident answer
A practical feasibility model should label each important input in one of three ways:
- Verified: supported by a source that the team has checked.
- Provisional: a working assumption used so the option can be explored.
- Unresolved: information that could change the answer and still needs to be checked.
This simple separation changes the conversation. The team can compare two development options without pretending that either option is ready for approval.
It also makes the next action visible. If the result changes mainly when the road width is confirmed, the road-width check is more important than polishing the rendering.
Unknown is not the same as zero
Missing information is often handled badly in early models. A blank field becomes zero. A missing rule becomes a default. A range becomes one selected value without recording why.
That makes the spreadsheet look complete, but it hides the uncertainty inside the result.
The safer choice is to keep the field unresolved and carry that state into the output. A user should be able to see that the buildable area, unit count or cost range depends on an input that has not yet been verified.
An unresolved value is not a failure of the model. It is an honest instruction about what must happen next.
Keep the chain inspectable
Early feasibility is a chain, not a single calculation:
site boundary → applicable rules → development geometry → unit mix → cost and time → decision
Each link can introduce a different kind of uncertainty. A boundary may be incomplete. A planning rule may need interpretation. A layout may work geometrically but fail a required access condition. A cost may be a placeholder rather than a quote.
The model should preserve that chain. When an output changes, the team should be able to trace the change back to the input or assumption that caused it.
This is also where an AI system needs discipline. Speed is useful only if the system shows the evidence and assumptions behind the result. A fast answer that cannot be inspected is difficult to trust.
The output should help choose the next check
The first model is not the final approval package. Its job is to help the team decide whether a site deserves the next level of work, and which question should be answered first.
A good output therefore includes:
- the options that were compared;
- the verified inputs used;
- the assumptions that still need confirmation;
- the unresolved questions that could change the choice; and
- the next check with the highest decision value.
That last item matters. A long list of caveats is not the same as a useful decision process. The team needs to know which missing fact is worth resolving before it spends more time on design, due diligence or negotiation.
A small test for a useful model
Before relying on an early feasibility result, ask three questions:
- Can we state what is known?
- Can we see which assumptions are provisional?
- Can we name the unresolved fact most likely to change the decision?
If the answer to all three is yes, the model is doing useful work even when the result is not final. It is making the decision easier to inspect and easier to improve.
That is the standard we are applying to Keystone: compare development options early, keep the evidence visible, and never turn an unknown into a confident-looking number just to make the page look finished.
Related reading: From land boundary to development scenario, How developers evaluate a new land opportunity, and How early site-planning AI should be evaluated.
---
*Founder-method note: this is a description of Keystone's working method, not a client case study. It makes no claim about project savings, speed, accuracy or investment outcomes. Any real project still needs current local-source checks and the appropriate professional review.*