Every term used on MIR's public surface, defined in plain English. Last updated 2026-05-24.
Memory Infrastructure Registry. Participation history infrastructure for the internet. MIR records what entities (humans, employees, contractors, AI agents, and service accounts) have actually done over time, and surfaces that record as a signal at the moment of high-stakes decisions.
MIR is not an identity provider, a policy authority, or a scoring system. It is the evidence layer that sits underneath your existing authorization stack.
The verifiable record of what an entity has actually done over time, expressed as structured events submitted by the systems that observed those actions (your application, your API, your fraud system). MIR stores and queries this record.
A new hire and a 10-year employee may have identical credentials and identical permissions. Their participation history is what tells them apart at the moment a high-stakes action is requested.
See also: Event, Tier, Evidence layer.
MIR's position in your security architecture. Identity verification answers "who is this?" Policy authorization answers "what are they allowed to do?" The evidence layer answers "what have they actually done that earns the right to do this right now?"
The evidence layer does not make the final decision. It provides the behavioral input that authority and enforcement layers resolve against.
The point in your system where an action is authorized or denied. MIR returns a recommendation before the boundary. The consuming system enforces the decision at the boundary. MIR does not enforce.
MIR's evaluation surface. Given an actor, an action, and optional context, the policy engine looks at the actor's accumulated participation history, applies the tier thresholds for the requested action, and returns a recommendation. The endpoint is POST /v1/policy/evaluate.
The policy engine is deterministic: no machine learning, no opaque scoring. Tier thresholds are event count plus history age. The reasoning behind any recommendation is human-readable via the whyRec field.
MIR returns recommendations, not decisions. The consuming system makes the final call. This separation is load-bearing: it preserves the consuming system's autonomy and prevents MIR from becoming an unaccountable enforcement layer.
ALLOWSTEP_UPLIMITDENYSTEP_UP; the consuming system decides which step-up method to use.whyRecA discrete trust level (0, 1, 2, or 3) earned by an entity through accumulated clean participation history. Tier determines which actions are recommended for ALLOW versus STEP_UP, LIMIT, or DENY at the moment of evaluation.
Tier is computed at query time from the entity's event stream, not stored as a static rating. There is no machine learning, no opaque scoring, no risk model. The thresholds are public and unchanging.
Tier 0 is not a negative judgment. It means the entity has not yet accumulated history. New hires, freshly-provisioned agents, and newly-onboarded customers all start at tier 0.
The deterministic rules for tier assignment:
The thresholds are MIR-managed defaults. The per-action required tier is configured by the consuming organization in the policy engine.
Non-human entities (AI agents, service accounts) lose tier when inactive: 90-179 days dormant drops them one tier; 180+ days drops them to tier 0. Human entities do not decay -- a 3-month leave of absence should not reset earned trust. Decay is computed at query time and resets immediately when new events arrive. Sandbox events are exempt.
A cross-platform tier requirement. To reach tier 2 in cross-platform mode, the entity needs events from 2+ different partners; tier 3 needs events from 3+ partners. This prevents a single partner from unilaterally promoting an entity to the highest tier across the network.
Intra-org mode has no partner diversity requirement -- a single organization can take its own entities to tier 3 on its own events.
An organization tracks its own entities (employees, contractors, AI agents, service accounts, vendors) inside its own environment. No network required, no other organizations involved. Immediate value, no waiting for ecosystem effects.
Intra-org tier uses the same event count and age thresholds as cross-platform tier, but has no partner diversity requirement.
An entity carries its participation history across multiple organizations (multiple partners contributing events for the same linked entity). Used for humans, employees, contractors, and service agents that operate across institutional boundaries.
Cross-platform tier requires partner diversity (see above) in addition to event count and age.
AI agent in MIR's vocabulary refers specifically to an AI agent deployed within a single organization (intra-org only). It does not cross institutional boundaries.
Service agent refers to an AI-backed integration that operates across organizations (e.g., a vendor-provided AI that one company runs to act on behalf of another). Service agents are cross-platform.
This distinction matters because the trust mechanism differs: intra-org AI agents are governed by the org that deployed them; cross-platform service agents accumulate history across institutional boundaries.
actor.type on policy evaluationIn POST /v1/policy/evaluate, the request body's actor.type is one of two lowercase values:
"human" -- the action is being requested by or on behalf of a human"service" -- the action is being requested by an AI agent, service account, or other non-human serviceNote: there is no "agent" value here. AI agents and service accounts both use "service". Submitting "agent" will return a 400.
actorType on submitted eventsIn POST /v1/events, the optional actorType field is one of three uppercase values:
HUMAN -- the event was produced by a human actionAGENT -- the event was produced by an AI agent or service accountUNKNOWN -- the producing actor is not known with certaintyThis is different from the policy-evaluate request: events use AGENT (uppercase, three values); policy evaluate uses service (lowercase, two values).
actorType on audit log entriesIn GET /v1/audit responses, the actorType field describes which class of identity performed the audited operation. One of five uppercase values:
PARTNER -- API call from a partner organization (authenticated by API key)USER -- account-holder logged in via sessionADMIN -- MIR operatorSYSTEM -- automated MIR processAGENT -- AI agent or service accountThis enumeration describes the actor that hit MIR's API, not the actor referenced by a submitted event or policy evaluation.
actorLabelAn AI agent or service account can be issued an API key with a restricted set of permissions: only specific endpoints, only specific event types, only specific resources. A spawned sub-agent inherits its parent's permissions and cannot escalate beyond them.
kickedOffBy field on each agent. Enterprise deployments require a human authorizer at the root of every lineage tree -- no agent acts on behalf of "no one."POST /v1/events, capturing something an entity did: a transaction completed, a review left, a sign-in, an agent action. Events have a type (one of MIR's recognized event types), an external entity ID, a timestamp, and optional weight. Free-form metadata is rejected by design.Idempotency-Key) on event ingestion. MIR caches the response for 24 hours; resubmitting the same payload with the same key returns the cached result instead of creating a duplicate event. Required for agent endpoints.POST /v1/claims. Claims are recorded but do not change tier. They surface in policy responses via claimStatus.claimStatusOne of three values returned in every policy evaluation:
clean -- no claims on recordflagged -- one or more open claims, not contestedcontested -- one or more open claims, the entity (or another party) has formally disputedMIR records the claim. The consuming system decides what the claim means for the action being authorized. A flagged status does not automatically deny; it surfaces to the consuming system as evidence to consider.
chargeback, fraud, policy_violation, abuse, suspension, and identity_dispute. The set is enumerated by the API; consult /v1/policy/actions or the API reference for the current full list.x-api-key header. Stored as SHA256 hash on MIR's side, never in plaintext. Partners receive their key when their application is approved. Agent keys may be scoped to specific endpoints and event types and may be rotated via POST /v1/agents/:id/key/rotate.decision_correlation_idGET /v1/audit and GET /v1/audit/:id. Each entry carries actorType, actorId, actorLabel, the action performed, the resource affected, the correlation ID, and timestamp.GET /v1/policy/decisions/conformance -- returns metrics that surface whether a partner is actually using MIR's recommendations or rubber-stamping them. Includes rubber_stamp_rate, latency thresholds, and minimum-reports requirements before the metric is computed.
/v1/ prefix. Breaking changes will be introduced under a new version prefix; existing version contracts are honored for the duration of partner contracts.