Answers to common questions

SiP is a research-led technology initiative for complex systems. It studies how systems like lending and collections can be modelled, represented, and tested, then publishes the models and the specifications derived from them.

The governing rule is derivation integrity: a model is published first, an implementation is derived from it, and the derivation can be inspected by someone who has seen neither the code nor the author.

Practitioners who build and operate lending, collections, and other financial systems: engineers, architects, product managers, analysts, and operators responsible for outcomes.

It’s also for anyone assessing whether the underlying research holds up, since the falsifiers and open conditions are published alongside the claims.

Start with Specifications if you have a concrete problem: it’s the searchable set of formal specifications for lending and collections systems, stated as rules rather than guidance.

Start with the Knowledge Map if you want the intellectual structure first: the principles, models, and research questions everything else derives from.

Start with the Mission if you want why the work exists before either of those.

Mission explains why the work exists. Core Principles states the invariants as commitments you can check yourself. The governing standard (Our Approach) is the longer version: the governing rule, how we work, and what would prove the whole thesis wrong.

The Strategic Plan sits alongside these; it’s what changes at each annual review rather than what holds between them.

A specification states a rule for how a system should behave: a state model, an obligation, a decision, or a convergence mechanism, rather than a suggestion or a case study. Each one traces back to a named clause in the Knowledge Map.

Locked specifications are visible as part of the pipeline but not yet ready for public reading: incomplete derivations, project-specific detail still being generalised, or de-identification still in progress.

Locked is a maturity signal, not a pricing signal. When a specification is ready, it’s unlocked for everyone.

Featured specifications are curated for quick orientation: broadly reusable rules worth reading first if you don’t yet know what you’re looking for.

Tags are the handles for recurring concerns: domain, failure mode, and technique. They let you cut across specifications when a problem spans state, obligations, and decisions at once.

Yes. A specification changes when its underlying model changes, correction flows model first: a defect found in an implementation is fixed in the model, and the specification follows.

The intellectual structure behind everything else on the site: eight layers, from foundational principles through to canonical works, that every specification and topic derives from.

Foundational principles, formal models, computational models, obligation systems, decision systems, enterprise systems, research streams, and canonical works, in that order of dependency.

No. Most current published work sits in the obligation-systems layer, since financial obligations are the initial proving ground. The map states where coverage is thin rather than implying even progress across all eight.

No. A specification states a rule and what would falsify it, not an aspiration. Where something is context-dependent or not yet argued directly, the specification says so.

No. SiP publishes systems and modelling research. Treat it as practitioner-grade specification, then validate against your own legal, compliance, risk, and policy context.

Four falsifiers are published on Our Approach, each with a genuine change of direction if triggered rather than a restatement. For example, if the specification format produces implementer disagreement across three published specifications, new specifications halt until the format is revised.

Specifications are written to be reusable and de-identified. If one can’t be safely generalised yet, it stays locked until it can be.

The plan for 2026 to 2028: the mission, the governing rule, the organisational invariants, the falsifiers, and the strategic objectives, the parts that hold between annual reviews.

The Strategic Plan page holds what changes only at annual review. The full plan document adds the roadmap, the capacity model, the risk register, and everything else that moves on a different cycle.

The core plan is stable between annual reviews. The full plan’s roadmap and operating detail move more often, on their own cycle, without touching the invariants or falsifiers underneath them.

You can contribute by sharing incidents, reviewing draft specifications, or flagging where a published rule doesn’t hold in your own systems.

The goal is to raise the floor for operational reliability and correctness.

Collaboration can include sanity-checking specifications, discussing failure modes, or building tools and prototypes derived from the published models.

Yes. Typical engagements include workflow reviews, diagnosing bottlenecks, sense-checking changes before launch, and supporting decision-making in high-impact areas.

Bring the workflow you’re worried about, current observability signals, known failure modes, constraints (policy, compliance, tooling), and what "better" means for you.

Search Specifications for the failure mode or state you’re seeing. Related rules, obligations, and decision logic surface together under the same tags, rather than split across separate sections.

Start with the obligation-systems and decision-systems layers on the Knowledge Map for the underlying model, then search Specifications for the concrete rules that apply to the workflow you’re changing.

Point to the specification itself: it states the rule, what it rules out, and what would prove it wrong, which is usually a stronger basis for an internal argument than a general framework.