The standard we hold ourselves to

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. This page sets out what that requires of us, and what would prove it wrong.

The governing rule Where should I start?
System architecture visualization

The governing rule

A model and its implementation are not two artefacts. They are one artefact expressed twice. The model is normative. The tool is derived. Where the two disagree, the model is correct and the tool is defective.

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. It is the distinguishing claim of this body of work, and every objective and gate below is written against it.

What the rule binds

  • Correction flows model first. A defect found during execution is corrected in the model, and the tool follows.
  • A model is published before, or with, any tool derived from it. Tools are never published ahead of their models.
  • The method is demonstrated across more than one domain, or it is a solution, not a method.

How we work

Over 2026 to 2028 Systems In Practice moves from a research and development activity into a research, engineering and publishing organisation of deliberately modest size, carried by five objectives.

Objective 1

Foundational research

A coherent body of research defining how complex systems are modelled, how states and transitions are represented, and how the correctness of those models is evaluated.

See where this lives in the map
Objective 2

Derived computational architecture

A technical foundation reusable across applications, in which no component may redefine the underlying model. Every implemented rule traces to a named model clause.

See where this lives in the map
Objective 3

Applied validation

Demonstrating that the models solve consequential problems, using financial systems as the initial testbed and recording where they are insufficient.

See where this lives in the map
Objective 4

Publication and knowledge transfer

Moving the body of work into use, and exposing it to criticism that internal review cannot provide, through a sequenced publication programme.

See where this lives in the map
Objective 5

Capacity and sustainability

Sustaining rigorous research and dependable engineering without dependence on a single project, funder or person.

See how you can support this

Conditions that must remain true

Each carries the response required when it is breached. An invariant with no breach response is only a preference. Six of these, restated as checkable commitments with how you can verify each one yourself, are set out in full in Core Principles.

The two-year roadmap

Five phases from September 2026 to August 2028. Each gate carries a pass condition, a hold condition and a stop condition, so a gate can halt work rather than only pose a question.

Phase 1 Sep – Dec 2026

Establish the foundation

Approve the plan, complete the baseline capacity assessment, fix the research agenda, and begin Publication Programme Phase 1.

Phase 2 Jan – Jun 2027

Consolidate research and architecture

Tag framework v1, complete the first financial case study, and generate the conformance suite from the invariant set.

Phase 3 Jul – Dec 2027

Validate and extend

Complete the second case study, commission the first external review, and decide the institutional form.

Phase 4 Jan – Jun 2028

Demonstrate transferability

Complete the third financial case study and a second-domain proof of concept, the direct test of falsifier F1.

Phase 5 Jul – Aug 2028

Institutionalise and plan the next cycle

Publish the two-year impact and learning report, record which falsifiers were tested, and approve the next cycle.

What would prove us wrong

A thesis that cannot fail is not a research position. Our thesis is that model-normative development, applied under a strict validation standard, produces systems whose behaviour is reconstructable and demonstrably correct, and that this discipline transfers across domains. Four falsifiers are defined, each with a response that is a genuine change of direction, not a restatement.

F1

The framework is domain specific.

Tested when. Tested when, after a second-domain proof of concept, transfer requires redefining core framework terms rather than parameterising existing ones.

If triggered. Stop describing the work as a general method. Reposition as a financial systems discipline.

F2

The specification format is insufficient for determinism.

Tested when. Tested when, across three published specifications, independent implementers diverge on conformance fixtures more than once.

If triggered. Halt new specifications. Revise the specification format before any further publication.

F3

Derivation integrity does not pay for itself.

Tested when. Tested when derivation and conformance work consumes more engineering capacity than agreed, without a measured reduction in defect rate.

If triggered. Reduce mandatory derivation to a defined artefact class rather than all executable output.

F4

The work is not transferable in practice.

Tested when. Tested when no external party adopts, extends, cites or independently validates any published artefact within twenty four months of first publication.

If triggered. Treat as a distribution failure first and a substance failure second. Reallocate toward engagement for one cycle.

Where should I start?

01

See the intellectual structure

The principles, models and research questions that everything else in this body of work depends on.

Read the Knowledge Map
02

See why the work exists

The mission, purpose and vision behind the standard described on this page.

Read the mission
03

See it applied

The topics and working notes where the obligation-systems layer of the model is being worked out in practice.

Explore topics

Complex systems, made legible.