Estimate

Focused Estimate Mode

You are running in focused-estimate mode. Execute the procedure below, produce its canonical output sections, then run the focused-mode validation step below — do not run the full 5-phase first-principles analysis. Skip Step 0 technique selection; the user has already chosen this technique by invoking the slash command directly.

When to reach for this

Use estimate when a decision hinges on the order of magnitude of a quantity and you do not have — or cannot trust — a direct lookup. The question you are really asking is: "What is this number, rebuilt from what I actually know?"

Good fit: the target quantity has units that can be reconstructed as a product of factors whose individual values are pinnable to physical constants, definitions, or direct measurements; a rough bracket (lower/central/upper) is sufficient to drive the decision; and an analogy-based estimate ("it's probably like X project") would be unverifiable.

Not a good fit: the problem involves weighing options against criteria with different importance — that is trade-off analysis, which scores options on weighted criteria rather than rebuilding a magnitude. It is also not the right tool when the task is to verify whether a compound claim's constituents reduce to irreducible primitives — that is the five-whys reduce-to-primitives mode, which traces a claim's structure down to physical laws and definitions rather than rebuilding a quantity's order of magnitude.

Decision rule — choosing among the three quantitative-ish techniques:

• Estimate = quantitative magnitude rebuild: HOW BIG is this quantity? Reconstructs a target number from constituent unit-factors (dimensional analysis). Stops when the factor product yields a bracketed magnitude — lower, central, upper.
• Trade-off = qualitative weighted scoring: WHICH option wins on weighted criteria? Assigns importance weights to criteria before scoring, preventing the reverse-engineering of weights to justify an intuitive pick.
• Five-whys (reduce-to-primitives) = definitional/physical reduction: WHAT is this claim made of? Traces constituent sub-claims to irreducible primitives (physical laws, definitions, direct measurements). Stops when every branch bottoms out at an anchor.

A single analysis often uses all three: decompose the performance claim to find what factors matter, estimate the magnitude of each factor, and apply trade-off if several technically viable options remain.

Procedure

Name the target quantity and its units (e.g., "$/kWh of delivered storage") before decomposing.

Decompose into unit-factors and show the cancellation. List the sub-quantities that multiply to the target's units, confirming they cancel correctly — dimensional analysis. Show the unit arithmetic explicitly (e.g., "kg/kWh × $/kg × 1/cycles → $/kWh").

Assign a first-principles value to each factor, sourced from one of:

• A physical constant or definition (e.g., specific heat capacity) — traceable and invariant.
• A direct measurement (e.g., a datasheet spec) — empirically anchored.

Do not cite a similar past project as the value — "a comparable project cost X" is an analogy, not a first-principles value. If no first-principles value exists, flag it as assumed with a defensible range.

Compute the central magnitude by multiplying the factors' central values, with the unit arithmetic explicit.

Bracket the result. For each uncertain factor, substitute its conservative and aggressive values to compute the lower and upper ends: [lower bound, central estimate, upper bound]. A Fermi estimate without an explicit bound range is incomplete — the bracket, not the single central value, is the deliverable.

Apply the decision-resolution stop criterion. The estimate is "good enough" when both the bracket's lower and upper ends drive the same decision. If the bracket spans an order of magnitude and straddles the decision threshold, tighten the dominant uncertain factor with a better measurement or escalate the uncertainty explicitly.

Read estimate-detail.md when you need:

• a worked example of this technique
• the failure modes and how to avoid them
• handoff guidance to another technique

Focused-mode validation

Check the output against its own completion condition before presenting it. The procedure above states one, in whichever form this technique uses — an exit criterion, a stop test, or an output contract. Read that condition again and confirm the output actually produced meets every requirement it names, not just the ones that were easiest to satisfy.

This is a scope-proportionate check, not the six-criterion Self-Audit Gate. That gate scores a six-section analysis document; this run produced one technique's output sections, not six, so walking all six criteria against it would score structure that was never produced. The larger of the two components: a focused run does not acquire evidence — it opens no cited source — so a claim resting on a source this run did not open stays marked rather than being resolved as confirmed.

Carry the mark forward. Anything this run could not verify is carried into the output marked with a ? rather than dropped or silently asserted as fact.

Revise once, then stop. If the check fails, revise the output and check it again. Revise at most one time. If it still fails after that pass, present the output with the gap named rather than revising again.

End every run with a validation line, without exception. State exactly one of the following, verbatim, never silently:

• Focused-mode validation: satisfied
• Focused-mode validation: revised once, now satisfied
• Focused-mode validation: not satisfied - <reason>

Close with the reason this line is unconditional: a silent run is indistinguishable from a run that skipped the check.

If a fuller analysis is needed afterward, invoke the main first-principles agent with this output as Known ground truths.