AI / ML Disclosure

What MIR Is

MIR (Memory Infrastructure Registry) is a participation-history platform. Partners submit events describing what entities -- humans, employees, contractors, AI agents, and service accounts -- have done. MIR records those events and computes a tier for each entity using fixed thresholds (event count and history age). At the point of a partner's authorization decision, MIR returns a recommendation -- ALLOW, STEP_UP, LIMIT, or DENY -- based on the entity's accumulated tier and claim status.

MIR provides evidence. The consuming system makes the decision.

Tier Computation Is Deterministic

Tier is a function of event count and history age. The thresholds are public and fixed:

• Tier 0: 0 events, 0 days of history
• Tier 1: 10+ events, 14+ days of history
• Tier 2: 50+ events, 30+ days of history (cross-platform: 2+ partner sources)
• Tier 3: 200+ events, 90+ days of history (cross-platform: 3+ partner sources)

The same input always produces the same tier. There is no probabilistic component, no learned weight, no inference, and no opaque scoring.

AI / ML Risk Category Mapping

The table below maps the risk categories most often raised in vendor security reviews, NIST AI RMF assessments, and EU AI Act due diligence to MIR's actual implementation.

Risk Category	MIR Status
Model bias / fairness	Not applicable. No model exists. Tier is a published threshold function of event count and history age. Thresholds apply identically to every entity.
Hallucination / fabricated output	Not applicable. MIR returns a fixed enumeration of recommendations (ALLOW, STEP_UP, LIMIT, DENY) plus structured metadata. No generated text.
Model drift	Not applicable. No model. Thresholds change only via versioned policy updates, which are documented in the public changelog.
Training data risk	Not applicable. No training takes place. MIR ingests events submitted by authenticated partners and stores them as records.
Explainability	Every policy evaluation supports a debug mode (?debug=true) that returns the full signal breakdown: event count, partner diversity, claim count, history age, and the threshold that produced the recommendation. The recommendation is fully reconstructible from recorded inputs.
Black-box decisioning	Not applicable. The decision logic is published thresholds. Source code paths, threshold values, and the policy engine architecture are documented in the integration guide and enterprise guide.
Adversarial input attacks	Not applicable for ML adversarial attacks (no model). Standard input-validation defenses apply: explicit field rejection (no free-form metadata), SHA256 hashing of external IDs, rate limiting, idempotency keys, sandbox isolation.
Model versioning / lineage	Not applicable. The policy engine is a versioned codebase, not a model artifact. Threshold and action-registry changes are tracked in the public changelog.
Automated decision-making (GDPR Art. 22)	MIR returns recommendations to the consuming system. The consuming system makes the decision. MIR does not execute, enforce, or finalize any action. Authority and enforcement remain with the partner.
EU AI Act high-risk classification	MIR is not an AI system as defined in EU AI Act Art. 3(1). It is rule-based software with deterministic, fully specified outputs. Customer determinations of high-risk use depend on the consuming system's downstream decision logic, which is the customer's responsibility to assess.

What MIR Does Use

For completeness, the standard infrastructure components MIR runs on:

• PostgreSQL -- relational data store for events, users, partners, audit records
• Redis -- session cache, rate-limiting counters, idempotency tracking
• Express / Node.js -- HTTP API runtime
• SHA256 hashing -- applied to all external user identifiers and API keys before storage
• TLS 1.2+ -- transport security on all partner endpoints
• Pino structured logging -- audit and operational logs

None of these components contain or invoke AI or machine-learning models.

Verification

The claims in this document can be verified by:

• Calling POST /v1/policy/evaluate?debug=true on any actor and inspecting the returned signal breakdown -- the recommendation is fully traceable to event count, history age, and partner diversity.
• Reviewing the public API documentation and integration guide (partner login required) for endpoint specifications.
• Reviewing the public changelog for the full history of threshold and action-registry changes.
• Reviewing MIR's Constitution and Constraint statement, which formalize the deterministic, evidence-only architectural commitment.

For deeper review, contact enterprise@mirregistry.com. Source-code access for vendor security review is available under NDA.

What This Document Does Not Cover

This disclosure addresses MIR's own software. It does not cover:

• How partners submit events. Partners may use AI or ML in their own systems to detect, classify, or generate the events they then submit to MIR. The integrity of submitted events is the partner's responsibility.
• How partners use MIR's recommendations. The consuming system's downstream logic, including any AI or ML it employs to act on a recommendation, is the partner's responsibility to assess and disclose.
• MIR Assertions, a separate product for cryptographic media provenance, which has its own architectural disclosures.