Calculation, validation, and source methodology
Neutron STEM Lab pairs interactive tools with visible engineering context. The goal is not to hide a formula behind an input form. Published tool pages expose their core equations, assumptions, design boundaries, references, tool version, and—where available—worked examples, review dates, and representative validation cases.
Documentation completeness is reported explicitly. A tool without a published validation case or editorial review date is labeled that way rather than being presented as independently verified or recently reviewed.
Engineering quality status
Every workbench page includes an engineering-quality summary generated from the tool's own manifest. It always reports the published equations, assumptions, limitations, and references. Additional evidence—such as representative validation cases, worked examples, or an editorial review date—is shown only where that material has been published for the tool.
- Published evidence means the material is present on that tool page; it does not imply certification or third-party approval.
- Representative validation identifies a documented cross-check against an analytic result, reference value, or independently reproduced case.
- Worked examples expose intermediate values so a representative use case can be reproduced by hand or with another method.
- Content review records the date of an editorial/technical content review when one is published. Tool versioning remains separate from editorial review metadata.
- Reference count reports listed technical sources. A direct link is shown only when the manifest includes a source URL.
Calculation method
Calculations should be implemented from explicit equations or bounded numerical models that are appropriate for the tool's stated scope. Where a tool uses an approximation, first-order model, fixed-step solver, empirical relationship, or configurable screening criterion, that limitation should be visible on the same page as the result.
Units are part of the model rather than decoration. Inputs and outputs should identify their units, conversions should occur explicitly, and graphs should label axes with the quantity and unit being displayed. Invalid, non-finite, or physically incompatible inputs should fail visibly rather than silently propagating through saved or shared engineering state.
Validation policy
Representative calculations can be documented as validation cases. A validation case states the method used for the cross-check, the expected result, an observed result when one has been directly checked, and any meaningful tolerance or numerical-resolution note.
- Verified result: a representative engine output has been directly compared with a known result or independent calculation.
- Analytic cross-check: the expected behavior follows from a closed-form equation and is used as a numerical sanity check.
- Reference cross-check: behavior or a limit is compared against an external technical reference or device specification.
Passing a representative validation case does not prove a model is correct for every possible input. Numerical convergence, edge cases, tolerances, environmental conditions, and real hardware behavior can still matter.
How to independently check a result
- Record the exact inputs, units, selected model, and tool version.
- Read the displayed assumptions and limitations before interpreting the output.
- Recalculate a representative point from the published equation or an independent engineering method.
- Check orders of magnitude, signs, units, limiting cases, and conservation relationships where they apply.
- Open the cited primary source when a result depends on a rating, material property, constant, standard, or manufacturer specification.
- For consequential decisions, use an independent tool, current standard, test measurement, or qualified engineering review rather than relying on one browser calculation.
If a result cannot be reproduced, use the calculation-issue link on the tool page and include the tool version, inputs, expected behavior, and the independent method used for comparison.
Source policy
When a calculation depends on externally defined data, the preferred source order is primary technical documentation first, followed by established standards and authoritative engineering references. Examples include manufacturer datasheets and application notes, standards organizations, government or research-agency publications, and established engineering textbooks.
The site does not attempt to reproduce complete copyrighted standards or every page of a manufacturer datasheet. Component records and code-adjacent tools are summaries intended to help with selection and understanding; users should reopen the current primary document before a final design decision.
Standards, codes, and regulatory requirements
A calculator result is not a statement of code compliance unless the tool explicitly implements and documents the applicable requirement. Electrical, structural, pressure, environmental, safety, and other regulated designs can depend on jurisdiction, edition, installation method, materials, duty cycle, environmental conditions, and project-specific requirements that a general-purpose calculator cannot infer.
When a standard or manufacturer document is cited, verify the current revision and applicability before final design. A reference title on this site is not a substitute for access to the governing document.
Assumptions and limitations
Engineering calculators are only as valid as their model boundaries. Each tool can publish assumptions and limitations directly beneath the interactive workspace. Typical boundaries include balanced-system assumptions, ideal or first-order components, steady-state operation, simplified thermal paths, omitted parasitics, fixed-step numerical integration, or the absence of regulatory/code checks.
Neutron STEM Lab is intended for learning, design exploration, and preliminary engineering calculations. Safety-critical, code-regulated, production, medical, structural, high-energy, or otherwise consequential designs require appropriate independent verification and qualified engineering review.
Content review and revisions
Rich authority content can carry a visible review date. That date records when the page's technical explanation or validation material was last reviewed; it is not a claim that a particular credentialed person approved the design. Tool versions remain separately visible so calculation changes can be tracked independently from editorial changes.
Search metadata is intentionally derived from the same page content rather than from hidden claims. Long workbench summaries may be shortened for a concise meta description, while the full engineering scope remains visible on the page. Structured data describes the tools as educational learning resources and does not invent ratings, reviews, certifications, or professional endorsements.
Errors should be reproducible. Tool pages include a direct “Report a calculation issue” link with the tool identifier and version so incorrect equations, edge cases, unclear assumptions, or stale reference data can be reported precisely.
Methodology content reviewed: August 17, 2026.
Local processing and user data
Interactive calculations run in the browser. Tool state stays on the user's device unless the user explicitly exports a file, creates a shareable state URL, saves a portable Neutron project file, or submits information through a separate contact workflow. A tool may link to an external manufacturer or reference page, but ordinary calculator inputs are not sent to those references.