Strategic Plan
2026 to 2028

1Executive overview

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. Its 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.

The strategic opportunity is not to produce more software. It is to establish a discipline in which 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. We call this derivation integrity. It is the distinguishing claim of the body of work and the organising principle of this plan.

Over the 2026 to 2028 period Systems In Practice will move from a research and development activity into a research, engineering and publishing organisation of deliberately modest size. Five objectives carry the plan: foundational research, derived computational architecture, applied validation, publication and knowledge transfer, and capacity with sustainability.

The initial applied domain is financial systems, specifically obligation and repayment architectures, state consistency, and computation under incomplete transaction observability. That domain is a proving ground, not the destination. A method demonstrated in one domain is a solution. The plan therefore commits to a second domain before it permits us to describe our output as a method.

Strategic outcomes by August 2028

Accountability

Each objective carries a single accountable role. These are responsibilities rather than departments, and where one person holds several, the roles remain separately documented, because the conflict between them is real even when the person is one.

2The governing standard

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.

What the governing rule binds

Correction flows model first. A defect found during execution is corrected in the model, and the tool follows. Fixing behaviour in code and leaving the model unchanged severs the derivation and is a conformance failure, not a shortcut.

Publication order. A model is published before, or with, any tool derived from it. Tools are never published ahead of their models.

Domain breadth. The method is demonstrated across more than one domain. A body of work confined to a single domain has demonstrated a solution, not a method.

3Organisational invariants

Conditions that must remain true regardless of circumstance, each with the response required when it is breached. An invariant with no breach response is a preference.

The floors referenced in I6 and I7 are parameters, not judgements. They are set once, during the baseline assessment, and thereafter changed only by explicit decision at an annual review. Section 9 defines how they are set.

4Thesis, and what would falsify it

Our thesis is that model-normative development, applied under a strict validation standard, produces systems whose behaviour is reconstructable and whose correctness is demonstrable, and that this discipline transfers across domains.

A thesis that cannot fail is not a research position. Four falsifiers are defined. Each has a response that is a genuine change of direction, not a restatement.

Recording that a falsifier was tested and not triggered is itself a research output. Recording that one was triggered, and acting on it, is a stronger one.

5Definitions: units of output

A plan that counts its outputs must first define them, and must define how the counted units relate to one another.

Relationship between the units. Specification and publication are different properties of a document, not different documents. A publication is any validated item released from the Publication Programme; it may present a specification, a case study, a synthesis, or expository work that supports one of those. A specification is the subset of that output which defines a bounded system in full and therefore passes L1 to L13. The Objective 1 target of eight specifications is a quality floor within the Objective 4 target of twenty one published items, not an additional workload alongside it.

The three executable classes are as defined in the Unified Validation Reference. An Executor implements a published model faithfully. An Instrument measures without deciding. A Validator checks an artefact against a model's invariants. Anything that decides what the model leaves undefined is a substitute, and is prohibited under I5.

6Strategic context and the honest baseline

The problem

Complex systems are built from domain requirements, software components, operational rules and external integrations. Each component can be locally correct while the system as a whole develops inconsistencies in how states, transitions, obligations and dependencies are interpreted.

A financial obligation may be represented differently by a repayment scheduler, an accounting component and a servicing integration. If each independently defines what an outstanding balance means, the system produces contradictory results while every component appears to function. The research problem is to establish shared semantics and computational structures that prevent divergence, and to make the absence of divergence demonstrable rather than assumed.

The problem is not confined to finance. It appears in distributed systems, workflow engines, infrastructure management and health information systems.

What is established, and what is not

This plan is published with its unknowns intact. A body of work whose central claim is that difficult conditions should be named rather than omitted cannot present its own position as more settled than it is.

Established. A substantial body of conceptual work exists, organised across the Knowledge Map, the Series Catalogue and a seven-phase Publication Programme. A validation standard exists at version 3.1, including levels L14 and L15 governing executable artefacts. Domain depth exists in obligation and repayment systems and in state consistency under incomplete observability.

To be established by 31 December 2026. Capacity and available hours; legal structure; committed income; the condition of existing technical assets; active partnership terms; the intellectual property position on prior work; and the defect and rework baseline against which F3 will be measured.

The baseline assessment is a dated deliverable of Phase 1, not an assumption the plan may keep deferring. Every parameter marked as set at baseline in this document is listed in its output.

Opportunities

Demand for explainable and auditable computational decisions is rising, driven partly by regulation and partly by the growth of AI-assisted development, which increases the volume of code whose provenance is unclear. A discipline that makes derivation inspectable is better positioned as that volume grows, not worse.

Our differentiator is the relationship between meaning and implementation, not feature count. Our strongest immediate advantage is access to genuinely demanding financial problems as a proving ground.

Constraints

The binding constraint is capacity, and it is small. Every other constraint is downstream of it: the cost of infrastructure, the difficulty of cross-domain validation, and the risk of portfolio expansion before the architecture is mature.

There is a second constraint specific to us. The validation standard is strict by design. Applied faithfully, it will reject or hold work that a less disciplined organisation would publish. That is the intended effect, but it caps throughput. The plan therefore states a realistic publication rate rather than one borrowed from organisations that publish without a gate. Section 10 does this.

7True north and success criteria

To establish and demonstrate a repeatable approach for translating complex system models into computational implementations that preserve defined meaning, invariants and state consistency as systems evolve, and to make that preservation demonstrable to a reader who has seen only the model.

Each project need not use the same technology or domain model. Each must contribute to the shared body of knowledge. A model or implementation demonstrates the following, and each is testable rather than aspirational.

The final row is the operational form of the governing rule and the primary criterion by which L14 is judged. These criteria are converted into the standard specification template during Phase 2.

8Strategic objectives

Objective 1: Advance foundational systems research

Purpose. To develop a coherent body of research defining how complex systems are modelled, how states and transitions are represented, and how the correctness and applicability of those models are evaluated.

1.1 Establish the formal modelling framework. A shared conceptual framework covering boundaries, entities, state variables, transitions, dependencies, invariants, observations, and the relationship between conceptual and computational representation. Priorities: a terminology document with one definition per term and no synonyms; a standard specification format; criteria for identifying relevant states; methods for representing transitions and constraints; treatment of incomplete, delayed and conflicting observation; a versioning and review process for definitions.

1.2 Research state consistency and invariants. How a system preserves defined conditions across transitions, including under asynchrony and missing history. What constitutes authoritative state; how derived state is distinguished from observed state; which invariants must hold; how divergence between component representations is detected; under what conditions differing observations converge.

1.3 Maintain the research evidence repository. Research questions, hypotheses, model versions, experiments, results, negative findings and decisions, with each substantial claim linked to its supporting evidence and assumptions. Negative findings are recorded with the same weight as positive ones, because F1 to F4 cannot be evaluated without them.

The negative findings indicator is deliberate. A research programme reporting no failed hypotheses over two years is not reporting.

Objective 2: Build derived computational architecture

Purpose. To translate research into a technical foundation reusable across applications, in which no component may redefine the underlying model.

2.1 Canonical model and representation layer. Shared concepts represented through explicit contracts rather than duplicated across components. Domain semantics separated from storage, interface, integration and infrastructure. Initial work: canonical state representation, transition contracts, invariant validation mechanisms, model versioning, and interfaces for component-specific projections.

2.2 Reference implementation and conformance suite. The reference implementation demonstrates the principles in software. It is not a universal platform and will not be positioned as a product. The conformance suite is generated from the invariant set rather than written alongside it, which is the practical expression of L15: each invariant becomes an assertion, each edge case a fixture with a determinate expected outcome, each infeasible configuration a startup check.

2.3 Derivation integrity in practice. Every executable artefact carries a clause-level mapping table linking each implemented rule to a named model clause, and each exposed configuration value to a model parameter. An implementation exposing a setting the model does not define has reintroduced operator judgement below the level of the model. That is a determinism failure expressed in a different medium, and it is treated as one.

2.4 Architectural governance. Material decisions recorded as Architecture Decision Records. Changes to shared model semantics require review of the effect on existing components, tests and research assumptions, and are made in the model before the code.

The reconstructability test is the one that matters. It is the only indicator that directly tests the governing rule, and a failure on it is a strategic failure rather than an engineering defect.

Objective 3: Validate through applied systems

Purpose. To demonstrate that the models solve consequential problems, and to identify the conditions under which they are insufficient.

3.1 Financial systems as the initial testbed. Deterministic obligation construction, repayment schedules, state transitions, reconciliation, and convergence under incomplete transaction observability. Work is structured so that findings are separable from the particular product in which they arise.

3.2 Standard case study method. Each case study documents problem, boundary, assumptions, baseline, model, implementation, evaluation criteria, results, limitations and lessons. It distinguishes a model that works in a controlled example from one validated under operational conditions, and it records unsuccessful approaches.

3.3 Second domain. During year two we assess one additional domain for transferability. Candidates: workflow systems, distributed state management, infrastructure operations. Selection depends on partner access, research relevance, data availability and evaluability. We will not build a second full product before the research case is established. This work is the test for F1. It is not optional and cannot be deferred into the following cycle without breaching I4.

Objective 4: Publish and transfer knowledge

Purpose. To move the body of work into use, and to expose it to criticism that internal review cannot provide.

4.1 Execute the Publication Programme. A sequenced seven-phase programme and Series Catalogue already exist. Section 10 states the committed sequence and rate.

4.2 Targeted partnerships. Universities, independent researchers, financial technology organisations and enterprise practitioners whose problems align with the agenda. Partnerships are assessed on research relevance, access to real problems, mutual contribution, intellectual property terms and transferability of the resulting knowledge.

4.3 External identity grounded in artefacts. Communications describe specific problems and published artefacts. Claims about impact are made only where an external party has used or validated the work.

Independent use is the F4 indicator. A reading of zero at the August 2027 review brings the F4 response forward by one cycle under the early-warning rule. The falsifier itself is tested at August 2028.

Objective 5: Build capacity, governance and sustainability

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

5.1 Operating structure. Four functions: Research, Engineering, Applied Programmes, and Operations and Partnerships. These are responsibilities, not departments. Where one person holds several, the allocation is documented so that decision authority remains unambiguous.

5.2 Research and technical governance. A research review process, architectural review, documented contribution standards and named ownership of shared models. Research findings and implementation decisions affecting the same concepts are reviewed together.

5.3 Capability and continuity. Priority capabilities: systems research, formal methods, software architecture, domain modelling and technical writing. Recruitment is phased against funding. Continuity is addressed through documentation and review rather than through headcount we do not have. Key person risk is not mitigated by a talent pipeline that does not yet exist; it is mitigated by making the work reconstructable, which is the same property the governing rule requires.

5.4 Infrastructure. Version control, automated testing, access management, backups, documentation and security controls. Partner and financial data handled under documented access, retention and privacy requirements.

5.5 Diversified funding. Research grants, philanthropic support, strategic partnerships, commissioned research, consulting, and mission-aligned licensing or service revenue. The mix depends on legal structure, eligibility and maturity. Funding that supports foundational research is accounted separately from revenue generated by applied services.

5.6 Financial governance. Cost baseline, annual budget, cash flow forecast, approval controls and reporting in year one. A reserve policy appropriate to the legal structure, with a stated target level of unrestricted reserves.

5.7 Institutional form. A decision on the structure for research and commercial activity, covering governance, intellectual property ownership, publication policy and the relationship between research and delivery. No structure is assumed. Recommendation by June 2027, decision by December 2027.

5.8 Mission protection. Funded work is accepted only where it advances the research agenda, produces applied evidence, generates sustainable resources or builds strategic capability. Work failing all four is declined. I6 makes this enforceable rather than advisory.

9The capacity model

Capacity is the binding constraint, and this plan measures it directly rather than dividing an unmeasured base into shares. A percentage split of an unknown total carries no information and cannot be breached, which means over-commitment cannot be detected.

1. At baseline, record total available capacity in person-days per week, by named person, distinguishing committed delivery time from discretionary time. This is the single most important number in the plan.
2. Set the protected research floor referenced in I6 as an absolute quantity of person-days per week, not a percentage. A floor expressed as a percentage falls as total capacity falls, which is precisely when protection is needed.
3. Set the funder concentration limit referenced in I7 as a percentage of annual income, with a stated figure.
4. Define the minimum viable week: the smallest set of activities that must occur every week for the plan to remain live. Proposed: one specification advanced, one conformance check run, one publication item progressed. If a week passes without it, that is recorded. Three consecutive misses trigger a scope review, not an apology.
5. Express the indicative allocation as ratios against measured capacity, reviewed quarterly.

The shares are indicative. The floor is binding. Where they conflict, the floor wins.

10Publication throughput and programme alignment

The Publication Programme defines seven phases. The Series Catalogue defines three series and a highest-value publication sequence. The Knowledge Map defines eight layers. This section commits to a rate consistent with all three and with the capacity constraint above.

Throughput and the gate. Each item passes validation before release. The standard rejects work that a less disciplined process would publish, so the rate above assumes a rejection and rework allowance. The planning assumption is that roughly one item in four requires a revision cycle before it clears. If the observed rejection rate exceeds one in two over any quarter, the constraint is the drafting process rather than the standard, and the response is to revise the drafting template rather than to relax the gate. Relaxing the gate breaches I3.

Canonical works. The four canonical works in Knowledge Map Layer 8 are syntheses. Under invariant PI4 of the Publication Programme, none may be drafted until every input item is published, and the input sets for all four include items in Phases 6 and 7. No canonical work is therefore drafted within this plan period. What this period delivers is the input set: by August 2028 the items on which K1 and K2 depend are largely published, and the two syntheses become writable in the next cycle. Publishing a synthesis before its inputs would invert the derivation the whole standard is built on, and committing to draft one early would do the same by a slower route.

11Theory of change

The feedback loop is the mechanism, not an exception to it. Applied failure reveals weakness in the model. New research changes the implementation. Correction always flows model first.

12Readiness stages

A staged assessment determines when an idea, model or opportunity justifies further investment.

At each stage the decision is advance, refine, pause or discontinue. Discontinue is a legitimate and expected outcome, and the reason is recorded.

13Two-year roadmap

September 2026 is the operational start. Each gate carries a pass condition, a hold condition and a stop condition, so that a gate can halt work rather than only pose a question.

Phase 1: Establish the foundation, September to December 2026

Phase 2: Consolidate research and architecture, January to June 2027

Phase 3: Validate and extend, July to December 2027

Phase 4: Demonstrate transferability, January to June 2028

Phase 5: Institutionalise and plan the next cycle, July to August 2028

Complete the two-year evaluation, publish the impact and learning report, record which falsifiers were tested and with what result, update the research roadmap, and approve the next cycle. The review determines which research streams continue, which technical assets require long-term stewardship, and which applied opportunities justify further investment.

14Operating model and decision rules

Quarterly cycles. Each quarter identifies a limited number of priorities with named owners, dependencies and the evidence required for completion. A well-designed experiment that establishes a limitation is a successful outcome and is recorded as one.

Decision rules for new work

1. Does it address a consequential systems problem within the agenda?
2. Will it produce transferable knowledge, reusable architecture or applied evidence?
3. Are we positioned and resourced to do it, measured against capacity rather than estimated?
4. Are assumptions, risks and evaluation criteria defined before work starts?
5. Can it be sustained without breaching I6?
6. Does it create architectural or institutional dependencies disproportionate to its value?

A no to question 3 or 5 is decisive. The others are weighed.

Governance

The Research Lead owns the coherence of the research agenda. Technical leadership owns architectural integrity and derivation discipline. Programme owners own applied delivery and evaluation. Organisational leadership owns finance, partnerships, risk and alignment.

15Evaluation, learning and accountability

Learning cycle. Research and engineering conduct a joint synthesis review each quarter, identifying findings that require changes to models, architecture, priorities or assumptions. Decisions are recorded, including why evidence was accepted, rejected or judged insufficient. The status of F1 to F4 is reviewed at each annual review and reported explicitly, including where the answer is not yet testable.

16Financial strategy

The figures in this plan are planning parameters, not statements of current position. They become commitments once the baseline assessment sets them.

Priorities. Balance foundational research funding against applied revenue and partnerships, avoiding a position in which delivery obligations consume all capacity. I6 is the enforcement mechanism.

Sustainability goals by August 2028. An approved multi-year budget, a diversified funding pipeline, documented financial controls, a reserve policy, and a known full cost of maintaining core research and technical infrastructure. Revenue-generating activity is priced for full cost recovery, including research supervision, technical maintenance, administration and long-term support.

Scenarios. Three are maintained: constrained, preserving essential research and infrastructure only; baseline, supporting the approved roadmap; growth, enabling additional capacity and applied programmes. Expansion occurs only when both funding and operational capacity support it. The constrained scenario is written first, because it is the one most likely to be needed.

17Risk register

The register is reviewed quarterly and whenever a new project, partnership or technical dependency is introduced.

18Strategic scorecard

The indicators measure progress, not output volume. A smaller number of rigorous, reusable contributions is worth more than a larger number of disconnected ones.

19Open conditions

Conditions within this plan's scope for which behaviour is not yet defined, or for which behaviour is defined but the judgement behind it has not been made. Publishing them is the same discipline the standard requires of every artefact: a document that appears complete because the difficult conditions were omitted is worth less than one that names them.

20Looking ahead

By August 2028 we should be able to demonstrate a progression from foundational research to validated computational practice. The value of the work will rest on the ability to define hard systems problems precisely, model them coherently, derive dependable implementations from those models, and produce evidence about where the approach works and where it stops.

The next cycle depends on what the research establishes and on which falsifiers were triggered. We may deepen the financial systems work, expand into further domains, mature the reusable platform, or establish institutional research partnerships. Those decisions will follow the evidence.