How it fits together: three loops

The platform is not a list of modules and it is not one loop. It is three loops that answer three different questions, a gate between two of them, and one inbox where any of them asks a person for a decision.

Loop	The question it answers	Its work
Data	Is what we know good enough to act on?	Observe, interpret, own, find the gaps, fix, observe again
Model	What exists to be governed, and does it still deserve to?	Propose, shape, formalise, retire
Access	Who should have what, and does it still hold?	Intent, compare, act, attest

1. Connecting a system happens once. From then on the data loop runs: observe what is there, interpret it, find who owns it, and turn the gaps into work.
2. The access loop works out who should have what, compares it with reality, acts, and asks people to confirm. The gate between the loops decides what it may claim: what was never observed is not a finding.
3. The model loop decides what exists to be governed: roles, applications and entitlements are proposed, shaped, formalised and eventually retired. It reads the data loop and gives the access loop the catalogue it reasons in.
4. Whatever needs a person, from either loop, arrives in one inbox: an unowned account, an approval, a certification, drift. The decision goes back into the loop it came from.

The data and access loops run on machine time: syncs and reconciliation runs. The model loop runs at human pace: a role is proposed, discussed, and then lives for years.

Before the loops: connect a system

Connecting a system happens once, then the data loop runs for as long as the system is connected. The onboarding wizard first asks what the system is: a source that identities come from, a target that holds accounts, or both. Then it asks how the platform reaches it: directly, or through the tier-3 agent inside the customer's network.

The data loop

• Observe. Sync reads what exists on each system and writes nothing back. Identities come from a source, accounts and their grants from a target. See The data model.
• Interpret. Each account is linked to the identity that owns it and classified by purpose, and each entitlement by the kind of permission it gives. See Account rules.
• Own. Everything that later needs a person resolves through one ownership cascade, which is why a certification cannot invent its own reviewer list. See Ownership and non-human identities.
• Gaps. Unowned objects, unclassified accounts, incomplete HR data and systems that report no activity are findings in their own right. Fixing one changes what is observed, and the loop turns again.

The model loop

This is the catalogue the access loop reasons in: applications, entitlements and roles.

• Propose. Role mining finds a candidate in the access people already hold, or an administrator asks for one. A proposal is never created automatically. See Roles and role mining.
• Shape. The application, entitlement and role wizards decide its name, its owner, its kind of permission, whether it may be requested and who reviews it.
• Formalise. It becomes a real object with an owner. From then on a policy can grant it, a request can ask for it and a certification can confirm it.
• Retire. A deprecation plan moves the holders off and ends it on a date. The object keeps its history.

The access loop

• Intent. Policies, roles, approved requests and lifecycle windows say what should be true, and the status cascade decides what may be true right now. The result is Expected, and every grant in it can say why.
• Compare. Reconciliation compares Expected with Actual per grant and stores the reason at that moment. That snapshot is what makes "who had access on this date, and why" a lookup.
• Act. Every grant and revoke passes the same checks: approvals, safety limits, the state of the system and the tenant. A failure becomes a job with a typed reason rather than a silent error.
• Attest. Certifications ask again, on a schedule or after an event, whether a person still stands behind the access. See Access reviews and approvals.

The gate: the data loop decides what the access loop may claim

When the data loop says	The access loop may not say
No system here reports activity, or none has finished an ingest	that an empty last-used date means "never used"
The ownership cascade resolves to nobody	that the object is covered by a review
There is nothing to divide by	that a compliance control scores a percentage

Each of these started as a defect and is now guarded by a test. Data quality is not an onboarding chore that ends when governance starts; it keeps running, and it can stop a claim.

One inbox

Every decision a loop needs from a person arrives in the same inbox: approvals, certifications, reconciliation drift and the Advisor's findings. The workbenches are for looking; deciding happens in the inbox, and a decision goes back into the loop it came from. Carrying out a decision never needs a second one, so Act never appears there.

The Advisor covers the data and the access loop. The model loop has its own proposals (role proposals, deprecation plans, entitlement onboarding), each with its own approval through the same inbox.

Outside the loops

Just-in-time elevation, break-glass and the emergency lockout do not wait for a loop to come round. They act immediately, for a limited time or until lifted, and they leave the most detailed evidence. See Privileged access.

Related

• The data model: the objects the loops work on.
• The status cascade: how Intent turns sources into Expected.
• What we don't claim: the limits of these claims.