Skip to content

Identity, Reference & Matching

← Back to Mechanisms by Solution Family

Solutions that establish what an entity is, bind records to the right referent, resolve names, or match cases without confusing near-equivalents.

152 mechanisms across 17 solution archetypes in this solution family. A mechanism inherits the primary family of the archetype it instantiates; family is about the move the solution makes, not the domain where it originated.

Aspect-Scoped Identity Projection

Represent one underlying entity under a defined aspect or role as a linked derived bearer, so properties, rights, obligations, identifiers, and lifecycle rules attach only where they belong.

8 mechanisms · View full solution archetype

  • Aspect Lifecycle Register — Tracks each aspect's state through time — proposed, active, suspended, superseded, retired — with the persistence rules that decide every transition and the evidence that triggered it.
  • Database View or Entity Projection — Exposes an entity under one aspect as a derived record assembled at read time from the underlying source, showing only the columns and rows that aspect is entitled to.
  • Legal Capacity or Status Record — Establishes a person or organization acting in a specific legal capacity as a formal, authority-backed record naming the capacity and the evidence that created it.
  • Role-Based Access Profile — Grants an account the permissions of a named role, scoped and purpose-limited so what one capacity may do never leaks into another.
  • Role-Scoped Record Type — Defines a distinct stored record type for an entity under a role, with its own key and its own rules for reconciling clashes with the underlying entity.
  • Scoped Namespace Suffix — Makes an aspect independently addressable by attaching a scope qualifier to the underlying entity's name, keeping the link to the base visible inside the identifier itself.
  • Typed Identity-Relation Edge — Represents the bond between an underlying entity and one of its aspects as a single typed, first-class edge that can carry its own precedence and conflict rules.
  • Work / Expression / Manifestation / Item Model — Splits a creative artifact into a four-level ladder — work, expression, manifestation, item — so each abstraction level bears only the properties that belong to it.

Data-Control Boundary Inertization

Keep untrusted content inert until a structural boundary, validation rule, and authority gate explicitly permit it to become control.

11 mechanisms · View full solution archetype

  • Allowlisted Parser or Schema Validator — Admits input only when it matches an explicitly allowlisted grammar or schema, parsing it into typed, role-tagged fields and refusing anything that doesn't fit — so untrusted bytes never reach an interpreter as an unvalidated blob.
  • Capability-Scoped Tool Invocation — Binds each tool or action call to a narrowly scoped capability granted for that purpose, so untrusted content processed by a deputy can never summon authority the deputy was not explicitly handed.
  • Content Security Policy or Execution Policy — A declarative policy the runtime consults after parsing and before execution, naming which sources and channels may run and treating everything else as inert — so injected content that slips past other controls still has no authority to act.
  • Contextual Output Encoding — Neutralizes an untrusted value by encoding it for the exact sink it is written into — HTML body, attribute, JavaScript, URL, or SQL literal — at output time, so it stays data and never becomes markup or code.
  • Injection Payload Regression Tests — A maintained suite that fires a corpus of known injection payloads at every mapped input boundary and fails the build if any one is no longer neutralized, turning past vulnerabilities into permanent guardrails.
  • Least-Privilege Execution Context — Runs the code that touches untrusted content inside a stripped-down, isolated context — minimal privileges, no ambient authority, contained blast radius — so that even a full compromise of the interpreter can do little.
  • Parameterized Interpreter Call — Sends untrusted values to an interpreter through its binding interface so they travel in a separate operand channel and are parsed as data, never as command.
  • Rejection or Quarantine Queue — Routes content that fails the boundary's checks to a held, logged disposition path — never silently dropped nor forced through — where it can be reviewed, released, or purged.
  • Structured Command Construction — Assembles a command as typed structure with untrusted values in explicit operand slots, so no command string is ever formed for them to inject into.
  • Taint Tracking or Provenance Labeling — Labels data as untrusted at its entry boundary and propagates the mark with it, so any attempt to use tainted content as control is visible at the point of use.
  • Template or Markup Sandbox — Renders untrusted markup inside a restricted engine that reconstructs it as inert display structure, so embedded directives are shown, not executed.

Deferred Fulfillment Placeholder

Create a first-class placeholder for a committed future value so dependent work can proceed, compose, wait, cancel, or fail explicitly before the value exists.

10 mechanisms · View full solution archetype

  • Await or Subscription — Lets a consumer watch a placeholder's public state and receive streamed updates until it resolves, without pretending the value is already in hand.
  • Callback or Continuation Registration — Hands the placeholder a continuation to run when it resolves — plus a fallback path if it doesn't — so the consumer surrenders its wait instead of parking on it.
  • Cancellation Propagation — Carries an authorized cancel request through a placeholder and out to everything downstream and upstream that was holding for it.
  • Dependency Graph Scheduling — Orders a graph of interdependent placeholders and releases each dependent the moment its predecessors resolve — or partially resolve.
  • Failure Propagation — Routes a placeholder's failure — with its reason preserved — to every dependent, switching each to its fallback instead of leaving it to hang.
  • Pending State Polling — Repeatedly reads a placeholder's status record on the consumer's own clock until it flips to a terminal state, for consumers that cannot be pushed to.
  • Promise Creation Protocol — Mints the deferred placeholder — a handle bound to an expected value type, a responsible fulfiller, and an initial pending state — before the value it stands for exists.
  • Resolution Event Commit — Atomically stamps a pending placeholder into a single authorized terminal state, guarded so exactly one resolution ever takes effect.
  • Resolved Value Memoization — Caches a placeholder's resolved value so every later read returns the identical stored result instead of re-triggering the producer.
  • Timeout Expiration Handler — Bounds a placeholder's wait with a deadline and, when it lapses, forces it out of pending into an expired terminal state with a fallback.

Dispute-Question Alignment

Stop arguing over answers until the parties have identified which kind of question they are actually contesting.

8 mechanisms · View full solution archetype

  • Burden and Standard Alignment Table — Binds each stasis type to the evidence it admits, the burden and threshold it must clear, and the answer form it demands — so proof is matched to the question.
  • Cross-Stasis Dialogue Protocol — A turn-by-turn conversational ruleset that catches an answer aimed at the wrong question in real time and names the equivocation as it happens.
  • Fact-Definition-Quality-Policy Matrix — A fixed grid whose columns are the stasis question types; sorting each claim into a cell both labels it and dictates what a valid answer must look like.
  • Formal Decidability Probe — For a question handed to an automated or formal decider, tests whether it actually admits a terminating decision procedure — or whether the promised verdict is impossible.
  • Jurisdictional Stasis Routing Check — Decides whose call each typed question is — which forum or authority is competent — and routes each to the body or neighbor archetype that can validly decide it.
  • Point-at-Issue Intake Form — A single front-door form that captures the contested claims in each party's own words and attaches a provisional question-type label before any argument begins.
  • Stasis Mapping Workshop — Gets every party in one room to co-build the stasis map — claims, question types, live mismatches, and sequence — as a single shared artifact.
  • Stasis Review Memo — The closing written record of a stasis process — states which question was controlling and why, what was decided, what remains open, and what would reopen it.

Durable Identifier Binding

Create a durable handle for a referent, bind it in an authoritative record, and maintain enough lookup, lifecycle, and audit rules that later references can rely on the handle without re-describing the entity.

10 mechanisms · View full solution archetype

  • Accession Numbering Protocol — A rule for minting structured, sequential identifiers whose shape encodes collection, order, and hierarchy, so the number itself is human-readable and self-locating.
  • Alias Redirect Table — A maintained map from superseded, variant, or legacy identifiers to the current canonical handle, so old references keep resolving.
  • Check-Digit or Format Validation — A validation rule that rejects malformed or mistyped identifiers at the point of entry by checking them against the shape grammar and a built-in checksum.
  • Collision Detection Review — Scans existing bindings for identifiers that point at the same entity twice — or one identifier stretched across two entities — and routes each conflict to a steward for a merge-or-split decision.
  • Identifier Lifecycle Register — Records where each identifier stands in its life — active, deprecated, retired, or superseded — and which identifier replaced which, so a handle is never silently reused or left dead-ending.
  • Identifier Minting Workflow — The governed procedure that issues a new durable identifier for a referent — scoping the entity, confirming it is genuinely new, and having an authorized party mint and register the handle.
  • Identifier Registry — The authoritative book of record that holds every identifier-to-referent binding together with the trail of who assigned it and when.
  • Identifier Reservation Queue — Lets a requester claim an identifier before the thing it will name exists, holding it in a provisional state that nobody else can take until the binding is finalized or the hold expires.
  • Namespace Prefix Registry — Allocates prefixes — segments of the identifier space — to sub-assigners, so each can mint freely inside its own prefix while the boundaries between prefixes guarantee no cross-collision.
  • UUID or Random Token Generator — Fabricates identifiers that are unique by construction — drawn from a space so vast that no coordinator, lookup, or namespace is needed to keep any two from ever colliding.

Entity Individuation Criteria Design

Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.

9 mechanisms · View full solution archetype

  • Count Impact Assessment — Estimates how a proposed individuation rule changes entity counts, denominators, eligibility, and exposure before the rule is adopted.
  • Edge-Case Adjudication Panel — A standing review body that decides contested individuation cases and records each ruling as governed, appealable precedent rather than hidden drift.
  • Entity Definition Workshop — A facilitated session that surfaces the tacit, conflicting assumptions about what counts as one entity before any system is built on them.
  • Entity Resolution Policy — A standing procedure for deciding whether two records refer to the same entity by applying an explicit same-as criterion rather than raw token matching.
  • Identity and Unity Test Checklist — A fixed set of same-as, part-whole, persistence, and edge-case questions a reviewer must answer before an entity model is accepted.
  • Individuation Criteria Charter — The single authoritative document that declares, for a scope, which entity kinds exist, their unity and identity tests, and who may revise them.
  • Master Entity Registry — The system of record that stores accepted entities, their identifiers, aliases, lineage, and cross-system links under the governing individuation criteria.
  • Split/Merge Decision Tree — A branching template that walks a transformation to a verdict: continuity, succession, fork, merger, replacement, or several new entities.
  • Versioned Identity Rulebook — A change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable.

Entity Persistence Across Observation Gaps

Keep a temporarily unseen entity represented as an uncertain continuing entity, then re-associate its return to the retained identity before declaring disappearance or creating a replacement.

5 mechanisms · View full solution archetype

  • Absence-Evidence Calibration Test — Rates how informative a non-detection actually is — by asking how likely the channel would have seen the entity if it were there — so a weak-coverage silence can't be read as strong evidence of absence, and only a genuinely informative absence is allowed to trigger retirement.
  • Dormant Entity Registry — Keeps an entity's identity and last-known facts in a bounded, tiered, privacy-limited dormant record when detailed prediction isn't warranted — marking it unobserved rather than deleting it, so continuity survives a long gap without inventing a current state.
  • Multi-Observer Sighting Reconciliation — Merges intermittent, out-of-order, and conflicting reports of one entity from many observers into a single continuity record — ranking sources by authority and keeping each report's provenance rather than letting the loudest or latest overwrite the rest.
  • Predictive State Filter — Carries an entity's state forward through an observation gap as a probability distribution anchored on the last confirmed sighting, widening the uncertainty envelope as time passes so the estimate never masquerades as an observation.
  • Reappearance Association Protocol — Decides whether a fresh sighting is the same entity that went dark — scoring it against an explicit identity criterion and abstaining into a monitored ambiguous hold rather than forcing an unsafe rebind.

Evidence-Bound Authentication

Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.

11 mechanisms · View full solution archetype

  • Certificate Chain Validation — Establishes that a certificate's key really belongs to the named subject by walking the signed chain from leaf to a trusted root, enforcing each hop's validity, scope, and revocation, and returning a graded verdict.
  • Chain-of-Custody Evidence Review — Authenticates an artifact by reconstructing its unbroken, documented custody trail — proving the thing in hand is the same one collected at origin, handled intact and untampered.
  • Challenge-Response Authentication — Proves a claimant holds a secret by having them compute the correct answer to a fresh, unpredictable challenge — so possession is demonstrated without the secret crossing the wire, and a captured exchange can't be replayed.
  • Credential Verification Workflow — Runs an asserted eligibility or identity claim through a defined sequence of primary-source evidence checks — with a staffed exception lane for the cases the rules can't settle — before a protected offer or access is granted.
  • Digital Signature Verification — Confirms that a specific message was signed by the holder of a given key and hasn't changed since — binding content to its signer's key, with tamper-evidence built in, while deliberately leaving key-to-identity trust to a separate step.
  • Federated Identity Assertion — Lets one system grant access on the strength of a signed identity assertion from a trusted external identity provider — accepting the provider's authentication verdict instead of re-authenticating the user itself.
  • Liveness or Presence Check — Proves a real, live, present subject is producing the evidence right now — so a photo, recording, mask, or deepfake cannot stand in for a genuine presence.
  • Multi-Factor Authentication — Requires evidence from two or more independent categories — something you know, have, and are — so compromising any single factor is not enough to pass.
  • Provenance Chain Review — Authenticates an artifact by tracing its origin and every handoff — accepting it only when the lineage back to a trusted source is complete and unbroken.
  • Revocation Status Check — Checks whether an otherwise-valid credential has been revoked, expired, or pushed out of scope since it was issued — so trust is withdrawn the moment its basis changes.
  • Zero-Knowledge Authentication Protocol — Proves possession of a secret, or the truth of a claim, while revealing nothing beyond the claim itself — authentication without handing over the underlying data.

Identity-Bounded Change

Modify an existing entity only inside an explicit identity boundary, retain its stable identity and lineage when continuity tests pass, and declare replacement or a fork when they do not.

11 mechanisms · View full solution archetype

  • Chain-of-Custody Record — Holds an artifact's identity intact through every handoff by logging who held it, when, and what they did — an unbroken, tamper-evident chain of possession.
  • Conservation Treatment Record — A per-object dossier that fixes, before any work, which material is identity-bearing and which is alterable, then logs each treatment against that line — so a physical object stays the same authenticated thing through repair and restoration.
  • Document Revision History — Preserves a document's identity across drafts and editions by recording every revision, redline, and approval in order, so any past state is recoverable and every change is attributable.
  • Event-Sourced Entity History — Stores an entity's whole life as an ordered, append-only log of events and treats that log as the source of truth, reconstructing any past or present state by replaying it.
  • Identity Continuity Review — A periodic judgment that tests an entity's accumulated changes — not just the latest one, but the whole drift — against an explicit persistence criterion, and returns a verdict on whether it is still the same entity.
  • Legal Amendment Record — Keeps a legal instrument the same instrument through amendment by recording superseded language, effective dates, and which parties are bound by which version.
  • Persistent Identifier Resolver — Gives an entity one permanent identifier and resolves it to wherever the current authoritative version now lives, so the name survives every move and revision.
  • Policy Amendment Register — Maintains one authoritative register of each policy's current version, amendments, owners, and effective dates, and periodically reviews the accumulated changes for drift.
  • Replacement or Fork Decision Record — The authoritative record that declares whether a change continues the same entity, replaces it, or forks a new line — naming who decided, under what rule, and preserving the link to the predecessor.
  • Split/Merge Change Log — Records when an entity splits into several or several merge into one, marking the resulting branches and preserving parent-to-child lineage so identity survives cardinality changes.
  • Version Control System — Keeps every historical state, diff, branch, and merge of a digital artifact under one parented lineage, so any version can be named, compared, and restored while the artifact stays the same tracked subject.

Identity-Resonant Persuasion Design

Create ethical self-recognition between audience and appeal so alignment feels identity-consistent rather than externally imposed.

8 mechanisms · View full solution archetype

  • Consent and Autonomy Review — Checks whether recipients can understand the persuasive intent, reject the appeal, and retain meaningful choice.
  • Counteridentification Probe — Tests whether audiences hear the appeal as insulting, inauthentic, manipulative, out-group coded, or threatening to belonging.
  • Identity-Field Interview — Elicits how members describe their own values, boundaries, exemplars, taboos, and credible voices before messages are designed.
  • Identity-Resonance Message Review — Runs draft appeals through identity-map, authenticity, evidence, stereotype, and autonomy checks before deployment.
  • Narrative Identification Storyboard — Structures stories so the audience can inhabit a perspective or role while keeping claims accurate and agency-preserving.
  • Stereotype / Tokenism Red Team — Reviews whether the identity appeal relies on caricature, mascot examples, demographic essentialism, or borrowed legitimacy.
  • Trusted Messenger Selection Protocol — Selects or prepares messengers whose biography, role, conduct, and accountability make identification legitimate.
  • Value-Language Alignment Rubric — Checks whether wording, examples, metaphors, and calls to action fit the audience's own value vocabulary without distortion.

Nearest-Exemplar Response Reuse

Use the closest remembered or stored case as the model for the present response, while making similarity, adaptation, confidence, and exception boundaries explicit.

8 mechanisms · View full solution archetype

  • Case Similarity Rubric — A fixed, weighted scoring sheet that grades how well one candidate exemplar fits the new case and flags the mismatches that should veto reuse regardless of the score.
  • Case-Based Reasoning System — Runs the full retrieve–reuse–revise–retain loop, but earns its keep at the revise step: it adapts a retrieved case's solution to the new case's specific differences rather than copying it.
  • Exemplar Feedback Registry — Logs what happened every time an exemplar was reused and uses those outcomes to broaden, narrow, or retire each stored case's authority — so the case memory sharpens instead of fossilizing.
  • Expert Case Recall Checklist — Forces an expert's tacit 'this reminds me of a case' into an explicit, auditable comparison — which case, why it's close, and where the resemblance breaks.
  • Incident Playbook Lookup — Under time pressure, pulls the closest matching past incident and runs its response as the immediate starting action — bounded to the steps this incident actually covers.
  • K-Nearest-Neighbor Case Matcher — Answers a new case by polling its k nearest stored neighbors and letting them vote, reading confidence straight off how much the neighborhood agrees.
  • Precedent Matching Workflow — Treats a prior decision as binding guidance so like cases are decided alike — reusing the earlier ruling for consistency, and departing only by formally distinguishing the new case.
  • Similarity Search over Case Embeddings — Encodes every stored case as a vector and finds the nearest ones by a learned distance in that space — matching on raw concrete content instead of hand-built features or abstract rules.

Object-Centered Feature Binding

Bind separately detected features to the right object, event, entity, or record by using shared context, co-occurrence cues, exclusivity constraints, and explicit ambiguity states instead of fusing channels blindly.

9 mechanisms · View full solution archetype

  • Active Probe Sequence — Actively intervenes — asks, nudges, or re-observes — to generate new disambiguating evidence and stops once binding confidence clears the bar.
  • Assignment Optimization Matcher — Chooses the single globally consistent feature-to-object assignment that respects a one-to-one constraint, rather than accepting the first locally plausible pairing.
  • Binding Error Audit — Reviews completed bindings after the fact against their rationale records to find false merges and false splits and feed the corrections back.
  • Feature Binding Matrix — Lays features and candidate objects on the two axes of a grid, scores each cell by cue, and flags where assignments collide — so a whole binding decision can be inspected at once.
  • Merge/Split Review Queue — Parks ambiguous or conflicting bindings in a review queue and routes them to a human merge-or-split decision before any irreversible downstream action.
  • Multimodal Fusion Tracker — Binds features arriving through different sensing modalities into one object estimate while keeping each channel's uncertainty visible.
  • Object File Tracker — Keeps a persistent bundle for each object and carries its identity across time, updating or splitting it as new frames arrive.
  • Scene Segmentation Pipeline — Turns raw channel outputs into channel-specific tokens and candidate segments — the front-end that produces the units later binding steps score.
  • Temporal Coincidence Detector — Tests whether feature onsets fall inside the same time window more often than chance would allow, turning simultaneity into a scored — not assumed — binding cue.

Persistent Identifier Stewardship

Keep references usable over time by assigning a durable identifier and maintaining the resolver, metadata, and stewardship rules that make the identifier continue to reach the same intended entity.

6 mechanisms · View full solution archetype

  • Custodial Transfer Protocol — The governed handoff that moves update authority for a set of identifiers from one steward to the next — without ever orphaning the tokens.
  • Identifier Version Resolution Rule — The policy that decides which version a bare token resolves to — latest, pinned, or as-of a date — when one persistent identifier stands over many versions.
  • Persistent Identifier Resolver Service — Accepts a persistent token and returns its current usable target — looking up the live mapping and applying access rules — so callers never depend on where the entity currently lives.
  • Redirect and Tombstone Policy — Governs what a token resolves to once direct access ends — a redirect to a successor or a tombstone that explains the withdrawal — so continuity survives moves and deletions.
  • Resolution Link Checker — Continuously tests that tokens still resolve to meaningful current targets, flagging resolver rot before references silently decay.
  • Resolver Landing Page — The human-readable page a resolver returns — stating what the identifier denotes and showing the disambiguating detail a person needs to confirm they reached the right entity.

Persistent Site Framing

Keep places, slots, roles, beds, parcels, positions, or host regions usable over time by defining the site separately from whatever currently occupies it.

9 mechanisms · View full solution archetype

  • Assignment and Release Workflow — Governs how occupants enter, hold, and leave sites through explicit turnover states and authority checks, so no placement or vacancy just happens.
  • Capacity-Fit Matrix — Matches a proposed occupant against a site's capacity and constraints before anyone is placed, so mismatches are caught on paper rather than in place.
  • Occupancy Ledger — Records who occupied which site, when, and under what authority — an append-only history of each site's succession of occupants.
  • Physical or Virtual Labeling System — Renders each site's token in the world — a sign, code, or name — so the right host position can be found and referred to on the spot.
  • Site Audit Walkthrough — A periodic on-the-ground pass that reconciles the site records against physical reality and resolves every discrepancy it finds.
  • Site Lineage Tombstone — Marks a retired, split, or merged site and points old references to its successor, so decommissioning leaves a trail instead of a dangling gap.
  • Site Map or Plan — Draws sites as bounded, nested regions so their extent and adjacency are legible at a glance.
  • Site Registry — The authoritative catalog of sites — binding each host position's identity and steward to a durable entry that persists through every occupant.
  • Vacancy Status Dashboard — Surfaces which sites are vacant, occupied, reserved, or blocked — and how heavily each region is used — in one live view.

Principal-Bound Authority Mediation

Let a deputy act only when the requesting principal, stated intent, delegated scope, and use of the deputy’s authority are explicitly bound and checkable.

9 mechanisms · View full solution archetype

  • Confused-Deputy Abuse-Case Test — Deliberately constructs forged, replayed, and context-stripped requests that try to make a deputy spend its authority for an unentitled originator, and confirms each one is refused or stepped up.
  • CSRF Token Challenge — Embeds an unpredictable secret in the genuine user interface so a state-changing request proves it was intentionally initiated by the principal, not silently forged by a third-party page riding the ambient session.
  • Delegation Audit Log — Records each mediated action as a paired entry — who caused it and who executed it, under which delegated scope — so review can separate the originating principal from the deputy that acted.
  • Object-Capability Reference — Instead of asking a deputy to infer authority from identity, hands it a narrow, unforgeable reference that already embodies the permitted action on a specific object.
  • On-Behalf-Of Authorization Flow — Exchanges an incoming user credential for a downstream one that still represents the original caller, so each service hop re-derives authority from the real principal instead of falling back on its own broad service account.
  • Origin and Referer Gate — Validates the browser-attested Origin/Referer header against an allow-list of trusted front-ends, rejecting state-changing requests whose declared source is not the site's own interface — no shared secret required.
  • Policy-Engine Subject Binding Check — Sends each sensitive request to an externalized policy engine that evaluates it against the originating subject's own authority — not the deputy's — and returns permit, deny, or step-up.
  • Scoped Service-Account Impersonation — Has the deputy assume a narrow, short-lived identity scoped to the specific caller and task instead of acting under its own broad standing account.
  • Signed Delegation Token — A cryptographically signed, self-contained artifact that carries the originating principal, the permitted scope, and freshness bounds with it, so any downstream deputy can verify the delegation offline before acting.

Registry-Mediated Discovery

Put a maintained discovery registry between agents and changing counterparts so stable names resolve to current locations, interfaces, or contact records instead of hard-coded references.

10 mechanisms · View full solution archetype

  • Catalog or Broker Directory — Curates a browsable catalog of offerings under a broker who vets, categorizes, and ranks them, so a caller discovers a fitting counterpart rather than resolving an address it already knows.
  • Directory Service — Stores structured entries under a schema and hierarchical namespace, so a caller resolves a known distinguished name into an authoritative attribute record.
  • Federated Registry Synchronization — Keeps multiple autonomous registries mutually discoverable by propagating and reconciling entries across their partitions under an audited trust fabric, without merging them into one authority.
  • Human Referral Directory — Uses trusted people as the registry: you reach the current right counterpart by being forwarded along a chain of human stewards, each of whom knows who holds a role now.
  • Lease or Heartbeat Registration — Lets a provider publish its current locator under a time-bounded lease it must keep renewing; if the heartbeat stops, the entry auto-expires, so the registry only ever advertises things that are still alive.
  • Name Resolution Service — Translates one stable, human-meaningful name into its current locator by walking a delegated hierarchical namespace, so callers hold a name that never changes while the address behind it does.
  • Registry Query API — Exposes a programmatic contract for filtering the registry by attributes and returning locator records through access-scoped, privacy-filtered views, so callers discover by criteria rather than by knowing one exact key.
  • Resolver Cache with TTL — Memoizes a resolved locator on the caller's side for a bounded time-to-live, serving repeat lookups locally and, when the source is unreachable, falling back to the last-known-good answer.
  • Service Registry — Maintains a live roster of running service instances annotated with health and routing weight, so a client discovers not just an endpoint but a healthy, preferred one to send the next request to.
  • Successor Forwarding Record — Leaves a persistent tombstone at a retired key that names its successor, so a caller arriving at the old identifier is explicitly redirected to the current one instead of hitting a dead end, with the supersession on record.

Use-Time Precondition Binding

Act on a precondition only when the condition is still bound to the state at the moment of use, not merely when it was true during an earlier check.

10 mechanisms · View full solution archetype

  • Abort-and-Retry After State Mismatch — When a use-time check finds the state has changed since it was first read, it abandons the stale attempt cleanly and re-runs the operation on fresh state — instead of forcing the old decision through.
  • Compare-and-Swap Version Token — Reads a value together with a version marker and writes back only if the version is still unchanged — so a write computed from stale state is refused instead of silently overwriting a newer one.
  • Confirmation Dialog with State Refresh — Re-fetches the live state the instant a person clicks confirm and shows it — with what changed highlighted — so the human commits against current reality, not the stale screen they were looking at.
  • Final Revalidation Before Commit — Re-runs the original precondition check as the very last step before the irreversible commit, so the action fires only if the condition that justified it still holds at the instant of use.
  • Lease-Bound Capability Token — Grants permission as a self-expiring token whose short validity window bounds the check–use gap, so a stale grant simply stops working instead of needing to be revoked.
  • Lock or Hold Until Use — Takes an exclusive hold on the resource at check time and keeps it through the use, so the checked condition cannot change inside the gap.
  • Reservation-Commit Protocol — Takes the resource out of contention the moment it is checked — an expiring hold that the commit later consumes — so the precondition cannot drift between check and use.
  • Revocation Status Check at Use — At the point of use, queries a live revocation source to confirm a previously-granted authority has not since been withdrawn before acting on it.
  • Snapshot-Pinned Decision — Computes and records a decision against one frozen, versioned snapshot of the state, binding the action to the exact evidence it was based on.
  • Two-Phase Commit with Freshness Check — Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land.