Worlds
What you build with OiC.OS is not a configuration of an accounting package. It is a world: the agents that act, the kinds of money they hold, the contracts between them, and the sectors they belong to. A currency system, a company group, an industry, an association with internal clearing — these are all worlds, and they are built from the same parts.
Reference economics content ships as kernels — einbank, zweibank / dreibank, liquipool, supplychain, plus governance variants such as Islamic Banking — packaged in oicos.world contexts for teaching and delivery. See Modeling Service and Help — Worlds.
The same construction at every scale
An association that settles member contributions internally and a central bank that settles with commercial banks look like different subjects to an economist. In OiC.OS they are one construction with different parameters: agents holding claims on each other, a settlement layer above them, rules that say who may issue what. That is the compositional claim of the Magic Sauce turned into something you can actually build — one bank, three banks, a supply chain sharing a facility (LiquiPool), profit-and-loss sharing instead of interest (Islamic Banking). Only the scale and the parameters change, never the principle.
The books follow the model, not the other way round
In a conventional system somebody sits down and configures a chart of accounts, and the model of the business lives in a slide deck next to it. Here the direction is reversed. The model states which agents exist, which kinds of money circulate, and which contracts bind them; the accounts, the postings and the reports are derived from it. There is no second place where the same organisation is described again in a different language, and therefore no drift between the description and the books.
This is why a world is not delivered as a fixed template. Two customers who model different economies get different structures, generated from their own models when their environment is set up.
Pieces snap together only when they fit
You assemble a world by placing pieces and connecting them. Each piece exposes its interfaces — its ports — and each port carries a type: what flows through it, in which direction, in what unit. When you drag two pieces together, the connection is made only if the types on both sides agree. Where they do not agree, the pieces repel each other, like magnets held the wrong way round.
That behaviour is not a convenience feature of the interface. It is a type checker at work, the same discipline that keeps a compiled program from being assembled out of incompatible parts, applied to the assembly of an organisation. The consequence is that a world which can be built at all is a world whose parts agree at their boundaries — which is exactly the glueing condition described in the Magic Sauce.
Governance, decisions, accounting — three views of one world
Once a world exists, it can be looked at in three ways at once: the rules and rights that govern it (GovCat), the agents deciding within it (DecCat), and the books that record what happened (AccCat). The workbench shows all three, in a flat 2D view for working on a single institution and a 3D view for the layered whole, with the simulation trace running underneath.
Where this stands
The modelling language, the three views and the simulation run today in the workbench. Deriving a complete everyday business surface from a world — so that a customer's staff work in ordinary screens rather than in the modelling tool — is the step we are building now; it is described under Engagement. Packaging a piece of a world so that somebody else can buy it and glue it into their own is described under Org Shop.