Rules of Thumb

Rules of thumb are compact heuristics: small methods that help a person estimate scale, notice risk, choose the next measurement, or make a reversible decision before every variable is known. They are useful because they compress experience. They are dangerous when they pretend to be proof.

The right posture is practical and humble: use a heuristic to get orientation, attach units and assumptions, keep the error visible, and replace the shortcut with measurement when the decision becomes expensive. A rule of thumb is successful when it leads to a better question.

This page connects mathematics, linear algebra, standards, data sources, industrial products, overlanding, maps, data visualization, human-machine interaction, SEO, software libraries, design, graphs, semantic web, and philosophy because rough estimates need units, provenance, communicable uncertainty, and a clear retirement path.

A rule of thumb is a bounded decision aid. It is not a universal law, formal proof, or measured fact. It should say what it estimates, where it works, how wrong it may be, and what stronger evidence should replace it.

Good heuristics are memorable, directionally right, explicit about their domain, and easy to falsify. Bad heuristics hide their assumptions, omit units, or survive after the evidence has changed.

A useful heuristic has four properties:

• scope: it names the domain where the shortcut applies;
• scale: it carries a unit, order of magnitude, threshold, or comparison class;
• failure: it names conditions where the shortcut breaks;
• replacement: it points to the measurement, source, standard, or calculation that supersedes it.

For example, "1 milliliter of water is about 1 gram" is useful for ordinary kitchen, classroom, and field reasoning. It is not a precision metrology statement about every liquid under every temperature and pressure. The rule works because the domain is ordinary water, the unit is clear, and a stronger measurement is obvious when precision matters.

That trust boundary is a philosophy concern: a heuristic should be marked as a bounded method, not smuggled into the graph as a settled fact.

Common measurement shortcuts include:

• 1 milliliter of water is approximately 1 cubic centimeter and approximately 1 gram near ordinary room conditions.
• 1 liter of water is approximately 1 kilogram.
• 1 inch is exactly 2.54 centimeters.
• 1 meter is a little longer than 1 yard.
• 1 mile is about 1.61 kilometers.
• 1 kilometer is about 0.62 miles.
• 1 acre is about 0.405 hectares.
• A 1 percent improvement compounded about 70 times roughly doubles, because of the rule of 70.
• A rough order-of-magnitude answer is often more useful than a false-precise number with no source.

These are orientation tools, not permission to drop units. A useful estimate keeps the unit attached to every line so the error has somewhere visible to live.

Good back-of-the-envelope work usually starts by decomposing the problem into count, size, rate, and duration:

• how many things are there?
• how large is each thing?
• how often does it happen?
• how long does it run?
• what unit converts the answer into a decision?

Common patterns include powers of ten, reference classes, minimum-likely-maximum ranges, dimensional analysis, known anchors, and second-method checks. The practical move is to ask, "What would have to be true for this estimate to be wrong by 10x?"

In linear algebra, this same habit appears as a model with assumptions, inputs, residuals, and sensitivity. In data visualization, it appears as axis choice, denominators, uncertainty bands, and readable annotations.

A compendium rule should be written as a small method, not a slogan. A durable record keeps:

• the quantity or decision being estimated;
• the unit, scale, or comparison class;
• the ordinary domain where the rule works;
• the known failure cases;
• the observed or cited source;
• the confidence level or expected error range;
• the stronger measurement, calculation, source, or standard that should replace it.

That structure keeps heuristics useful for SEO, search, and graph navigation. A reader can skim the rule quickly, but the index can still distinguish a conversion fact, a field estimate, an interface heuristic, a procurement checklist, and a research triage threshold.

Rules of thumb should be matched to the cost of being wrong:

• Low stakes: use the heuristic freely to get orientation, plan a conversation, or choose what to measure next.
• Medium stakes: keep a range, cite the source, and check the estimate against a second method.
• High stakes: replace the heuristic with measurement, standards, review, and a traceable calculation.

This matters for standards, industrial products, data storage, and human-machine interaction. A quick estimate of file size is fine for planning. A quick estimate of load rating, medical dosage, electrical safety, or structural capacity is not enough.

Every heuristic should carry an implied error range. Some are good within a few percent under ordinary conditions. Others only tell you whether the answer is closer to ten, one hundred, or one thousand. That difference matters more than elegance.

For a wiki entry, write the bound plainly when it is known: exact conversion, ordinary-condition approximation, order-of-magnitude estimate, or rough planning heuristic. If the bound is unknown, say so and link the rule to a source or stronger method. This keeps the graph from treating a shortcut as a universal measurement fact.

Heuristics are most useful when they say what happens next. A threshold can trigger a measurement, review, design change, archival capture, or stronger calculation:

• if a page has no body-backed incoming links, add real reciprocal context before calling it connected;
• if a chart's axis choice changes the apparent conclusion, show the alternative or explain the scale;
• if a dependency becomes foundational, write an adoption gate before merging it;
• if a field estimate can affect safety, replace it with a specification, measured value, or standard;
• if a search-visible page feels thin, expand the article before optimizing metadata.

Thresholds turn rough judgment into repeatable practice. They belong near data visualization, industrial products, SEO, and libraries because each field needs to know when a shortcut has done enough and when it has become risky.

Rules of thumb are most useful when grouped by domain:

• measurement: unit conversions, density approximations, distance anchors, scale references, and significant figures;
• computing: memory, storage, latency, throughput, build duration, index size, bandwidth, and queue depth;
• design: contrast, line length, screen density, touch target size, recovery cost, and reading-speed assumptions;
• operations: retries, lead time, staffing, failure rates, service levels, and cost envelopes;
• history and field work: travel distance, artifact scale, map uncertainty, preservation conditions, and source reliability.

The domain label is part of the rule. A field archaeology estimate, a data storage estimate, and a product-operations estimate can all use the same arithmetic but answer different kinds of questions.

Reference-class reasoning asks, "What similar cases have already happened?" It is often better than inventing a fresh model from scratch. For a software project, compare against previous builds, migrations, bug-fix cycles, or content indexing runs. For travel, compare against actual door-to-door trips rather than map distance. For storage, compare against measured corpus size and growth rate.

Overlanding makes this concrete. Map distance is a weak estimator for rough tracks, heat, altitude, mud, fatigue, gates, and recovery time. A better reference class is the last comparable route with the same vehicle, load, season, road surface, and driver condition.

The trap is choosing the flattering class. A small website migration may belong with "content migrations" rather than "quick config changes." A prototype may belong with "unknown integration work" rather than "one script." Good reference classes make the estimate less theatrical and more honest.

Systems of measurement are social infrastructure. Metric, SI, imperial, US customary, typographic, astronomical, engineering, and historical units all encode assumptions about the work they were made for. Unit conversion is not busywork; it is often where hidden mistakes enter a model.

Ancient units such as the cubit, foot, stadion, li, or mile are especially context-dependent. They are useful for reading history and archaeology, but they should be treated as ranges unless a source defines the exact local standard. Modern standards bodies exist partly to remove that ambiguity from engineering, science, trade, and safety-critical work.

Design heuristics are useful only when they protect a specific reader or operator task. "Keep line lengths readable" is stronger when it names a content type, viewport, font size, and scanning behavior. "Confirm destructive actions" is stronger when it names action frequency, reversibility, user expertise, and the cost of a mistaken confirmation.

In human-machine interaction, heuristics should be treated as review prompts, not laws. They help a designer find likely friction, but the replacement evidence is observation, accessibility review, analytics, support logs, or task-completion testing.

For this compendium, display heuristics should preserve a readable measure, clear section hierarchy, durable anchors, accessible contrast, meaningful internal links, and enough article substance that metadata is not doing the work of content.

Content heuristics are triage rules. A page with no reference sources is not necessarily wrong, but it is harder to trust. A page with no body-backed internal links is under-integrated. A page whose title, description, heading, aliases, and graph node all say nearly the same thing may be discoverable without being useful.

For SEO, the useful rule is not "add keywords." The useful rule is "make the entity clearer." That means distinct descriptions, body evidence, canonical names, aliases, internal links, references, and structured data that match the article rather than decorate it.

Software work is full of shortcuts: latency budgets, file-size estimates, dependency health checks, cache invalidation windows, retry limits, build duration estimates, and service-level objectives. These are useful only when tied to observed systems.

A software library adoption heuristic should record package purpose, maintainer activity, dependency chain, release cadence, license, security history, and replacement plan. A data storage heuristic should record growth rate, retention policy, backup cost, restore time, and the query that produced the estimate.

Operational heuristics should become dashboards, alerts, or runbooks when the cost of surprise is high.

Field work uses heuristics because perfect information is often unavailable. A route-time estimate, map-scale judgment, fuel reserve, weather interpretation, or site-access assumption can be good enough to plan the next check. It is not good enough to erase uncertainty.

For maps, a rule should preserve coordinate reference system, scale, date, source, and confidence. For topology, it should distinguish adjacency, containment, overlap, and connectedness instead of collapsing every relation into "near." For industrial products, it should never replace the manufacturer specification where safety or fit matters.

The best way to improve rules of thumb is to keep score. Write the estimate before looking up the answer. Record the actual value. Notice whether your errors are random or biased. Over time, this builds a private library of scale: file sizes, travel times, energy use, page counts, build durations, conversion rates, storage costs, and human attention limits.

Calibration links this page to data storage, data visualization, and standards. Estimates become more useful when they can be shown, checked, revised, and retired.

Every useful heuristic should accumulate counterexamples. Rules fail when units change, environments drift, incentives distort the measure, samples are biased, or a local convenience becomes a general claim. A catalog of failures is not an embarrassment; it is how the rule becomes safer.

For source work, this means recording when a dataset was stale, non-representative, rate-limited, or missing identifiers. For product work, it means preserving substitutions, inspection notes, and part failures. For interface work, it means recording when a "simple" control confused users, hid state, or made recovery harder. These failures give the graph better negative edges: invalid_when, contradicted_by, superseded_by, and requires_review.

The mature use of a heuristic is knowing when to retire it. A quick byte-size estimate can become a measured corpus scan. A travel-time guess can become a route log. A volume approximation can become a weighed sample. A rough linear model can become a documented linear algebra calculation with assumptions and residuals.

This is why rules of thumb belong near data sources. Each rule should point toward a stronger source of truth: instrument reading, standard table, source query, simulation, historical dataset, reviewed calculation, or direct observation.

A useful heuristic record should preserve the rule, unit, domain, assumptions, source, known failure cases, confidence, and replacement calculation. That lets the knowledge graph connect a shortcut to mathematics, linear algebra, standards, graphs, measurement systems, and examples where the rule breaks.

The graph should not treat a rule of thumb as a fact. It should represent it as a bounded method: works under these conditions, estimates this quantity, comes from this source, and should be replaced by this stronger method when precision matters.

Useful predicates include estimates, approximates, assumes, valid_under, invalid_when, replaced_by, derived_from, measured_by, calibrated_by, and contradicted_by. Those edge types make it possible to search for shortcuts without confusing them with verified measurements.

Fields worth preserving for heuristic records include rule text, estimate target, unit, domain, scale, ordinary range, error band, source URL, source type, confidence, failure cases, replacement method, examples, and last calibration date.

Those fields make a rule useful across semantic web, data sources, standards, and data visualization. A graph can then answer, "Which heuristics affect display quality?", "Which rules depend on SI units?", or "Which shortcuts should be replaced before publication?"

A rule of thumb should have a lifecycle, not an aura. It begins as a remembered shortcut, becomes useful when its domain and unit are named, becomes trustworthy when it is calibrated against observations, and becomes risky when it keeps being used after conditions change. A healthy rule record should therefore say whether the rule is informal, measured, calibrated, replaced, obsolete, safety-critical, or publication-ready.

This lifecycle is especially important for cross-domain pages. A design heuristic may be good for a familiar interface but wrong for accessibility. A maps heuristic may work at one scale and fail at another. A data storage heuristic may be fine for a personal archive but reckless for regulated evidence. A software library heuristic may favor activity and still miss security, governance, or maintenance risk.

The reader workflow is simple: identify the quantity, unit, ordinary range, source, known failure cases, and replacement calculation. Then ask what decision the rule is allowed to influence. If the decision affects safety, money, privacy, publication, or long-term preservation, the rule should point toward a stronger method before it is trusted.

Graphing that lifecycle keeps the page honest. A heuristic can be linked to examples where it works, counterexamples where it fails, the standard or measurement system it depends on, and the data source that eventually replaces it. The result is a wiki that preserves practical judgment without pretending that every shortcut is a fact.

The strongest rules also carry a stopping condition. A reader should know when to stop estimating and start measuring: after a threshold is crossed, before publication, before purchase, before public routing, before a safety decision, or whenever the error band would change the conclusion.

Public rule cards should be more explicit than private mental shortcuts. A publication-ready heuristic should show the formula or sentence, ordinary range, unit, confidence, sample source, known traps, and replacement method in one small record. That makes the rule useful in data visualization, because the chart can show both the estimate and the uncertainty. It also makes the rule useful in semantic web contexts, because a downstream page can cite the rule as a bounded method rather than as an unsupported fact.

For search, the important terms are often the hidden ones: unit conversion, error band, back-of-the-envelope, Fermi estimate, safety margin, calibration, baseline, and threshold. Keeping those terms close to examples lets the wiki retrieve a useful rule when a reader does not yet know the formal method.

The maintenance question is whether the rule still saves time after its caveats are known. If explaining the caveats takes longer than doing the measurement, the heuristic has graduated out of public guidance and should become a pointer to the stronger calculation.

That graduation should be recorded instead of silently deleting the rule. Old shortcuts explain why a workflow used to feel reasonable, and they help readers avoid repeating an attractive but outdated estimate.

Rule-of-thumb systems fail in recurring ways:

• the unit is missing or silently converted;
• the ordinary domain is treated as universal;
• an exact conversion is mixed with an approximation;
• the sample that taught the rule is biased;
• a local workflow shortcut becomes public guidance;
• a safety-critical decision relies on an uncited estimate;
• the graph stores the rule as a fact rather than as a method;
• the replacement calculation is never named.

The fix is to make the rule small, sourced, bounded, and easy to retire.

• NIST Metric SI (opens in new tab)
• NIST Special Publication 811 (opens in new tab)
• BIPM SI Brochure (opens in new tab)
• NIST fundamental physical constants (opens in new tab)
• NIST measurement uncertainty topic page (opens in new tab)
• NIST/SEMATECH e-Handbook of Statistical Methods (opens in new tab)
• Nielsen Norman Group usability heuristics (opens in new tab)
• WCAG 2.2 Quick Reference (opens in new tab)
• Google SRE book on service-level objectives (opens in new tab)
• OpenSSF Scorecard (opens in new tab)

• Mathematics for exact structure after the estimate.
• Linear Algebra for model assumptions, residuals, and replacement calculations.
• Data Visualization for communicating scale and uncertainty.
• Standards for canonical definitions and interoperability.
• Data Sources for source provenance and refresh discipline.
• Data Storage for measured corpus size, growth, retention, and restore assumptions.
• Human-Machine Interaction and Design for heuristics that shape interfaces, states, and recovery paths.
• SEO and Software Libraries for lightweight quality gates that should eventually become explicit records.
• Maps and Overlanding for field estimates where route, season, source, and risk change the answer.