Non-deterministic means that the same starting conditions can lead to different outcomes. In a deterministic system, identical inputs always produce identical outputs. In a non-deterministic system, you can run the same process with the same inputs and get a different result each time. The concept shows up across computer science, physics, and everyday software, and understanding it in one context makes it easier to recognize in the others.
The Core Idea
Think of a deterministic process like a vending machine: you press B4, and you always get the same snack. A non-deterministic process is more like rolling dice. You throw them the same way every time, but the result varies. The key distinction is predictability. In a deterministic system, if you know the current state and the input, you can predict exactly what happens next. In a non-deterministic system, there are multiple possible next steps, and you can’t say for certain which one will be taken.
This isn’t the same as saying the system is broken or random for no reason. Non-determinism often arises because the system has more than one valid path it could follow, and nothing forces it to pick the same one every time.
Non-Determinism in Algorithms
In computer science, a deterministic algorithm goes through the same sequence of states for a given input and always lands on the same output. A non-deterministic algorithm, by contrast, may take different paths through its logic on different runs, even with the exact same input. The output can vary from one execution to the next because the algorithm faces branching points where more than one step is valid and doesn’t have a fixed rule for choosing.
A useful way to think about non-deterministic algorithms is the “guess and check” model. Instead of methodically working through every possibility in order, a non-deterministic algorithm can “guess” a potential solution and then verify whether it’s correct. If you imagine it exploring many possible paths at the same time, it only needs one of those paths to succeed for the answer to count as correct.
This idea is central to one of the biggest open questions in computer science: the P vs. NP problem. The complexity class NP (which stands for “non-deterministic polynomial time”) contains problems where a proposed solution can be verified quickly, even if finding that solution from scratch seems to take much longer. A non-deterministic machine could, in theory, guess the right answer and verify it in a reasonable amount of time. Whether a regular, deterministic computer can always do the same thing just as fast is the question nobody has been able to answer.
Deterministic vs. Non-Deterministic Machines
Computer scientists formalize this distinction using abstract machines called automata. A deterministic finite automaton (DFA) has exactly one transition from every state for every possible input. Feed it a symbol, and there’s only one place it can go. A non-deterministic finite automaton (NFA) can have zero, one, two, or more transitions for the same symbol from the same state. It can even transition without consuming any input at all, something a DFA cannot do.
An NFA accepts an input string if at least one of its possible paths through the machine ends in an accepting state. It doesn’t matter if other paths fail. This “at least one path works” rule is a hallmark of non-deterministic models. Interestingly, NFAs and DFAs are equally powerful in terms of what languages they can recognize. Any NFA can be converted into an equivalent DFA, though the DFA may need far more states to do the same job.
Non-Determinism in Quantum Physics
Non-determinism isn’t just a computer science concept. It sits at the heart of quantum mechanics. A quantum system, left alone, evolves in a perfectly deterministic way according to the Schrödinger equation. But the moment you measure it, something fundamentally different happens. The system “collapses” from a spread of possible states into a single definite outcome, and which outcome you get is governed by probability, not certainty.
The Born rule tells you the odds of each possible measurement result, and those odds hold up beautifully across many repeated experiments. But it offers no explanation for why a specific result occurs in any single measurement. You can prepare two identical quantum systems, measure them the same way, and get different answers. This isn’t a limitation of your instruments. Under the standard Copenhagen interpretation of quantum mechanics, the randomness appears to be built into nature itself. Physicists and philosophers have debated what this means for nearly a century, and the question of why measurements produce definite outcomes at all remains one of the deepest unsolved problems in physics.
Where You Encounter It in Software
Most working programmers encounter non-determinism not through abstract theory but through the practical headaches it causes. The most common source is concurrency. When a program runs multiple threads at the same time, the operating system’s kernel decides which thread runs when. That scheduling is non-deterministic: the threads may execute in a different order each time the program runs. If two threads try to modify the same piece of data simultaneously, the final result depends on which one gets there first. This is called a race condition, and it’s one of the most frustrating bugs to track down because it might only appear under specific, hard-to-reproduce timing.
Non-determinism also shows up in “flaky” tests, automated checks that pass sometimes and fail other times with no code changes in between. These failures often trace back to non-deterministic behavior: thread timing, network latency, reliance on the current time, or unordered data structures. Research from IEEE has shown that lightweight detection techniques can help flag and debug this kind of non-determinism, but it remains a persistent pain point in software development.
True Randomness vs. Pseudorandomness
Computers that need random numbers usually use pseudorandom number generators (PRNGs). Despite appearances, these are fully deterministic. If you know the seed value that started the generator, you can reconstruct the entire sequence of “random” numbers it will produce. That predictability is useful for testing and reproducibility, but it’s a problem for security.
True randomness, the non-deterministic kind, comes from physical processes: electrical noise in hardware, radioactive decay, or other unpredictable events. NIST (the National Institute of Standards and Technology) draws a clear line between the two. Deterministic generators can be traced back to their seed. Non-deterministic entropy sources cannot, which is why they’re essential for generating cryptographic keys and other security-sensitive material.
Non-Determinism in AI Models
Large language models like the ones powering modern AI chatbots can behave non-deterministically depending on their settings. The key parameter is called temperature. When temperature is set close to zero, the model almost always picks the highest-probability next word, making its output nearly deterministic. As temperature increases, the probability distribution flattens, giving lower-probability words a better chance of being selected. At a temperature of 1, the output becomes noticeably varied, and you can ask the same question twice and get meaningfully different responses.
Even at supposedly deterministic settings (temperature of zero), researchers have documented that large language models can still produce slightly different outputs across runs. This residual non-determinism comes from low-level computational factors like floating-point arithmetic and GPU parallelism, not from the model’s design. It’s a subtle reminder that true determinism in complex software systems is harder to guarantee than it looks.