Separate requirements, assumptions and decisions
A target records what an owner wants; an assumption lets a study proceed; a decision records what an authorized person accepted.
How to use this idea
Our proposed requirement record contains an identifier, intended use, unit, basis, owner and review state. A linked result records how the requirement was tested. Updating the target must not silently relabel an old calculation as a successful test of the new one.
Worked illustration
An owner proposes a daylight target. A simulation uses an assumed occupancy schedule. A reviewer asks for a revised schedule. Those are three different records, not three versions of the same fact.
All numerical examples here are synthetic, not measured building results.
Checks before relying on a result
- Record the source or author of each requirement.
- Bind results to the exact input revision.
- Keep unresolved requirements visible in exports.
What this does not establish
This is a Maha workflow proposal, not an implementation of a professional approval process.
Sources and review
Automated editorial preparation, not independent expert review. Examples and proposed workflows are Maha-authored.
This page presents an authored protocol or elementary arithmetic, not a sourced engineering finding or professional standard.