Short Answer
Every engineering calculation rests on a mix of verified data and simplifications: properties that had to be estimated, behaviors that had to be idealized, effects judged small enough to ignore. These judgments are the calculation’s assumptions, and they shape the result as much as the arithmetic does. Written well, an assumption tells the reader what was taken for granted, why, and how much the answer would change if the assumption were wrong. The core practice is simple to state: make each assumption explicit and separate, give it a justification, say what it does to the result, and keep the list traceable and current so a reviewer can verify the work.
What Counts as an Assumption in a Calculation
An assumption is a statement accepted as true, without proof within the calculation itself, in order to make the analysis possible. Engineering modeling guidance treats assumptions as a deliberate part of the modeling step: after the problem is clearly defined — what you want to know, and which system or control volume you are analyzing — the engineer decides which physics matters, identifies the significant transfers of mass, energy, and force, and then selects assumptions such as steady state, adiabatic behavior, uniform properties, ideal gas behavior, or frictionless flow, alongside the boundary and initial conditions, before simplifying and solving any governing equation (Purdue University lecture notes on the engineering approach to problem solving).
It also helps to distinguish assumptions from design inputs. A design input is specified information taken from an identified source, such as a specification, code requirement, drawing, vendor datum, or measurement. An assumption fills a gap: it is adopted where verified information is unavailable, unnecessary for the required accuracy, or impractical to obtain. Best-practice guidance for engineering calculations treats design inputs and assumptions as related but distinct topics, and a well-documented calculation keeps the two traceable separately, so a reader can tell what was looked up from what was decided.
Why Assumptions Belong in Writing
Calculations are a form of technical communication. Guidance from the University of Missouri notes that calculations are shared with other engineers, supervisors, and sometimes clients, and that a shared calculation must be formatted so the reader can understand the work and make sense of the answer (University of Missouri guidance on calculations and spreadsheets). An assumption that exists only in the author’s head cannot be understood, checked, or corrected by anyone else, and it cannot be revisited when conditions change.
Writing the habit early matters. Purdue advice on written assignments reports that employers and alumni consistently rank written communication among the most important engineering skills, and among the least developed, and recommends practicing good habits on low-stakes documents such as homework, where feedback is available and the consequences of imperfect work are small (Purdue advice for preparing written assignments). Stating assumptions cleanly is one of the simplest of these habits to carry into professional practice.
In industrial and regulated settings, the stakes are formal. Best-practice guidance developed within the U.S. Department of Energy complex (EFCOG Best Practice #65) presents a framework for engineering calculations covering development, design inputs and assumptions, documentation and content, format, rigor, review and verification, approval, and revisions, grounded in quality requirements including 10 CFR 830, DOE O 414.1C, and ASME NQA-1 (EFCOG Best Practice #65, Engineering Calculations). Under such programs, an undocumented assumption is not merely untidy; it is a gap in the quality record.
Common Assumptions and When They Are Reasonable
Most recurring assumptions fall into a small number of families. The table below summarizes frequent examples, what each means, and when each is typically defensible. Reasonableness always depends on the specific system: a uniform-temperature assumption may suit an agitated vessel yet be indefensible across a heat-exchanger wall. The engineer, not the label, makes that call.
| Assumption | What it means | Typically reasonable when |
|---|---|---|
| Steady state | Nothing changes with time; accumulations are zero | The process runs at stable conditions and startup, shutdown, or upset transients are excluded from the question |
| Adiabatic | No heat crosses the boundary of the system | Equipment is well insulated, the process is fast, or heat effects are analyzed separately |
| Uniform (lumped) properties | A property such as temperature or composition is the same throughout the control volume | The region is well mixed, or gradients are small relative to the values of interest |
| Ideal gas | Pressure, volume, temperature, and amount of gas follow the ideal gas relation | Conditions are far from the gas’s critical point, where real-gas corrections become significant |
| Frictionless or negligible losses | Frictional pressure drops and losses are ignored | Lines are short and generously sized, or the calculation is a first-pass sizing estimate |
These examples come from standard modeling instruction. The discipline lies not in naming them but in recording when each was judged acceptable for the calculation at hand.
How to Write an Assumption, Step by Step
- Define the problem and the model first. Assumptions chosen before the problem is understood tend to be inherited habits rather than decisions. State what you want to know, identify the system or control volume, decide which governing physics is important, and fix the boundary and initial conditions. The assumption list then documents the choices actually made while setting up the model.
- State each assumption explicitly and separately. Give assumptions their own numbered list (A1, A2, A3, and so on) in a dedicated part of the calculation, one statement per assumption. Do not bury them in mid-paragraph prose, and do not leave them implicit inside a spreadsheet formula or a software default: if a tool’s default setting materially affects the result, that setting is an assumption and belongs on the list.
- Quantify whenever possible. Replace untestable qualifiers with numbers, ranges, or bounding values. ‘Negligible heat loss’ cannot be checked; ‘heat loss is less than 2% of the thermal duty’ can be (the figures here are illustrative). Quantified assumptions also show the reviewer exactly what was bounded and how.
- Give every assumption a basis. Three justifications cover most cases: a citation to a handbook, standard, vendor document, or previously verified calculation; a measurement or design record; or physical reasoning argued in a sentence or two. A routine assumption needs only one line; an assumption that drives a safety margin, or that a reviewer is likely to challenge, deserves fuller treatment.
- State the effect on the result. Say how the answer depends on the assumption, in which direction the error falls if the assumption is imperfect, and under what conditions the assumption stops being valid. If neglecting heat loss makes a predicted duty slightly low, that is a non-conservative direction, and the reader needs to know it.
- Make the list traceable and keep it current. Record who made each assumption and when; standard calculation sheets carry identifiers such as the author, date, page numbering, and sometimes space for who checked the work. At review, assumptions are checked like any other content. If inputs or design conditions change, reopen the affected assumptions and document a formal revision rather than quietly editing a number.
An Illustrative Comparison
The following hypothetical example shows the difference in practice. Suppose an engineer is performing a duty calculation for a gas cooler. A weak assumption block might read: ‘Assume steady state, ideal gas, and no heat loss.’ Every clause is technically an assumption, but nothing is checkable, and nothing tells the reviewer how the result depends on the choices. A stronger version of the same block reads:
- A1 — Steady state. Basis: the calculation covers normal operation after startup transients have ended. Effect: transient loads during startup are outside the scope of this calculation and would need a separate check if they could govern the design.
- A2 — Heat loss to the surroundings is less than 2% of the thermal duty. Basis: the equipment is specified with insulation, and a bounding estimate made during preliminary sizing supports the margin. Effect: neglecting heat loss slightly lowers the predicted duty; the direction is non-conservative for equipment sizing, so the sizing margin must absorb it.
- A3 — The gas is treated as ideal at the stated operating pressure and temperature. Basis: operating conditions lie well below the critical point of the dominant components. Effect: real-gas corrections are expected to change the calculated density by only a small amount at these conditions; if operating pressure rises in a future revision, this assumption is re-examined.
The second block is longer, but each line can now be verified, challenged, or updated on its own, which is the point of writing assumptions down.
Common Mistakes and How to Fix Them
- Silent assumptions inside tools. Defaults built into spreadsheets and software quietly shape results. Extract every default that materially affects the outcome into the written assumption list, where it can be reviewed.
- Vague wording. Phrases such as ‘normal conditions’ or ‘negligible losses’ cannot be tested and invite different readings. Quantify them or replace them with specific, checkable statements.
- Mixing inputs and assumptions. When verified data and estimates share one undifferentiated list, readers cannot tell what is firm. Keep design inputs and assumptions separate, as calculation best-practice guidance does, and cross-reference each assumption to where it is used.
- Justification-free assumptions. An assumption with no stated basis is an opinion. Attach at least a one-line basis to every entry, and identify the source of any cited value.
- Stale assumptions. Assumptions made for an early revision can survive into later work after the data that justified them has changed. Revisit the assumption list whenever design inputs change, and record revisions formally rather than editing values in place.
- Hidden structure. Assumptions scattered through prose are easy to miss. Consolidate them in one numbered section of the calculation with cross-references to where each applies.
Assumptions in Reviewed and Safety-Related Work
Where a calculation supports safety-related structures, systems, and components — items whose reliable performance prevents or mitigates accidents that could cause undue risk to public health and safety — assumption handling becomes part of a formal quality framework. The EFCOG guidance organizes calculation practice into topics including development, design inputs and assumptions, documentation and content, format, rigor, review and verification, approval, and revisions, drawing on ASME NQA-1 and its predecessor standard (ANSI N45.2.11) within the compliance frame of 10 CFR 830 and DOE O 414.1C. The guidance applies a graded approach, and it notes that extending these practices to non-safety-related items is good practice.
The practical consequences for assumptions are consistent across quality programs: assumptions are identified in the document, tied to justifications, evaluated for their effect on the result, and checked by an independent reviewer as part of verification. Assumptions awaiting confirmation — for example, those pending vendor data — are flagged for follow-up so they cannot silently persist into a final design. Even where no formal program applies, this is a sensible standard to write to, because a calculation that may one day be reused is a calculation whose assumptions may one day be relied upon.
Practical Takeaways
- Write every material assumption as its own numbered statement, with a basis and a stated effect, in a dedicated section of the calculation.
- Quantify assumptions where possible, giving ranges or bounding values instead of words such as negligible.
- Keep authorship and dates attached to assumptions, and treat the list as living content that is checked at review and updated through documented revisions.
- Scale the rigor to the consequence of the calculation, consistent with the graded approach used in formal calculation guidance.
Documented, justified, and quantified assumptions are what turn a calculation from a private estimate into a piece of engineering communication that others can verify, reuse, and build on.
FAQ
What is the difference between an assumption and a design input?
A design input is specified information taken from an identified source, such as a specification, code requirement, drawing, or measurement. An assumption fills a gap where verified information is unavailable or unnecessary for the required accuracy. Calculation best-practice guidance treats the two as distinct topics, and a documented calculation keeps them traceable separately.
How detailed should a written assumption be?
Detailed enough that a competent reviewer can see what was assumed, why, and how the result depends on it. Most assumptions need one to three sentences covering the statement, the basis, and the effect, with quantities or bounding values wherever they can be supplied.
Do routine or obvious assumptions still need to be written down?
Yes. Even a standard assumption such as steady state deserves its own entry with at least a one-line basis, because reviewers need to confirm that it holds for the specific system. Low-stakes work such as coursework is the recommended place to build the habit.
What should be done if an assumption turns out to be wrong?
Reopen the calculation rather than adjusting the answer quietly. Re-derive the affected results under the corrected assumption, document the change as a revision with a new date and reason, and have the revised work re-checked where the calculation is subject to formal review.
Leave a Reply