Every quarter, a certification campaign asks several hundred people to look at several thousand line items and decide, one by one, whether someone should still have access they were granted at some point in the past. The campaign completes. The compliance requirement is satisfied. And the following quarter, the same questions are asked again, because the process has no memory of what it learned.

This is not a failure of the people doing the review. It is a failure of the instrument.

What a campaign optimises for

A campaign optimises for coverage. Every entitlement, every holder, every cycle. Coverage is easy to measure and easy to defend to an auditor, which is why campaigns survive despite being universally disliked.

What it does not optimise for is the quality of the decision. Consider what a reviewer receives: a line item saying that a user holds a role. Not whether the role has been exercised, not when the user last touched the resource behind it, not who the user's manager is, not which risk opened the question. Just the grant. The reviewer applies a heuristic, usually "I recognise this name", and moves on. Decisions are produced at the speed of clicking, and the reasoning is not recorded because there was no place to put it.

Then there is the question of attention. A campaign spends the same diligence on access that is exercised daily and access that has not been touched since the day it was granted. Those two items are not equally risky, but they look identical in the list, so they get the same twenty seconds.

And finally, there is no learning. A campaign produces a set of decisions, not a set of facts. Nobody can say afterwards what changed in the estate because of it, which findings it resolved, or whether the access it approved became dormant three weeks later.

Invert the order: let the finding open the work

The alternative is to stop treating the review as a periodic sweep and start treating it as a consequence. Work is opened by a finding, scoped to the access the finding concerns, carries the evidence that produced it, is addressed to the person accountable for that access, and is closed with a recorded outcome.

Four steps, in this order.

Identify the access that warrants a decision. Not all access: the access where the evidence says something is wrong. Entitlements that are granted and unused. Accounts whose use is visible in events but which no source declares, which is how accounts nobody manages become visible. Applications that no owner claims. Grants that exceed the purpose of the identity holding them. Each of these is a question that a person can answer in seconds because the evidence is attached, and none of them needs a calendar.

Derive who is accountable. From ownership and management fields in the catalogues, from the hierarchies the sources already contain, with manual overrides retained and traced back to whoever set them. The accountable party is a person, with a role as a fallback, never a shared queue. This single point is where most governance processes quietly die: a finding sent to a team mailbox is a finding nobody owns.

Route it as a structured item. It carries the evidence, states the decision required, defines the response format, and sets a deadline. The person resolves it inside their own business function, in the product, without opening four other systems to reconstruct context. The response returns to whatever opened the item, which may be a human or an agent.

Record the outcome and track it to closure. Not as a status note. As an entry in a ledger: what was decided, on which evidence, by whom, when, with what justification, and with what correction if the decision is later revisited.

The ledger is the part that changes the conversation

An audit log tells you that something happened. A ledger tells you why, and lets you reconstruct the position at a point in time.

The difference is structural. An append-only ledger records every decision about an identity or an application, whether it was automatic or taken by a person, the model and the confidence behind it when it was automatic, the derivation logic, the justification offered for a human override, the actor and the timestamp. A correction is added as a new entry; the original stays in the history. Nothing is overwritten, so the record is event-sourced rather than edited.

Because the underlying observations are retained, replaying the ledger reproduces the state of a decision as of any earlier date. An auditor can ask why a person was considered answerable for an application in March and receive the inputs that produced that judgement, not a reconstruction made after the fact.

This is the difference between passing an audit and being able to answer a question during one.

Where this leaves the governance platform you already own

The objection is immediate and fair: we already have an identity governance platform, and it runs our campaigns.

Good. Then it becomes one of the sources rather than the answer. The model I am describing discovers from three channels: declarations from the governance system, catalogues from the access managers, and events from logs and the security information and event management system. The intersection of the three is what produces a state for every subject.

That intersection is the interesting part, because it answers a question a governance programme cannot ask about itself. Accounts that appear in events and are declared nowhere: nobody manages them, yet they authenticate. Access declared and silent for a year: the programme believes it is needed, the evidence says otherwise. Applications the governance system maps to an owner, and instances of them that nobody claims. The delta between what the organisation believes about its identities and what the estate actually does is where the risk lives, and it is structurally invisible to the system that holds the belief.

The boundary, stated deliberately

This model is read-only towards the systems it reads. It does not provision, does not manage lifecycle, does not implement SCIM, and does not replace the governance platform.

That is not a limitation of effort. It is a position. A layer that both witnesses the estate and mutates it stops being an independent witness: the moment it can change access, its own record of what access existed becomes a record of what it decided, and the delta it exists to report disappears. Identity truth and identity change are different problems, and separating them is what makes the first one trustworthy.

How this is built in Sharelock

Identity Visibility is the layer that produces this state model, and it rests on one distinction the rest depends on: the absence of information is not the absence of an object. Every subject therefore carries one of four states. Matched means the channels agree, known means a source declares it with no event confirming use, ghost means events show it and no source declares it, unused means it is declared and silent. Every source declares the coverage it provides and the freshness of its last successful collection, which is what keeps the model usable as evidence rather than as a guess.

Accountability is derived rather than stored: from owner and manager fields and from the hierarchies present in the sources, with manual overrides retained and traced back to the person who set them. A derivation is explainable and replayable, which is what allows an auditor to ask why a particular person was considered answerable for a particular application in March.

The item is routed through a module that treats human decisions as first-class work: a task when a decision is required inside a process, a report when a judgement is needed outside it. Each carries the evidence, the response format, the responsible role or person and a deadline, and each returns its outcome to whatever opened it, human or agent, with an immutable audit entry.

The outcome lands in the decision ledger. Every decision about an identity or an application becomes an entry recording whether it was automatic or manual, the model and confidence behind it when it was automatic, the derivation logic, the justification for a human override, the actor and the timestamp. Corrections are added as new entries and the original stays. Because the underlying observations are retained in a columnar store with point-in-time reconstruction, replaying the ledger reproduces the position as of a past date rather than a current approximation of it.

A worked example makes the loop concrete. An account authenticates to a business application for nine months while no declaration in the governance platform and no catalogue in the access manager mentions it. The layer holds it as a ghost. Usage shows a weekly pattern, so it is not dormant, and the manager chain resolves to a named person in the owning department. A task opens with that history attached and a keep-or-revoke decision required within five days. The owner revokes, records the justification, and the entry lands in the ledger with the evidence that opened it. The next time the same account appears, the record already exists.

Everything the layer knows is exposed through Model Context Protocol servers, so an agent routes a governance decision to the right person using the same truth a human reads in the console, with the same freshness and without a second version of the facts.

The read-only position is enforced rather than promised. Collectors hold read scopes only, the layer has no write path into a target system, and where an action must execute it is carried out by the response layer through a connector that supports it, with the authorising decision left in the ledger.

Three questions for any review process

If you run certification campaigns, or are about to buy a platform that does, ask three things.

Does the reviewer see the evidence in the item? Usage, provenance, dormancy, ownership. If the line item is a grant and a name, the review is a formality.

Can each decision be traced back to the risk that opened it? If the answer is a spreadsheet and a campaign identifier, you have compliance evidence, not a decision record.

Does the process learn? After a cycle, can you say what changed in the estate, which questions were resolved, and which ones came back? If every cycle asks the same questions, you are not reviewing access. You are paying for the appearance of it.

‍