Reconciliation and drift

Each Authonomy instance’s canonical view is a replica of two upstream streams: the identity stream from the customer’s authoritative IdP, and the credential stream from the deployment’s credential store. The reconciliation model keeps both replicas current, bounds their staleness, and avoids the conflict surface a more naive replication scheme would have.

This page describes the mechanism. The contract — what the drift window guarantees and what it costs — is described in Understand the drift window.

Two streams, one replica

Every replica in the deployment carries state from both streams:

Identity flows from the customer’s primary IdP. Authority for the identity population — who exists, what attributes they hold, whether they are enabled or disabled, what entitlements they hold — rests with the customer’s designated primary. Every other representation of identity is a replica; no replica ever displaces the primary as the system of record for identity.

Credentials flow from the deployment’s credential store. Authonomy is authoritative for native credential state (the WebAuthn public keys, TOTP seeds, and password hashes that the floor verifies); the credential store is the persistent home for that material.

A replica serves authentication against last-known state, within the drift-window bound. It does not assert authority. It does not create or mutate identity or credential state while severed from the upstream source. This commitment is what produces the no-conflict property described below.

The four sync modes

Four sync modes operate against the drift-window contract. The first two are continuous; the second two are operator-initiated.

Incremental sync. Continuous propagation of changes since the last sync marker, on cadences chosen to hold the drift window. The bulk of state movement happens here — when a user is provisioned, attribute-changed, or deprovisioned at the authoritative source, the change reaches each replica through incremental sync.

Full sync. Periodic full re-read of each upstream source, reconciled against the replica. Runs on a slower cadence — typically nightly, deployment-configurable — and exists to catch drift that incremental sync could not resolve: missed change notifications, long-severed replicas on reconnect, or bugs in the incremental path that would otherwise accumulate.

Targeted sync. Operator-initiated sync for a specific subject, attribute, or scope. Used when a change needs to reach replicas faster than the incremental cadence provides — urgent deprovisioning, urgent onboarding, emergency credential revocation. A targeted sync is written to the audit trail with the operator’s identity and the reason given.

Orphan reconciliation. Detects replica records that no longer have a corresponding authoritative record and removes them. Exists because deprovisioning events occasionally slip through the incremental path — a notification dropped, a sync interrupted mid-operation — and the orphan sweep closes that gap.

All four modes run through the operations framework. Each sync operation is durably recorded, retried on failure with backoff, deduplicated via idempotency keys, and observable in the operations console.

Why there’s no conflict surface

A reader familiar with distributed-state systems may expect a conflict-resolution discussion here. The design avoids one by making severed replicas read-only with respect to identity and credential state:

Identity stream: no conflict surface. A conflict requires two or more sides making concurrent authoritative claims about the same state. The customer’s primary IdP makes claims about identity lifecycle. No replica makes authoritative claims about identity lifecycle. Therefore no two authoritative claims exist to conflict. Every replica’s statement about an identity is derived from the authoritative source’s prior statement, with a bounded lag.

The closest thing to a conflict on the identity stream is the case where an authentication served during an outage was against a subject whose authoritative record had since been deprovisioned, and the deprovisioning hadn’t yet reached the replica. The design acknowledges this explicitly: it’s the deprovisioning-lag consequence of the drift window, not a conflict.

Credential stream: no conflict surface. Severed instances do not accept credential writes locally for replay on reconnect. Just-in-time enrollment, re-enrollment, credential recovery, password reset, and credential revocation all require the credential store or its authoritative write path to be reachable. Severed instances fail closed for these operations. The trade-off is deliberate: a simpler reconciliation model in exchange for narrower availability of credential-management operations during severance. Pre-enrolling users at onboarding closes most of the gap.

The result is a reconciliation model that doesn’t require a merge step on reconnect. Both streams are pure downstream catchup: the replica resumes consuming the upstream stream from where it left off and shrinks back toward the drift window.

What reconnection looks like

Reconnection has two shapes, distinguished by which stream is reconnecting:

Identity-stream reconnection is purely downstream catchup. The sync engine resumes propagation of any authoritative-source changes that accrued during the outage. Each instance’s canonical view shrinks back toward the drift window. No identity-state reconciliation is required because no replica wrote identity-lifecycle events during the outage. The router’s stabilization window holds traffic on whichever method served during the outage until the recovered method’s healthy state is durable.

Credential-stream reconnection is downstream catchup or reachability restoration. Reconnection applies any credential-store changes that accrued during the outage to the reconnecting instance’s local replica, or restores access to current credential state in externalized-keystore topologies. Because severed instances do not accept credential writes while disconnected, there is no upstream credential backlog to merge.

The same reconciliation model applies regardless of why the path was unavailable — external-IdP outage, credential-store outage, or site WAN severance. The stabilization windows sit between the outward reachability change and the traffic transition; their purpose is to prevent a flapping path from producing repeated transitions, not to perform reconciliation work.

The shape of the contract

Stated in operational terms: a deployment configures a drift window. The platform commits to keeping replicas current within that window absent severance, and to resuming convergence to the window when severance ends. During severance, the effective staleness on a frozen stream is the window plus the duration of severance.

The deployment selects the window width as a function of its risk posture — shorter for tighter deprovisioning lag and faster propagation, longer for lighter sync traffic — and engages the targeted-sync escape hatch for individual events that need to propagate at human-operational speed independent of the everyday cadence. The contract holds; the choice of where to set the levers is the deployment’s.