Methodology
We build Kaltask tools to do one thing well and to show the work. This page describes the practices behind that claim.
How tools are built
Every Kaltask tool begins as a defined problem rather than a feature. We identify the calculation or transformation a person actually needs, name the inputs and outputs, and specify the method before any interface is designed. Tools are built as single-purpose utilities. A tool that would require the user to learn its conventions before it can answer their question has failed its brief and is rebuilt or retired.
How formulas and methods are sourced
Formulas are drawn from primary references: textbooks, standards documents, peer-reviewed sources, and official specifications. Where a calculation has multiple accepted forms, we select the one most appropriate to the tool's intended use and note the choice in the tool's documentation. Where a method is an approximation, we say so. We do not treat a formula as verified because it appears on other calculator sites.
How tools are tested
Each tool is tested against known values before release. We construct test cases from worked examples in source material, from edge cases that probe boundary behavior, and from inputs designed to break assumptions. Unit handling, rounding behavior, and conversion accuracy are verified independently of the primary calculation. A tool that passes its primary logic but rounds incorrectly is not considered working.
A worked example: how the 401(k) Calculator was verified
The 401(k) Calculator uses the standard future-value-of-an-annuity formula compounded over the contribution period, with a separate compounding pass for the existing balance. Verification went through three layers. First, the projection was reproduced in a spreadsheet using the same inputs and the same compounding interval. Annual results agreed to within one cent for representative scenarios (mid-career contributor, late-career catch-up, fresh starter at 22). Second, employer-match handling was checked against the IRS annual contribution and elective-deferral limits in effect at publication, with edge cases at the limit boundary and at the catch-up cutoff. Third, the withdrawal projection was checked against a fixed-period annuity calculation with both end-of- period and life-expectancy assumptions. We picked end-of-period for consistency with how most plan providers report projections, and we documented the choice inside the tool. None of these layers prove the tool answers every retirement question; they prove that for the questions the tool claims to answer, the numbers are correct.
Numerical precision and rounding
Calculations run in JavaScript's native double-precision floating point unless the tool needs more, in which case we say so and use a decimal library. Currency outputs are rounded to two decimal places at display time, never during intermediate calculation. Percentage outputs are rounded based on context. Interest rates and tax rates are kept to four decimal places of precision internally and two at display. Growth rates and confidence intervals round to one decimal at display. Unit conversions use exact ratios where the conversion is defined exactly (1 inch = 25.4 mm) and noted-precision constants where it isn't (gravitational acceleration, density of water at a named temperature). When a tool relies on an approximation such as Newton's method iterations, regression-fitted models, or time-of-flight estimators, the documentation says so and reports the precision range we tested it across.
How documentation is written
Every tool ships with documentation on the same page as the tool itself. The documentation covers what the tool calculates, how to use it, realistic use cases, worked examples, and answers to the questions people actually ask about the underlying method. Documentation is written to be read by someone who arrived from a search result and needs an answer in under a minute. We do not pad it. We do not write to a word count.
How updates and corrections are handled
Tools are not static. When a formula is refined, a standard changes, an edge case is reported, or we find our own mistake, we revise the tool and its documentation together. Corrections are not quiet. When a change affects results a user may have relied on, we say what changed and why. Feedback is read. Reports of incorrect output are treated as defects and prioritized accordingly.
Documentation, glossary, and cross-linking
Every tool's documentation lives in the page itself, server-rendered alongside the tool, not loaded after the fact. The text is extracted fromKALTASK-DOCmarkers inside the tool's source HTML at build time, which means the documentation is versioned with the tool that produced it. Domain terms used inside the documentation are scraped, reviewed, and given short, declarative definitions in the glossary; the build pipeline then injects glossary anchors into the documentation so the first occurrence of each term on each page becomes a click-through. Definitions stay flagged as pending until a human writes the definition and marks it as published. We do not auto-generate glossary text from a language model.
How we handle what a tool does not do
Every tool has a boundary. A screen size calculator is not a display engineering suite. A GPA calculator does not adjudicate transcript disputes. Where a tool's scope could reasonably be misread, the documentation names the boundary. We would rather send a user to a better resource than produce a confident answer to the wrong question.
Who builds this
Kaltask is operated by Alkyrie, a design-driven system. Tools are built, reviewed, and maintained by the same small team that sets the standards on this page. We are reachable through the contact page.