# Verified Computation

> Exact math goes to tools; reasoning stays with the model.

- Skill: `heat-death/verified-computation` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add heat-death/verified-computation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/heat-death/verified-computation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: heat-death (https://skillmd.com/u/heat-death)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/heat-death/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:

| Task | Preferred tool |
|---|---|
| Simple arithmetic | Calculator |
| Symbolic math, exact algebra, equations | SymPy |
| General numeric computation, scripts, multi-step logic | Python |
| Data analysis (means, regression, aggregation, large data) | Python + NumPy / Pandas / SciPy / Statsmodels |
| File-backed data | Read the file first, then compute with Python/Pandas |
| Live information | Weather / Time / Search / Market APIs — those tools, not a calculator |
| Big-int / high precision | Python `decimal`, `fractions`, or SymPy as available |

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?