The Missing Layer

Identity tells you who someone is. Policy tells you what they're allowed to do. Neither tells you what they've actually done. That's the gap.

Same credentials. Same permissions. Different risk.

Every entity in your environment passes the same two checks: identity verification and policy authorization. But those checks return identical results for entities with fundamentally different risk profiles.

What is a tier? A discrete trust level (0, 1, 2, or 3) earned by an entity through accumulated clean participation history. Thresholds are event count + history age -- no machine learning, no opaque scoring. Tier 0 is not a negative judgment; it means the entity has not yet accumulated history. New hires and freshly-provisioned agents both start at tier 0. Tier 3 is not a safety certificate either; it records what an entity did, not what an entity is. Full thresholds →

What changes at the point of decision

When a high-stakes action is requested, MIR's policy engine checks the entity's accumulated participation history and returns a recommendation: ALLOW, STEP_UP, LIMIT, or DENY.

What MIR is

MIR is participation history infrastructure. It records what entities have actually done over time and surfaces that history as a signal at the point of decision. It is not an identity provider, a policy engine, or a scoring system. It is the evidence layer that sits underneath your existing authorization stack.

• Deterministic, not ML. No models, no scores, no opacity. Tier thresholds are event count + history age.
• Recommendations, not decisions. MIR returns ALLOW, STEP_UP, LIMIT, or DENY. Your system decides what to do with it.
• No subject-level PII. External IDs from partner-submitted events are SHA256 hashed. Events carry no free-form metadata. Account-holder login emails and partner admin contacts are stored as operational PII, governed by the DPA.
• Neutral. MIR is infrastructure, not a platform. It serves the entities it tracks, not just the organizations that submit events. Absence of history is not evidence of risk, and presence of history is not evidence of safety.

Why this is not your audit log

Most organizations already log what their systems do. An examination asks a narrower question: can you produce that record without the cooperation of the party whose conduct is in question?

Shipping logs to a central collector solved the server boundary decades ago. It does not solve the custody one. When the collector is operated by the same organization under scrutiny, the record can still be altered, deleted, or withheld by that organization. The record left the server and never left the party.

• Held by neither side. MIR keeps participation records apart from both the entity that acted and the operator of the system it acted in. Neither one is the custodian of the record it would be judged by.
• Reconstructible without us. A partner can pull a signed offline export: hash-chained checkpoints, a Merkle inclusion proof for every event, and a detached Ed25519 signature. The verifier is 17,686 bytes, imports node:crypto and node:fs and nothing else, and recomputes every hash on your own machine. If MIRegistry disappeared tomorrow, an export you kept and a key you pinned would still check out on a bare Node runtime.
• It refuses to verify itself. The verifier will not check a bundle against a public key carried inside that same bundle. Internal consistency is not provenance, so you pin the key out of band or you get a failure.
• Watched by two outside witnesses, two ways. Each checkpoint is announced to one independent witness as it seals. A second does not wait to be told: it fetches MIR's published head on its own schedule and records what was served. Checkpoints are anchored to Bitcoin through OpenTimestamps. MIR cannot quietly revise what it has already published. See the transparency page.

Where MIR sits in the stack

Who uses this