# One correct answer > Determinism is the one property the others depend on, as shown in the four properties]. Page: Methodology · Verify Canonical: https://banes-lab.com/disciplined-methodology/verify#one-correct-answer This section is stop 44 of 102 in the learning route. Previous: [29 - Unknown is not pass](https://banes-lab.com/disciplined-methodology/verify/unknown-is-not-pass.md). Next: [31 - Derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md). [Determinism](https://banes-lab.com/records/arch/determinism.md) is the one property the others depend on, as shown in [E1·a the four properties](https://banes-lab.com/disciplined-methodology/verify#one-correct-answer-panel-a). A deterministic mechanism can be healed, enforced, predicted and scaled, while pursuing those four separately produces mechanisms that have none of them; the ontology's names for what follows from determinism are [predictability](https://banes-lab.com/records/arch/predictability.md), [repeatability](https://banes-lab.com/records/arch/repeatability.md) and [reproducibility](https://banes-lab.com/records/arch/reproducibility.md). So the first question about a mechanism is not whether its subject can be checked, but whether its subject is deterministic, and [E1·b the first question](https://banes-lab.com/disciplined-methodology/verify#one-correct-answer-panel-b) shows what follows from each answer. The architecture page draws the consequence for the size of a system in [scale follows determinism](https://banes-lab.com/software-architecture/scale/scale-follows-determinism.md). ### Four properties, one axis Much of what looks like a tooling problem is a non-determinism problem in disguise. A check passes on one machine and fails on another, and the team learns to re-run it until it passes. A mechanism with two possible answers cannot be checked, healed or trusted at scale, because every consumer has to handle both. For this reason I reach for determinism first, because the other four properties follow from it. Determinism comes before speed and before elegance of any kind, rather than being traded against them. In practice, every mechanism is asked whether one correct answer exists for it. Where one does, the mechanism is built to produce that answer and nothing else, with its healer beside it. Where none does, the question is whether the subject can be changed so that one exists, and the subject is changed rather than the check loosened. Where neither is possible, that is said openly and a developer stays in [the loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md), with the evidence a check would need written down. To check this, run the mechanism twice on the same input and compare the bytes. A difference is a finding, whatever the tool says about itself. The model's output is not deterministic, and no instruction format makes it so; as the architecture page puts it, [the author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md). The input is therefore structured and the output verified. A rule often has one deterministic half and one that is not, and the honest form of the rule names which half is which. Each of the four derived properties fails in a recognisable way when determinism is missing. A healer working on a judgement call guesses. A check over a non-deterministic subject either fires on everything or flakes. A verdict that depends on who ran it cannot be quoted. A protocol that rests on care multiplies its cost by the number of parties while its enforcement stays flat. All four are the same defect, and naming determinism as the source is what lets one question test them all. Changing the subject is the move most often missed. An act that nothing records cannot be checked, but the same act performed through a tool that records it can, which is the purpose described in [tools live in the tree](https://banes-lab.com/disciplined-methodology/build/tools-live-in-the-tree.md). A rule that a reader has to remember cannot be checked, but the same rule written as a declaration a mechanism resolves can. The rule's wording does not change in either case. What changes is the subject, from something that happens in a turn to something that leaves an artifact, and once it leaves an artifact, the check, the healer and the verdict all follow. E1·a the four properties ```mermaid flowchart TB det["Deterministic · one correct answer exists"] heal["Healable · a fixer can restore it"] enforce["Enforceable · a check can hold it"] predict["Predictable · a reader can predict it"] scale["Scalable · a hundred consumers agree on it"] det --> heal det --> enforce det --> predict det --> scale ``` E1·b the first question ```mermaid flowchart TB mechanism["A mechanism is proposed"] subject{"Is the subject deterministic?"} build["Build the check and its healer"] change{"Can the subject be made deterministic?"} work["Change the subject · an act nothing records becomes an act a writer records"] conduct["Declare it unobservable, with the evidence a check would need"] mechanism --> subject subject -- yes --> build subject -- no --> change change -- yes --> work --> build change -- no --> conduct ``` ## Links to - [Determinism](https://banes-lab.com/records/arch/determinism.md) - [Predictability](https://banes-lab.com/records/arch/predictability.md) - [Repeatability](https://banes-lab.com/records/arch/repeatability.md) - [Reproducibility](https://banes-lab.com/records/arch/reproducibility.md) - [Scale follows determinism](https://banes-lab.com/software-architecture/scale/scale-follows-determinism.md) - [The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md) - [The author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md) - [Tools live in the tree](https://banes-lab.com/disciplined-methodology/build/tools-live-in-the-tree.md) ## Linked from - [Who does what](https://banes-lab.com/disciplined-methodology/start/who-does-what.md) - [Detect, log, fix](https://banes-lab.com/disciplined-methodology/build/detect-log-fix.md) - [Tools live in the tree](https://banes-lab.com/disciplined-methodology/build/tools-live-in-the-tree.md) - [The honest gaps](https://banes-lab.com/software-architecture/coverage/the-honest-gaps.md) - [The author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md) - [Scale follows determinism](https://banes-lab.com/software-architecture/scale/scale-follows-determinism.md)