WORK IN PROGRESSDraft docs — content and examples are still being refined.
Information model

Scenarios & changes

An application never edits the customer's current picture. It proposes a future — a set of changes grouped into a scenario — and the engine evaluates that future against today's state. This is how one data model holds both 'what is' and 'what if'.

The core idea

State + Scenario = a potential future

Three moving parts. Keep them straight and the whole change model falls into place.

01

State is the present

The root arrays — assets, financing, incomes, collateralAgreements — describe what the customer owns, owes and earns today. Nothing here is hypothetical.

02

Changes are deltas

A Change in state.changes[] is one edit on top of the present. CREATE_ELEMENT introduces something new; every other kind modifies or removes an existing element and points at it with basicChangeInformation.parentId.

03

A Scenario groups them

A Scenario is a named future: it lists the changes[] that belong together, plus the decisions[] and affordability analysis computed for that combination. State + scenario = a potential future.

One subtlety worth internalising: a scenario references change ids in its changes[] list, while the entities inside those changes reference entityids (a deed’s collateralCoverages[].idis a loan’s id). That two-level indirection — scenario → change → element, and element → element — is exactly what the JSON lens in the worked examples lets you trace.

Reference

Every change kind, and what it is for

Every change carries its own id in basicChangeInformation.basicEntityInformation. The difference is parentId: CREATE_ELEMENT adds a new element and has none, while every other kind modifies or removes an existing element and points at it through basicChangeInformation.parentId. List-valued changes mark each entry with a changeStatus of NEW or DELETED.

All 47 change kinds from the standard-model changesBase discriminator. Every change also inherits dataversion. List entries carry a changeStatus of NEW, CHANGED, UNCHANGED or DELETED.
Worked examples

Watch a scenario assemble around a real customer

Frida & Nils are buying their first home

Two applicants, no property yet. Almost nothing sits on root state — everything that matters is the purchase they are applying for, expressed as one scenario built from CREATE_ELEMENT changes. This mirrors the real Swedish purchase flow: a home, a new mortgage, and the deed + object that pledge the home to the loan.

ENTITY FAMILIES
PeopleAssetFinancingCollateralIncome / ExpenseScenario
TODAY VS IF-APPROVED
Today — on a root arrayProposed — changes[] · CREATE_ELEMENTRedeemed / removed
LINKS
Line — an id reference, labelled with its fieldF · DEBTORChip — a Role { partyId, role, share }
STEP 1 / 4Today the couple is just rows on root state: two Party records and the Case with its shared household (PARTNER). Everything they are applying for lives in the scenario, not here.
ON STATE — TODAYroot arrays · already true
mainCustomer
member
Frida Berg
partyKind: INDIVIDUAL_PERSON
idparty-frida
state.parties[]
Nils Berg
partyKind: INDIVIDUAL_PERSON
idparty-nils
state.parties[]
Case + Household
members→ frida · nils
relationshipPARTNER
state.case

Step through the story with NEXT, or jump with SHOW ALL. Hover a person (or a role chip) to draw the ties from them to every entity they hold a role in; hover any other card to light up its id references. Switch to PAYLOAD to watch the same story assemble as JSON.