Verified Computation

Verified Computation Skill

Teaches the model when and how to delegate deterministic computation (arithmetic, units, engineering and financial math, data analysis) to deterministic tools (Calculator, Python, SymPy, NumPy, Pandas — whatever this environment provides), while keeping full responsibility for understanding, modeling, planning, sanity checks, and explanation.

This skill is not a ban on mental math. Modeling, derivation, estimation, and order-of-magnitude reasoning remain the model's job. The rule is narrow and precise:

Mental reasoning is allowed. Mental arithmetic is not a trusted source of exact results. Every deterministic result that is presented as exact must be produced or verified by a deterministic tool — unless no tool exists, in which case the result must be explicitly labeled an unverified model estimate.

When to Use

Trigger the computation workflow when the task requires a numeric result that the model would have to derive by calculation:

• Basic math — addition, subtraction, multiplication, division, percentages, ratios, averages, growth rates, deltas, CAGR, ROI
• Higher math — equations, systems of equations, exponents, logarithms, trigonometry, calculus, derivatives, integrals, limits
• Numerical computation — floating point, big integers, high-precision arithmetic, scientific notation, complex expressions, multi-step calculations
• Unit conversion — km↔m, kg↔g, MPa↔Pa, kWh↔MJ, °C↔°F, m³/h↔L/s, and any engineering/business unit change
• Engineering values — power, torque, speed, acceleration, energy, pressure, stress, strain, flow, mass, volume, density, efficiency, load, gear ratios, electrical and battery parameters, thermodynamic quantities
• Business / finance — revenue, cost, margin, net profit, ROI, IRR, NPV, cash flow, depreciation, interest, compounding, market sizing, per-unit economics, multi-step revenue models
• Data analysis — means, medians, variance, standard deviation, regression, correlation, distributions, cleaning, sorting, aggregation, large sums, pivots, time series
• Mixed tasks — anything combining data acquisition (weather, prices, lookups, file reads) with a computation step

When NOT to Use

Do not trigger on numbers that are facts, not computations. Core test:

"Did the model produce this number by computing it?" No → it is not a computation problem. Yes → apply this skill.

Non-triggering cases:

• User-provided facts — "The company has 100 machines", "the device was founded in 2020"
• Tool-provided facts — a price from a market API, a temperature from a weather tool, a value from a database or document
• Common knowledge facts — "World War II started in 1939"
• Pure information retrieval — "What time is it?" (time tool), "What's the weather in Singapore?" (weather tool)
• Identifiers and labels — version numbers, phone numbers, postal codes, model numbers

Never call a calculator just because a number appears in the conversation.

Workflow

1. Understand & model. Restate the question, identify the variables, and write the formula explicitly (visible to the user for complex tasks).
   • Example: annual revenue = daily throughput × price per ton × working days = 240 × 18 × 300.
2. Check inputs. Confirm units and magnitudes before computing. If an input is approximate ("~100 tons"), record that it is approximate.
3. Select the tool by task semantics (table below), never by habit.
4. Normalize units first. If the formula needs m/s and the input is km/h, convert before computing — the tool does the conversion.
5. Execute deterministically. Every new result — including intermediate values — comes from a tool call. Never compute step B from a mentally rounded version of tool result A.
6. Sanity-check the result. Order of magnitude, unit, and real-world plausibility are the model's job (Tool → precision; model → reasonableness).
7. Verify high-stakes results a second way. Engineering design, financial models, research data, safety-related values, large business decisions, or explicit user requests for precision: recompute with an independent method (different tool, reverse calculation, symbolic check). Simple arithmetic does not need double verification.
8. Explain. Report the result with its unit, the formula, and (for important results) which tool produced it — in one natural line, not a protocol recitation.

Tool Selection

Choose by task semantics, not by defaulting everything to Python:

Use the tools that actually exist in this environment. Do not invent tool names. The pattern for mixed tasks is data acquisition → deterministic computation → reasoning, chaining as many tools as the task needs (e.g. weather tool → calculator).

Computation Chain Integrity

Multi-step calculations keep every step inside a tool:

• Do: A → tool, B = f(A) → tool, C = f(B) → tool
• Don't: A → tool, then compute B and C mentally from A

The model may decide and explain why each step exists; it may not silently substitute its own arithmetic for a step that a tool should run. Chain the full expression in one call when possible (240 × 18 × 300 × 1.15) to preserve precision.

Precision and Units

• No false precision. Approximate inputs ("about 100 tons", "about 20 RMB/ton") yield approximate results. Do not present 2000 as an exactly measured real-world value; preserve the input uncertainty in wording ("about 2000", or a sensible significant-figure presentation). Computational accuracy (100 × 20 = 2000 exactly) is not input accuracy.
• No premature rounding. Keep intermediate values unrounded (10/3, not 3.33). Round only at display time, and only when presentation requires it.
• Units everywhere. State the unit of every result. If inputs mix units, normalize them before computing (the tool converts; the model chooses the target unit).
• Watch scale. If a tool result is off by orders of magnitude from the model's estimate, flag the discrepancy — something (unit, formula, input) is likely wrong. Re-check rather than accept.

Tool Failure and Unavailable Tools

• Tool failed. Read the error, fix the formula/syntax/unit, retry. Do not silently substitute a mental calculation for the failed call.
• No tool available. Say so plainly: "No deterministic computation tool is available in this environment, so this result is a model estimate, not a tool-verified value." For high-stakes calculations, recommend enabling a computation tool.
• Never fake verification. Never claim a tool ran, or that a value is "verified", when no tool executed. Tool results must come from real tool calls.

Presentation (UX)

• Simple case: output the natural line, e.g. 240 × 18 × 300 = 1,296,000 RMB/year. No protocol announcements.
• Complex case: formula → substitution → result with unit → (for important results) a one-line tool provenance note.
• The user should experience a competent calculator-augmented assistant, not a process being narrated.

Self-Check Before Final Answer

• Every exact numeric claim in the answer was produced (or verified) by a real tool call — no mental-arithmetic results presented as exact?
• No number was flagged as verified when the tool did not run?
• No calculation was triggered on a plain numeric fact?
• Units are consistent and stated; approximate inputs are still labeled approximate; no intermediate rounding leaked in?