One-sentence answer: An algorithm works when a precisely defined sequence of operations transforms admissible inputs into outputs that satisfy a specification, terminates under the promised conditions, uses acceptable resources, handles edge cases and remains correct when the surrounding system meets the real world.
An algorithm is not merely “code.” It is the method underneath the code: a procedure for turning one state into another. Long division is an algorithm. Binary search is an algorithm. A route-planning method is an algorithm. A sorting procedure is an algorithm. A recommendation system may contain many algorithms. An AI model can be trained or queried through algorithms, but the model itself is not identical to the algorithm that operates on it.
An algorithm earns trust from its contract: what goes in, what must remain true, what comes out, when it stops and what happens at the edges.
Quick Read: the causal chain
PROBLEM → INPUT DOMAIN → SPECIFICATION → PRECONDITIONS → ORDERED OPERATIONS → STATE CHANGES → INVARIANTS → TERMINATION → OUTPUT → CORRECTNESS CHECK → COMPLEXITY → EDGE / ADVERSARIAL TESTS → DEPLOYMENT RECEIPT → REVISION
1. Start with the problem, not the procedure
An algorithm is meaningful only relative to a problem. “Sort these records by date” is a different job from “find the earliest valid date,” even if both inspect the same data. “Find the shortest route” differs from “find the safest route” or “find a wheelchair-accessible route.”
The problem statement should therefore identify:
- the admissible inputs;
- the desired output;
- constraints;
- what counts as a correct answer;
- whether an exact or approximate answer is acceptable;
- resource limits;
- which failures are unacceptable.
If the problem is underspecified, a perfectly executed algorithm can still solve the wrong job.
2. Inputs define the operating envelope
Every algorithm assumes something about its inputs. A sorting routine may assume comparable keys. A graph algorithm may assume non-negative edge weights. A numerical algorithm may assume finite values within a stable range. A school scheduling algorithm may assume room capacity and teacher availability are known.
These assumptions are preconditions. They should be visible because correctness usually depends on them.
| Question | Why it matters |
|---|---|
| What inputs are valid? | Defines the domain where the guarantee applies. |
| What inputs are malformed? | Determines error handling. |
| What inputs are extreme? | Exposes overflow, memory and timing failures. |
| What assumptions are hidden? | Reveals where correctness can silently fail. |
3. The algorithm changes state through ordered operations
An algorithm consists of operations arranged so that each step moves the system toward a desired state. Some procedures are sequential. Others branch on conditions, repeat loops, recurse, explore alternatives or operate concurrently.
The important property is not that the instructions are written as numbered lines. It is that the transition from one state to the next is defined well enough to analyse.
4. Correctness has two parts: if it stops, is the answer right—and does it stop?
Algorithmic correctness is commonly separated into two questions:
- Partial correctness: if the algorithm terminates, does the output satisfy the specification?
- Termination: does the algorithm eventually stop for every promised input?
Together they support total correctness for the declared input domain. A procedure that always produces the right answer but sometimes loops forever is not fully correct for tasks that require completion.
5. Invariants let us reason across many steps
An invariant is a property that remains true while the algorithm proceeds. Invariants are powerful because they provide a bridge between the initial state, every intermediate step and the final result.
For example, during insertion sort, one useful invariant is that the portion already processed remains sorted. In route search, an invariant may describe which distances are already final under the algorithm’s assumptions. In a financial reconciliation procedure, the total balance may be required to remain conserved through transformations.
When an invariant breaks, the algorithm has either received an input outside its contract or executed a faulty transition.
6. Correctness ≠ efficiency
Two algorithms can produce the same correct answer while using radically different time or memory. Complexity analysis asks how resource demand grows as input size grows.
| Complexity idea | Question |
|---|---|
| Time complexity | How does the number of operations grow? |
| Space complexity | How does memory use grow? |
| Worst case | What is the maximum resource demand inside the declared domain? |
| Average case | What happens under a specified input distribution? |
| Amortised analysis | What is the average cost across a sequence of operations? |
NIST’s Dictionary of Algorithms and Data Structures remains a useful public reference for algorithmic techniques, structures and complexity terminology; NIST updated its publication record in May 2026.
One benchmark runtime on one machine is not complexity analysis. It is an observation from one operating condition.
7. Exact, approximate, randomised and online algorithms offer different guarantees
Not all algorithms promise the same kind of answer.
| Type | Typical guarantee |
|---|---|
| Exact | Returns an exact solution when assumptions hold. |
| Approximation | Returns a solution with a stated relationship to the optimum or target. |
| Randomised | Uses random choices; guarantees may be probabilistic or expected. |
| Online | Makes decisions as inputs arrive without knowing the full future. |
| Heuristic | Uses a practical strategy without a universal formal guarantee. |
Calling all of these “algorithms” is correct, but the receiver must know which guarantee applies. A heuristic that performs well in practice should not inherit the proof obligations of an exact method, and an approximation should not be described as exact merely because its answer looks plausible.
8. Data structures change what the algorithm can do efficiently
Algorithms and data structures are tightly coupled. A queue, heap, hash table, tree, graph representation or index changes the cost of accessing and updating state.
The same abstract problem can therefore have different practical behaviour depending on representation. This is why How Databases Work and How Indexing Works matter downstream: data organisation is part of system performance.
9. Numerical assumptions can break mathematically correct procedures
Real computers do not manipulate infinite-precision mathematics by default. Integer overflow, floating-point rounding, underflow, finite precision and representation error can violate assumptions that look harmless on paper.
A robust implementation therefore asks:
- Can values exceed the numeric range?
- Can subtracting near-equal values destroy precision?
- Are comparisons stable under rounding?
- Does the algorithm assume associativity that floating-point arithmetic does not preserve exactly?
- Are units mixed?
A mathematically valid algorithm can fail as software if its machine-number model is ignored.
10. Edge cases are part of the specification
Algorithms often fail at boundaries: empty input, one item, duplicate values, maximum values, disconnected graphs, missing data, zero denominators, impossible constraints, cyclic dependencies or simultaneous events.
Testing should therefore include more than representative examples:
- boundary-value tests;
- property-based tests;
- randomised test generation;
- adversarial cases;
- large-input stress tests;
- invalid-input tests;
- independent implementation where consequence warrants it.
How Verification Works owns the general requirement-to-evidence contract.
11. Average performance can hide worst-case or adversarial failure
An algorithm may perform well on typical historical inputs but fail badly on specially constructed or unusual inputs. This matters in cybersecurity, finance, routing, recommendation, allocation and any environment where other actors can react strategically.
The hostile question is: What input would make this method behave worst, and can such an input occur naturally or be created deliberately?
12. Algorithm ≠ program ≠ model ≠ policy
| Algorithm | A procedure or method for transforming inputs into outputs. |
|---|---|
| Program | An implementation that may contain many algorithms, interfaces and system dependencies. |
| Model | A representation of selected aspects of reality. |
| Policy | A rule or governance choice about what should be done. |
| Optimisation | A problem of selecting among feasible alternatives under an objective. |
An algorithm may implement an optimisation method. A program may execute it. A model may provide the state it operates on. A policy may decide whether its output may be used. These layers should not be collapsed.
13. Worked example: finding a route
Consider a route-finding algorithm. If the problem is “shortest distance,” the graph may assign distance to each edge. If the problem becomes “fastest arrival,” travel time varies with congestion and time. If the receiver needs wheelchair access, stairs and lift status become feasibility constraints rather than minor preferences.
The algorithm can be perfectly correct for the shortest-distance graph and still return a useless route for the actual receiver. The error is not necessarily inside the algorithm. It may be in problem definition, data, model, or authority.
This is why world-class system design keeps algorithmic correctness separate from receiver correctness.
14. Algorithms across domains
| Domain | Algorithmic job | Boundary |
|---|---|---|
| Mathematics | Symbolic or numerical procedure | Correctness depends on mathematical assumptions. |
| Search | Retrieve/rank candidates | Ranking objective may not equal truth or usefulness. |
| Transport | Path finding and routing | Data freshness and receiver constraints matter. |
| Scheduling | Order tasks and resources | Objectives can conflict with fairness and resilience. |
| AI | Training, inference, search, tool selection | Algorithmic execution does not guarantee factual or ethical correctness. |
| Medicine | Decision support or workflow logic | Clinical ownership, validation and individual context remain required. |
| Education | Sequencing, assessment, recommendation | Learner evidence is not learner identity. |
15. Common algorithm failures
| Failure | What happened | Repair |
|---|---|---|
| Wrong specification | The procedure solves the wrong job. | Restate target, receiver and acceptance condition. |
| Precondition violation | Input falls outside assumptions. | Validate inputs or use another method. |
| Non-termination | Procedure can loop indefinitely. | Prove/develop a termination measure or bound. |
| Invariant break | A required property is lost during execution. | Identify faulty state transition. |
| Complexity explosion | Method becomes unusable at scale. | Change algorithm, representation or approximation. |
| Numeric failure | Machine arithmetic violates mathematical assumptions. | Use stable methods and explicit bounds. |
| Average-case blindness | Rare/adversarial cases cause severe failure. | Test worst-case and hostile inputs. |
| Receiver erasure | Algorithm metric improves while human outcome worsens. | Measure end-to-end receipt and revise objective. |
16. Hostile test: prove the contract, then attack the edges
- What problem is being solved?
- What inputs are allowed?
- What output property defines correctness?
- Which invariant should remain true?
- Why does the procedure terminate?
- How does time and memory grow with input size?
- Which numeric assumptions exist?
- What happens on empty, extreme, duplicate or malformed inputs?
- What is the worst or adversarial case?
- Does the final receiver actually benefit?
17. Where Algorithms fits in the wider How Things Work map
Algorithms connects Problem Solving, Models, Optimisation, Verification, AI, Search and Indexing.
Its distinct public job is: How does a defined procedure transform admissible inputs into outputs with stated correctness and resource guarantees?
18. What this article does not claim
- An algorithm is not automatically software.
- A program that runs without error is not automatically correct.
- Correctness is relative to a specification and preconditions.
- Fast average performance does not eliminate worst-case failure.
- An optimisation algorithm does not define which objective is morally or institutionally legitimate.
- An AI algorithm does not create factual truth or authority.
- Algorithmic correctness does not guarantee a good receiver outcome.
19. Observable mastery test
You understand algorithms when you can take an unfamiliar procedure and state its problem, input domain, preconditions, state transitions, invariant, termination argument, output specification, complexity, edge cases, numeric assumptions and receiver-level failure condition—and distinguish a correct algorithm from a merely successful demonstration.
Authoritative source corridor
- NIST: Dictionary of Algorithms and Data Structures — public reference for algorithmic techniques, structures and terminology; publication record updated May 7, 2026.
- NIST Dictionary of Algorithms and Data Structures — live dictionary.
- Turing (1936): On Computable Numbers — foundational formalisation of effective computation.
- How Verification Works — the cross-domain requirement/evidence contract.
Governing idea: The algorithm is only as trustworthy as the contract it can keep across inputs, scale, edge cases and the world outside the procedure.