JIM connects systems through a central identity hub rather than wiring them together directly. That one decision is what makes synchronisation auditable, consistent, and explainable, and it's what separates JIM from a pile of point-to-point scripts.
The naive way to keep many systems in sync is to connect each one to every other: a web of point-to-point integrations that grows quadratically and that nobody fully understands. Add a system and you add a connection to every existing one. Change a rule and you change it in a dozen places. When a value looks wrong, there is no single place to ask why.
JIM takes the opposite approach. Every Connected System links to one central hub (the Metaverse) and never directly to another system. Identity data flows in from each source, fuses into a single canonical record, and flows back out to the systems that need it. The number of integrations grows linearly, not quadratically, and there is exactly one place where identity is reconciled.
That central point is what buys you auditability, consistency, and causality. Because every value passes through the Metaverse, JIM can record where each attribute came from, which rule applied it, and what it changed, for every identity, end to end. The same single point works forwards as well as backwards: before you save a configuration change, JIM can evaluate it against every identity and show you what it would do.
Any system JIM talks to: an HR platform, a directory, an application, a file. You configure each one once, how to connect, what schema to read, and which objects to bring in. Everything JIM knows about the outside world enters through a Connected System.
A single object (a user, a group) exactly as it exists in one Connected System. A person with accounts in five systems has five CSOs. Each one is a faithful, unmodified picture of that system's view, captured before any reconciliation.
The single, canonical identity JIM assembles by fusing the CSOs that match. One person, one MVO, regardless of how many systems describe them. The MVO holds the agreed value for every attribute, decided by deterministic Attribute Priority across its contributing systems. Its shape is yours: the Metaverse Object Types and Metaverse Attributes are ones you define, not a fixed vendor model.
Every change moves through the same three-stage pipeline: the same cycle whether JIM runs nightly or near-real-time, and whether it's one system or fifty.
JIM reads objects from each Connected System into staging as CSOs: the system's own view, captured faithfully. Imports can be full or delta, so large estates only move what changed.
Object Matching Rules join each CSO to the right Metaverse Object, and inbound flow rules project attribute values onto it under deterministic Attribute Priority. This is where many systems' views become one canonical identity.
Outbound flow rules push the Metaverse's canonical state back out to the systems that need it, creating, updating, and removing accounts, memberships, and entitlements so every target converges on the agreed truth.
Everything above describes a single organisation-wide deployment. But the hub-and-spoke pattern isn't tied to scale: the same engine runs as one central fabric, or as many small, focused instances, each a complete Metaverse in its own right.
One JIM instance acts as the organisation's identity fabric, with every major system connected to a single Metaverse. This is the deployment shown above: the central hub that governs identity across the whole estate.
Many lightweight instances each solve one bounded problem (a subsidiary directory, an application feed, a regulated population) and nothing else. Each is a small Metaverse, deployed in minutes via Identity as Code and managed independently.
Point-to-point sync scripts are cheap to start and impossible to maintain. The Metaverse pattern is the harder thing to build, and the reason JIM stays auditable as the estate grows. Stand up an instance and see it work.
