Mission
A research-led technology initiative for complex systems
We study how complex systems can be understood, represented, tested, and translated into practical computational tools, publishing the models and tools we derive from that work.
Systems in Practice is a research-led technology initiative concerned with how complex systems can be understood, represented, tested and translated into practical computational tools. Our work addresses a recurring failure: as the number of interacting components, states and external dependencies increases, the underlying model fragments, and each component begins to define shared terms for itself.
Mission
To advance the understanding and practical application of complex systems through structured, repeatable research models and the dependable computational tools derived from them.
Systems In Practice holds that a model and its implementation are not two artefacts but one, expressed twice. The model is normative and the tool is derived from it. Where the two disagree, the model is correct and the tool is defective.
Purpose
SiP exists to reduce the gap between systems concepts and their practical implementation. It seeks to make complex system behaviour easier to define, reason about, test, and maintain by developing methods that preserve coherence as systems evolve.
Execution is one of the ways a model is tested. A model that cannot be executed has not been fully tested, and a tool that cannot be traced back to a model has not been fully specified. SiP treats the distance between the two as the thing being reduced.
Vision
A future in which complex systems can be designed and operated using explicit, testable, and reusable models that support reliable decisions, transparent reasoning, and sustainable technological development.
In that future, the specification is the audit. A system's behaviour can be reconstructed from its published model by someone who has never seen its source, and its conformance to that model can be demonstrated rather than asserted.
The Governing Rule
The model is normative. The tool is derived. No rule may exist only in code.
Any behaviour a tool exhibits that its model does not specify is a determinism failure, and is evaluated as such. This rule is the boundary between building tools and automating thinking, and it applies to every executable artefact SiP produces or accredits.
We call this derivation integrity: a model is published, an implementation is derived from it, and the derivation can be inspected by someone who has seen neither the code nor the author. A defect found during execution is corrected in the model first, and the tool follows. Fixing behaviour in code and leaving the model unchanged severs the derivation. It is the distinguishing claim behind this work, and the reason topics on this site try to name the rule behind a pattern, not just the pattern itself. It is one of four claims and six commitments set out in full in our Core Principles, the standard we hold ourselves to is described in our governing standard, and the layered structure it all rests on is mapped in the Knowledge Map.
Who it's for
This resource is built for practitioners: engineers, architects, product managers, and operators who are actively building or maintaining fintech systems. If you're knee-deep in loan servicing logic or debugging a payment reconciliation issue at midnight, this is for you.
The content assumes you have a baseline understanding of software systems and are looking for practical insights rather than introductory tutorials.
Our initial domain is financial systems: obligation and repayment architectures, state consistency, and computation under incomplete transaction observability. It is where the problems are hardest and our access is best. It is a proving ground, not the destination: we are committed to demonstrating the same approach in a second domain before we describe our output as a method rather than a solution.
What you'll find
The site is organized as topics: field reports from live systems, frameworks and mental models, and operational playbooks and implementation guides, searchable by tag rather than sorted into separate sections by kind.
Topics range from high-level system design to specific implementation details. Some are polished guides, others are evolving notes. Everything is a work in progress, reflecting the iterative nature of building real systems.
Topics are where this work reaches practitioners, the applied domain the Knowledge Map calls obligation systems. Underneath them sits the formal structure the map lays out in full: principles, models and open research questions that determine what gets written next.
About "Locked" content
You'll notice some topics are marked as locked. These aren't ready for public viewing yet. They might be incomplete, very project specific, need more research, or have been flagged for additional de-identification. Once they're ready, they'll be unlocked and available for everyone.
The locked status is a transparency signal. It shows what's being worked on and gives you visibility into the topics pipeline.
A Living Resource
Systems In Practice is continuously evolving. New topics are added against a published sequence rather than an ad hoc schedule, existing ones are updated as new learnings emerge, and the structure adapts as patterns become clearer. Every published item passes an internal validation standard before release, and nothing goes out on the strength of a deadline alone. This isn't a static textbook but a living knowledge base that grows with the field and its practitioners.
If you find value in this work, share it with others who might benefit. The more we can help, the better systems we'll all build.
Complex systems, made legible.
Want to Collaborate?
Have insights to share or interested in working on fintech systems together? Whether it's contributing content, reviewing patterns, or building tools, let's connect.