The MIR Assertions Constitution

Article I — Core Identity

1. MIRA is a notary. It records signed statements. It does not evaluate them.
2. MIRA is a registry. It stores assertions linked to artifact hashes. It does not curate, rank, or filter them.
3. MIRA is infrastructure. It operates like DNS or a certificate transparency log — mechanically, predictably, and without opinion.
4. MIRA is not an authority. Authority belongs to issuers and is established outside the registry through their real-world identity, domain ownership, and public reputation. MIRA does not confer, amplify, or diminish authority.

Article II — Immutable Rules

Article III — Non-Goals

The following are permanently outside the scope of MIRA. They are not deferred features. They are excluded by design.

1. Content moderation. MIRA does not review, approve, or reject assertions based on their content, subject matter, or political implications.
2. Issuer tiering. MIRA does not create tiers such as "official," "trusted," "premium," "government," or "enterprise." All issuers are issuers.
3. Authenticity verification. MIRA verifies cryptographic signatures and hash matches. It does not verify whether an artifact is authentic, original, or unmanipulated.
4. Ranking or sorting by prominence. Assertions are displayed in chronological or deterministic order (e.g., by assertion ID). Never by issuer importance, popularity, or perceived authority.
5. Recommendation or amplification. MIRA does not recommend issuers, highlight assertions, or surface "important" claims. All assertions are equal in presentation.
6. Narrative framing. MIRA does not describe assertions using language that assigns moral, legal, or epistemic weight. Assertion types are labels, not judgments.
7. Issuer endorsement. Registration and domain verification are mechanical processes. They do not constitute endorsement, approval, or certification by MIRA.
8. Feature monetization that introduces hierarchy. Paid features must never create visible differentiation between issuers or assertions. No issuer can purchase elevated display, priority ordering, or distinguished presentation.

Article IV — Language Standards

MIRA's public-facing surfaces — lookup pages, API responses, documentation, and embedded widgets — must adhere to the following language constraints:

1. Use nouns and mechanical states. Examples: "Issued By," "Assertion Type," "Timestamp," "Key Fingerprint," "Domain Verified (DNS)."
2. Do not use trust adjectives. Prohibited terms include but are not limited to: "verified" (as a trust signal), "official," "trusted," "authentic," "genuine," "confirmed," "certified," "approved," "legitimate."
3. Mechanical verification language is permitted. Examples: "Domain ownership confirmed via DNS TXT record," "Signature valid," "Key status: ACTIVE." These describe protocol states, not trust states.
4. DISPUTE is an assertion type, not an alarm. It receives no special iconography, color treatment, or visual emphasis. It is displayed identically to ISSUED_BY, METHOD, INTENT, or any other type.
5. Guidance text must reinforce neutrality. Any explanatory text on public pages must include language equivalent to: "MIRA records who made each assertion. MIRA does not verify content accuracy."

Article V — Technical Constraints

These constraints are enforced at the architectural level, not the policy level.

1. Assertions are cryptographically signed by the issuer. MIRA stores the signature and signed payload. The registry cannot forge, modify, or backdate assertions.
2. Issuer identity is derived from domain ownership and key registration. There is no manual approval tier, editorial review, or qualitative assessment of issuer suitability.
3. Key revocation is append-only. A revoked key is marked with a revocation timestamp. Assertions signed before revocation remain in the registry with their original key association.
4. Hash computation is performed client-side. Files are never uploaded to MIRA. Only the resulting hash is transmitted. MIRA has no access to original artifacts.
5. The API surface is minimal. The registry exposes: assertion creation, assertion lookup by hash, issuer key management, and key lifecycle events. Feature expansion must be justified against the non-goals and approved through the amendment process.

Article VI — Governance

Succession

The founding steward must designate at least one successor before the foundation is established. Successors are bound by this constitution. No individual — including the founder — may hold a board seat for more than two consecutive terms.

Article VII — Amendment Process

For Articles III–VI:

1. Proposed amendment published publicly with full rationale.
2. 90-day public comment period.
3. Board vote: 75% supermajority required.
4. 30-day implementation delay after approval.

For Article II (Immutable Rules):

Article II cannot be amended. It is the structural foundation of MIRA's institutional identity. If a future governing body determines that an Immutable Rule must change, the correct course is to create a new system under a new name. MIRA, as defined by this constitution, ceases to be MIRA if its Immutable Rules are violated.

Article VIII — Institutional Failure Conditions

MIRA should cease to operate rather than compromise its constitutional constraints. The following constitute institutional failure:

1. Silent deletion of an assertion.
2. Introduction of issuer tiering or preferential display.
3. Assignment of trust scores or credibility ratings.
4. Adjudication of assertion truthfulness.
5. Suppression of assertions based on content, political pressure, or commercial interest.
6. Modification of historical records without visible audit trail.

If any of these occur, MIRA has failed its mission and should be publicly acknowledged as compromised.