Deterministic Core, Non-Deterministic Shell
Outdata's Deterministic Core, Non-Deterministic Shell starts from Gary Bernhardt's Functional Core, Imperative Shell and relaxes one requirement: the core does not have to be purely functional, only deterministic, so a state machine that always gives the same result for the same inputs qualifies too. Everything that cannot repeat itself goes in the shell around it: unseeded randomness, threads, the network, the database, the clock. The practical half is written for anyone working in "the legacy & vibe-code mines": every messy codebase hides many small deterministic cores, and the job is to find them and gather them up, a gradual "defragmentation of determinism" that shrinks the part of the system you cannot test. I call this shape the bowtie: imperative edges, functional core. I talked it through with Peter Marreck on What Next? as the thin coordinator pattern, and it is a critical rule in my Intent project, Pure Function, Impure Coordination. The more of a program that lives in the deterministic middle, the more of it you can test and trust.
Was this useful?