Once we decided to place the system before development, the next problem was straightforward:
what should a pre-development decision be based on?
At this stage, most information is incomplete.
Costs shift. Staff performance varies. Demand is unknown.
Optimisation is not possible.
So the method could not be built around precision.
Feasibility comes before optimisation
Before a drink exists, there is nothing to optimise.
The only meaningful question is whether the idea can survive real operating conditions.
The method therefore focuses on feasibility under constraint, not upside potential.
If a concept cannot remain viable within acceptable limits of preparation time, workflow complexity, ingredient exposure, and execution risk, it should not enter development.
Inputs are limited by design
Many potential inputs were intentionally excluded.
The system does not:
- predict sales
- generate recipes
- rank ideas by appeal
These activities belong after development begins.
Including them earlier adds noise without improving the decision.
The method prioritises a small set of inputs that operators can realistically assess before committing resources.
Constraints are not weights
Operational factors are treated as constraints, not preferences.
If a concept violates a non-recoverable condition — such as service disruption, unstable preparation, or excessive skill dependency — it is rejected.
No amount of attractiveness compensates for structural infeasibility.
Decisions must be explainable
The output is not a score.
Each decision identifies the dominant constraints and risks that triggered it.
This allows outcomes to be reviewed, challenged, and reused as reference.
The method is deliberately narrow.
It exists to answer one question only:
should this concept enter development at all?
Everything else happens later.