Core Principles

Four claims about how business systems behave, six commitments about how we work, and the tests you can apply to both.

The principles at a glance

These principles guide how we pursue our mission.

For quick reference. Each entry is given in full further down the page.

P1	State before events State is the truth. Events are evidence of change.
P2	Obligations before transactions A commitment exists independently of the activity that satisfies it.
P4	Observability is limited What is observable and what is true are not the same.
P3	Convergence over completeness Correctness is reached by defined mechanism, not assumed at input.
W1	The model is normative, the tool is derived No rule exists only in code.
W2	Determinism over judgement Two practitioners, one model, the same decision.
W3	Reconstructability Behaviour is predictable from the published model alone.
W4	Name what is undefined Gaps are stated, never resolved by inference.
W5	A method is not a method until it transfers One domain is a solution. Two is a method.
W6	Publish what fails Negative findings and falsifier status are reported.

The claims appear in the order P1, P2, P4, P3. The numbering follows the Knowledge Map, which orders them by dependency of definition; the reading order follows the argument.

Two different kinds of principle

Most principle documents mix two things that behave differently, and the mixture is what makes them unreadable. We keep them apart.

Claims are positions about how business systems actually behave. They could be wrong. They are the substance of the research, and each one below states what would show it to be wrong.

Commitments are constraints we accept on our own work. They cannot be wrong in the same way, but they can be broken, and each one below states what breaking it looks like and where the enforcement lives.

A reader who wants to know whether to take this body of work seriously should read the claims. A reader deciding whether to rely on something we published should read the commitments.

A principle that forbids nothing is not a principle. Every entry below names something it rules out. If you can imagine a system, a document or a decision that violates it, it is doing work. If you cannot, it is decoration and does not belong here.

The claims

Four positions, and they form an argument rather than a list. P1 and P2 say what the objects of a business system are. P4 says what can be known about them. P3 says what follows from that. They are therefore given here as P1, P2, P4, P3, which is not a numbering error.

State before events

Business reality is represented by state. Events are evidence of change, not the primary source of truth.

What it rules out: Treating the event log as the thing that is true rather than as the record of what was observed. Systems that cannot answer a question about the present without replaying the past. Designs in which correctness depends on no event having been missed.
Why it matters: Event histories are incomplete in practice far more often than architectures assume. A system whose correctness rests on a complete history is correct only in the conditions it will not meet.
What would show it wrong: If, across the three financial case studies, snapshot-based computation cannot reproduce the outcomes that full event replay produces, for a class of question those systems must answer. This is testable by August 2028.

Argued in 3 published items

Obligations before transactions

A commitment exists independently of the activity that satisfies it. It has its own identity, its own lifecycle and its own invariants.

What it rules out: Modelling a commitment as a derived property of payments. Attaching an obligation to an account or a customer as an attribute rather than treating it as an object in its own right. Systems in which cancelling a transaction silently alters what was owed.
Why it matters: An obligation is renegotiated, decomposed, suspended and versioned. None of those operations is expressible if the obligation only exists as a sum over transactions.
What would show it wrong: If, across the case studies, no question arises on which an obligation-centric model and a transaction-plus-schedule model give different correct answers. Identical answers at higher modelling cost falsify the claim as surely as wrong ones would.

Argued in 3 published items

Observability is limited

What is observable and what is true are not the same. The gap between them is a design constraint to be modelled, not a defect to be removed.

What it rules out: Treating missing, late or contradictory data as a quality problem that belongs to somebody upstream. Specifications that assume perfect inputs and delegate the rest to support teams. Any design whose failure handling is the sentence “this should not happen.”
Why it matters: The gap is permanent. Integrations fail, files arrive late, counterparties restate. A model that has no representation of the gap has no defined behaviour in the conditions it will actually operate under.
What would show it wrong: Evidence that in the relevant domains the observed and the true can be reconciled upstream reliably and at acceptable cost, making explicit modelling of the gap net overhead.

Not yet argued directly. See the open position below.

Convergence over completeness

A system can move toward correctness without complete information, provided the mechanism by which it does so is defined.

What it rules out: Designs that are correct only when every input has arrived. Equally, and this is the half that gets missed, the assumption that things will come right on their own. Convergence with no named mechanism is not convergence. It is hope with a technical word attached.
Why it matters: It permits a system to be temporarily wrong and still be correctly designed. That is a stronger position than it sounds: it makes recovery a first-class part of the model instead of an operational afterthought.
What would show it wrong: A pattern in which convergence mechanisms cannot be specified without reintroducing a completeness assumption through the back door.

Argued in 1 published item

P3 is listed last because it is the response to P4 rather than an independent position. Read in order, the four say: here is what the objects are, here is the limit on what you can know about them, and here is what follows.

The commitments

Six constraints on our own work. Each states what breaking it looks like and what we do about it, so that you can tell and so that telling has a consequence.

How they relate. W1 is the root: it says where authority lies when a model and its implementation disagree. W2 and W3 are its tests. W2 asks whether the model yields one answer; W3 asks whether the model contains enough to yield any answer at all. W3 is the stronger of the two and implies it, because if two readers predict different behaviour then reconstructability has already failed. We keep W2 separately because it is the cheaper test to run. W4 governs what the model does not cover, W5 bounds how widely we claim it applies, and W6 governs the record of both.

The model is normative, the tool is derived

A model and its implementation are one artefact expressed twice. Where they disagree, the model is correct and the tool is defective.

What it forbids: Any rule that exists only in code. Any configuration setting the model does not define. Fixing behaviour in the implementation and leaving the specification unchanged.
How you can check: Every executable artefact we publish carries a clause-level mapping from each implemented rule to a named model clause. A rule with no clause is a defect we are obliged to report, not an optimisation.
If we break it: The tool is withdrawn, the model is corrected and published, and the tool is reissued. We do not document an exception.

Enforced by invariants I1 and I2, and by validation level L14

Determinism over judgement

Two competent practitioners applying the same model to the same inputs reach the same structural decision.

What it forbids: Thresholds expressed as “reasonable”, “appropriate” or “too long”. Rules that resolve to operator interpretation. Edge cases delegated to a support team, which is failure deferral rather than failure handling.
How you can check: Take any published model, hand it to two people, and compare what they build. Divergence is our defect, not their mistake.
If we break it: The ambiguity is resolved in the model, not in accompanying guidance. Guidance explaining what a specification meant is an admission that the specification failed.

Enforced by validation level L5

Reconstructability

A reader holding only the published model, with no access to the implementation and no access to us, can predict how the system behaves.

What it forbids: Knowledge that lives only in the author's head, in a conversation, or in the code. Specifications that are readable but not sufficient.
How you can check: This is the one to test if you only test one. Read a specification, predict the behaviour on a case it does not mention, then check against the implementation. If you cannot form the prediction, the specification has failed regardless of how well it reads.
If we break it: The release is held. A specification a reader cannot reconstruct is revised before anything derived from it ships.

Tested at every release gate, the single criterion that most directly checks W1

Name what is undefined

Where a model does not yet specify how to behave, we say so, in that place, as a named condition.

What it forbids: Appearing complete by omitting the difficult conditions. It also forbids the subtler version: a tool that quietly decides something its model leaves undefined. We do not build those, whether or not the decision they make is accurate.
How you can check: Every substantial document we publish carries an open conditions section. A document of ours with no open conditions is either finished or dishonest, and very little is finished.
If we break it: The deciding behaviour is removed, or the decision is defined in the model. There is no third option, and accuracy is not a defence.

Enforced by invariant I5 and by the unresolved tension rules in the validation standard

A method is not a method until it transfers

Work demonstrated in one domain is a solution. It becomes a method when it has been shown to work in a second.

What it forbids: Describing our output as general before the evidence exists. Our initial domain is consumer lending and collections, and until the second-domain work is done, the honest word for what we have is a solution.
How you can check: Watch the language. If we start saying method before we have published the transfer evidence, we have broken this.
If we break it: The language is corrected everywhere already published, not only going forward.

Enforced by invariant I4 and tested by falsifier F1

Publish what fails

Negative findings are recorded with the same weight as positive ones, and the conditions under which our own positions would be abandoned are stated in advance.

What it forbids: A research record that contains only what worked. Claims of impact where no external party has used or checked the work.
How you can check: Four falsifiers are defined in the strategic plan, each with a response that is a genuine change of direction. Their status is reported at every annual review, including where the answer is not yet testable.
If we break it: The finding is published late rather than not at all, and the delay is recorded alongside it.

Falsifiers F1 to F4, reviewed annually

Why you should be able to trust these

Not because we hold them sincerely. Sincerity is not checkable. Three properties are, and you can apply all three to anything on this page.

Each one forbids something specific. You can point at a system, a document or a sentence and say that it violates P4 or W2. A principle you cannot violate is not constraining anybody.
Each one can fail. The claims state what would show them to be wrong, and we have committed in advance to what we would do about it. The commitments state what breaking them looks like.
Each one is enforced somewhere nameable. Every entry ends with where it lives: an invariant, a validation level, a review. A principle with no enforcement point is a preference, and preferences belong on a wall, not in a standard.

And the fourth, which is not in our favour. None of these checks has yet been run by anyone outside. Recorded independent use of our work stands at zero. The tests above are available to you and nobody has taken them up, so what we are offering at this stage is checkability rather than a record of having been checked. That number is reported at every annual review, and it is the one to watch.

The strongest thing we can offer is not that we believe these. It is that we have made it possible for you to catch us not keeping to them.

Where these principles do not apply

They are claims about a class of system, not about software generally. Applying them outside that class produces overhead with no return.

Systems where the event sequence is the record by legal or regulatory definition, so that the log is the truth rather than evidence of it.
Systems with very little state, where the model is a schema and a state machine would be ceremony.
Domains where the observed and the true genuinely do coincide, and there is no gap to model.
Work whose value is speed of iteration over a short life, where the cost of derivation integrity is not recovered before the system is replaced.

P4 is the fastest way to tell. If you cannot name a way in which your inputs are incomplete, late or contradictory, these principles are probably not for the problem in front of you.

How this document changes

A claim is retired when it is falsified. The retirement is published with the evidence that falsified it and with a note of what replaced it. A claim quietly dropped between versions would break W6 in the act of maintaining the document.

A commitment is removed only by explicit decision at an annual review, recorded with the reason. It is never allowed to lapse through disuse.

A new entry requires the same structure as the existing ones: something it forbids, a condition under which it fails or is broken, and a named enforcement point. An entry that cannot supply all three is not admitted, however agreeable it sounds. Identifiers are permanent and are never reused.

What we have not yet defended

P4 is assumed throughout and argued nowhere. It is relied on by the computation work and by the whole treatment of failure, but no publication defends it directly. A principle the body of work leans on without defending is the weakest point in the foundation, and naming it here is W4 applied to this page.

A candidate title, Obligation Observability, is held in the publication reserve and is proposed for admission at the next review.

Two further open positions. The claim that each layer of the Knowledge Map can be expressed in the vocabulary of the layer beneath it has not been tested above the obligation layer. And the transfer evidence for W5 does not yet exist, which is why nothing on this site calls the work a method.

Complex systems, made legible.

Where this fits

The principles are the shortest complete answer to what we hold. The Knowledge Map shows how they fit into the layers above them, and the governing standard shows how they're enforced day to day.

Read the Knowledge Map Read the governing standard