# Requirements Index

Auto-generated by the requirements tool (`mu-requirements`). Do not edit by hand; regenerate instead.

_1284 requirements across 49 normative documents._

Stable catalog of every RFC 2119 normative statement in the Normative documents.
IDs have the form `<MNEMONIC>-R<nn>`, numbered per document in reading order.
Tooling, Conformance and Validation reference these IDs.

## Terminology -- `00-foundation/Terminology.md`  (6 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `TERM-R01` | SHALL | 1. Purpose | A shared vocabulary is essential for semantic interoperability. Every normative specification in the Meta-Universe family SHALL use the terminology defined i... |
| `TERM-R02` | SHALL | 1a. Role of This Document | Three foundation documents address vocabulary, and their roles SHALL NOT be conflated: |
| `TERM-R03` | SHALL | 2. Terminology Principles | The Meta-Universe terminology SHALL be: |
| `TERM-R04` | SHALL | 4. Normative Language | The keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT and MAY are interpreted according to RFC 2119. |
| `TERM-R05` | SHOULD | 5. Evolution of Terminology | New terms SHOULD: |
| `TERM-R06` | SHOULD | 5. Evolution of Terminology | Deprecated terms SHOULD remain documented for historical reference. |

## Change-Process -- `01-constitution/Change-Process.md`  (26 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `CHG-R01` | SHALL | 3. Guiding Principles | Every change SHALL follow these principles: |
| `CHG-R02` | SHALL | 4. Change Lifecycle | Every change SHALL pass through the following lifecycle: |
| `CHG-R03` | SHALL | 4. Change Lifecycle | No stage SHALL be skipped for normative changes. |
| `CHG-R04` | SHALL | 5. Change Request (CR) | Every proposed modification SHALL be represented as a Change Request (CR). |
| `CHG-R05` | SHOULD | 5. Change Request (CR) | A CR SHOULD contain: |
| `CHG-R06` | SHOULD | 6. Change Categories | Changes SHOULD be classified as one of the following: |
| `CHG-R07` | SHALL | Breaking | Breaking changes SHALL require explicit justification. |
| `CHG-R08` | SHOULD | 6a. Semantic Change Classification | The Editorial / Corrective / Evolutionary / Breaking axis in Section 6 describes the **impact** of a change. It SHOULD be complemented by a second axis descr... |
| `CHG-R09` | SHALL | 6a. Semantic Change Classification | A change to the normative rule base SHALL additionally pass the pre-merge Policy Consistency Check: a change that would make the rule set logically unsatisfi... |
| `CHG-R10` | SHOULD | 6a. Semantic Change Classification | Every Change Request SHOULD declare one or more semantic change types: |
| `CHG-R11` | SHOULD | 6a. Semantic Change Classification | Declaring the semantic type explicitly enables AI agents to reason about change. An agent SHOULD be able to read a Change Request, determine its semantic cha... |
| `CHG-R12` | SHALL | 7. Compatibility Assessment | Every Change Request SHALL include a compatibility assessment. |
| `CHG-R13` | SHALL | 8. Freeze Rule | - SHALL NOT receive silent modifications; |
| `CHG-R14` | MAY | 8. Freeze Rule | - MAY only change through a published Change Request; |
| `CHG-R15` | SHALL | 8. Freeze Rule | - SHALL preserve complete revision history. |
| `CHG-R16` | SHALL | 9. Versioning | Every published specification SHALL declare its version. |
| `CHG-R17` | SHALL | 9. Versioning | New versions SHALL be published instead of replacing previous normative releases. |
| `CHG-R18` | SHOULD | 9. Versioning | Historical versions SHOULD remain publicly available. |
| `CHG-R19` | MAY | 10. Deprecation | Features MAY be deprecated before removal. |
| `CHG-R20` | SHOULD | 10. Deprecation | A deprecation notice SHOULD specify: |
| `CHG-R21` | SHOULD | 10. Deprecation | Deprecation SHOULD precede any breaking removal. |
| `CHG-R22` | SHALL | 11. Migration | Whenever compatibility cannot be preserved, migration guidance SHALL accompany the new specification. |
| `CHG-R23` | SHOULD | 11. Migration | Migration guidance SHOULD include: |
| `CHG-R24` | SHALL | 12. Publication | Every published version SHALL include: |
| `CHG-R25` | SHALL | 13. Auditability | The evolution of every normative document SHALL remain auditable. |
| `CHG-R26` | SHALL | 13. Auditability | It SHALL be possible to determine: |

## Conformance -- `01-constitution/Conformance.md`  (22 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `CONF-R01` | SHALL | 4. Mandatory Requirements | A conforming specification SHALL: |
| `CONF-R02` | SHALL | 4. Mandatory Requirements | Failure to satisfy any mandatory constitutional requirement SHALL result in non-conformance. |
| `CONF-R03` | MAY | 5. Levels of Conformance | Additional maturity or capability levels MAY be defined by subordinate standards such as MMAS and MUFP. |
| `CONF-R04` | SHALL | 5. Levels of Conformance | These levels SHALL extend, but never weaken, constitutional requirements. |
| `CONF-R05` | MAY | 5a. Conformance Axes | The axes are independent: an artifact MAY hold constitutional conformance while declaring different levels on the architectural and federation axes. A combin... |
| `CONF-R06` | MAY | 6. Partial Implementations | An implementation MAY support only part of the Meta-Universe ecosystem. |
| `CONF-R07` | MAY | 6. Partial Implementations | Partial implementations MAY still conform to MUC provided that every implemented feature respects all applicable constitutional principles. |
| `CONF-R08` | SHALL | 6. Partial Implementations | Unsupported features SHALL be explicitly declared. |
| `CONF-R09` | MAY | 7. Extensions | Specifications MAY introduce additional concepts. |
| `CONF-R10` | SHALL | 7. Extensions | Extensions SHALL NOT: |
| `CONF-R11` | SHALL | 7. Extensions | Extensions SHALL declare: |
| `CONF-R12` | MAY | 8. Imported Standards | Imported models (for example OData, RDF, Schema.org, BPMN or FHIR) MAY be incorporated into conforming meta-models. |
| `CONF-R13` | SHALL | 8. Imported Standards | Importing an external standard SHALL NOT exempt the implementation from constitutional obligations. |
| `CONF-R14` | MAY | 9. Certification | Certification processes MAY evaluate conformance. |
| `CONF-R15` | SHOULD | 9. Certification | Certification SHOULD verify: |
| `CONF-R16` | SHOULD | 10. Declaration of Conformance | Every conforming specification SHOULD publish a Conformance Statement containing at least: |
| `CONF-R17` | SHALL | 11. Conformance Evolution | Conformance SHALL always reference a specific version of the Constitution. |
| `CONF-R18` | MAY | 11. Conformance Evolution | Future constitutional versions MAY introduce additional requirements. |
| `CONF-R19` | SHALL | 11. Conformance Evolution | Conformance SHALL therefore always be version-specific. |
| `CONF-R20` | SHALL | 12. Loss of Conformance | A specification SHALL lose constitutional conformance if it: |
| `CONF-R21` | SHALL | 12. Loss of Conformance | Loss of conformance SHALL be explicitly documented. |
| `CONF-R22` | MAY | Future Directions | This document defines the constitutional axis (single-level MUC conformance) and names the other two axes, but it does not define their levels. The **MMAS ma... |

## Definitions -- `01-constitution/Definitions.md`  (12 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `DEF-R01` | SHALL | 1. Purpose | Unlike the Foundation Terminology, which establishes a common vocabulary, this specification defines how those concepts SHALL be interpreted when applying th... |
| `DEF-R02` | SHALL | Constitutional Principle | A rule that SHALL remain valid across all future versions of the Meta-Universe unless explicitly superseded through the constitutional change process. |
| `DEF-R03` | SHALL | Semantic Sovereignty | Sovereignty SHALL NOT be transferred implicitly through federation. |
| `DEF-R04` | SHALL | Canonical Truth | Projections SHALL NOT replace canonical truth. |
| `DEF-R05` | SHALL | Federation Agreement | Participation SHALL remain voluntary. |
| `DEF-R06` | SHALL | Purpose | Purpose SHALL precede knowledge disclosure. |
| `DEF-R07` | MAY | Consent | Consent MAY be delegated according to governance policies. |
| `DEF-R08` | SHALL | Disclosure | Disclosure SHALL follow applicable Contracts. |
| `DEF-R09` | SHALL | 4. Normative Interpretation | 4. Informative documents SHALL NOT redefine constitutional concepts. |
| `DEF-R10` | SHOULD | 5. Evolution | Definitions SHOULD evolve conservatively. |
| `DEF-R11` | SHALL | 5. Evolution | Existing meanings SHALL NOT be redefined incompatibly without a new major constitutional version. |
| `DEF-R12` | SHOULD | 5. Evolution | Deprecated definitions SHOULD remain documented for historical interpretation. |

## Governance -- `01-constitution/Governance.md`  (21 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `GOV-R01` | SHALL | 2. Governance Principles | The governance of Meta-Universe SHALL follow these principles: |
| `GOV-R02` | SHALL | 3. Standards Hierarchy | The Meta-Universe standards SHALL be governed by the following hierarchy: |
| `GOV-R03` | SHALL | 3. Standards Hierarchy | Lower-level standards SHALL NOT contradict higher-level standards. |
| `GOV-R04` | SHALL | 4. Standard Ownership | Each standard SHALL declare: |
| `GOV-R05` | SHOULD | 5. Decision Principles | Changes SHOULD be evaluated according to: |
| `GOV-R06` | SHALL | 6. Evolution Model | Each released version SHALL be immutable. |
| `GOV-R07` | SHALL | 6. Evolution Model | New functionality SHALL be introduced through new versions rather than silent modification. |
| `GOV-R08` | SHALL | 7. Freeze Rule | - SHALL NOT be silently modified; |
| `GOV-R09` | MAY | 7. Freeze Rule | - MAY only change through an approved Change Request. |
| `GOV-R10` | MAY | 8. Change Requests | Any stakeholder MAY propose improvements. |
| `GOV-R11` | SHOULD | 8. Change Requests | A Change Request SHOULD include: |
| `GOV-R12` | SHALL | 8. Change Requests | Accepted changes SHALL appear in a future version of the specification. |
| `GOV-R13` | SHOULD | 9. Compatibility | The governance process SHOULD preserve compatibility whenever reasonably possible. |
| `GOV-R14` | SHALL | 9. Compatibility | Breaking changes SHALL be clearly identified and accompanied by migration guidance. |
| `GOV-R15` | SHALL | 10. Conformance | Governance SHALL ensure that certification criteria remain publicly available and versioned. |
| `GOV-R16` | SHOULD | 11. Transparency | The following SHOULD remain publicly accessible: |
| `GOV-R17` | SHALL | 12. Intellectual Independence | No programming language, vendor, platform or storage technology SHALL become a normative dependency of the standards. |
| `GOV-R18` | MAY | 13. Governance Bodies | The governance of Meta-Universe is described in terms of **architectural roles**, not a real organization. The roles below define *which responsibilities exi... |
| `GOV-R19` | SHALL | Architecture Board | Owns the Meta-Model Architecture Standard (MMAS). It governs the architectural model, validation levels and meta-model conformance, and SHALL ensure MMAS nev... |
| `GOV-R20` | SHALL | Certification Authority | Owns the conformance and certification framework. It defines and publishes conformance levels and certification procedures across MUC, MMAS and MUFP, and SHA... |
| `GOV-R21` | SHALL | Certification Authority | These roles are **organization-independent**. The standard SHALL remain valid regardless of which entity holds any role, and assuming a role SHALL NOT grant ... |

## Meta-Universe-Constitution -- `01-constitution/Meta-Universe-Constitution.md`  (43 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MUC-R01` | SHALL | 1. Purpose | All standards within the Meta-Universe family (including MMAS and MUFP) SHALL conform to this Constitution. |
| `MUC-R02` | SHALL | Article 1. Reality First | Every Meta-Object SHALL represent or intentionally abstract a real or conceptual entity. |
| `MUC-R03` | SHALL | Article 2. Universal Identity | Every Meta-Object SHALL possess a globally unique and persistent identity. |
| `MUC-R04` | SHALL | Article 2. Universal Identity | Identity SHALL remain stable throughout the object's lifetime. |
| `MUC-R05` | MAY | Article 2. Universal Identity | Names, labels and representations MAY change. |
| `MUC-R06` | SHALL | Article 3. Sovereignty | Every Meta-Universe SHALL remain sovereign. |
| `MUC-R07` | SHALL | Article 3. Sovereignty | Federation SHALL NOT transfer ownership, governance or identity between universes. |
| `MUC-R08` | SHALL | Article 4. Context | Every semantic fact SHALL exist within an explicit context. |
| `MUC-R09` | MAY | Article 4. Context | Different contexts MAY legitimately produce different projections of the same object. |
| `MUC-R10` | SHALL | Article 4. Context | Context SHALL be preserved. |
| `MUC-R11` | SHALL | Article 5. Separation of Object and Projection | No projection SHALL redefine the identity of its source object. |
| `MUC-R12` | SHALL | Article 6. Ownership | Every significant semantic fact SHALL have an owner. |
| `MUC-R13` | SHALL | Article 7. Provenance | Every significant fact SHALL declare its provenance. |
| `MUC-R14` | SHALL | Article 7. Provenance | Unknown provenance SHALL be explicitly identified. |
| `MUC-R15` | SHALL | Article 8. Traceability | Every significant semantic fact SHALL be traceable. |
| `MUC-R16` | SHALL | Article 8. Traceability | Implementations SHALL be able to determine: |
| `MUC-R17` | SHALL | Article 9. Shared Schemas | Semantic interoperability SHALL begin with shared schemas. |
| `MUC-R18` | SHALL | Article 9. Shared Schemas | Public availability of a schema SHALL NOT imply public availability of data. |
| `MUC-R19` | SHALL | Article 10. Semantic Discovery | A Meta-Universe SHALL be able to make the existence and structure of its public schemas discoverable to authorized participants. |
| `MUC-R20` | SHALL | Article 10. Semantic Discovery | Discoverability of a schema SHALL remain independent of access to the underlying data, and SHALL NOT compromise the sovereignty or confidentiality of the pub... |
| `MUC-R21` | SHALL | Article 11. Knowledge Disclosure | Knowledge SHALL be exchanged through explicit contracts. |
| `MUC-R22` | SHALL | Article 11. Knowledge Disclosure | Disclosure SHALL be limited to the agreed purpose and scope. |
| `MUC-R23` | SHALL | Article 12. Least Knowledge | Every participant SHALL receive only the minimum knowledge required to achieve an agreed purpose. |
| `MUC-R24` | SHOULD | Article 12. Least Knowledge | Implementations SHOULD prefer projections over complete objects. |
| `MUC-R25` | SHALL | Article 13. Purpose | Every request for semantic knowledge SHALL declare its intended purpose. |
| `MUC-R26` | SHALL | Article 13. Purpose | Purpose SHALL participate in authorization decisions. |
| `MUC-R27` | SHALL | Article 14. Trust | Trust SHALL never be assumed. |
| `MUC-R28` | SHALL | Article 14. Trust | Trust SHALL be established through verifiable identity, provenance, evidence or agreement. |
| `MUC-R29` | SHALL | Article 15. Security and Confidentiality | Trust SHALL NOT be confused with security. |
| `MUC-R30` | SHALL | Article 15. Security and Confidentiality | A Meta-Universe SHALL protect the integrity, authenticity and confidentiality of its semantic facts and of the projections it discloses, independently of the... |
| `MUC-R31` | SHALL | Article 15. Security and Confidentiality | Establishing trust SHALL NOT remove the obligation to secure disclosed knowledge. |
| `MUC-R32` | SHALL | Article 16. Federation | Independent universes SHALL communicate through federation. |
| `MUC-R33` | SHALL | Article 16. Federation | Federation SHALL exchange projections rather than ownership. |
| `MUC-R34` | SHALL | Article 16. Federation | Synchronization SHALL NOT redefine authority. |
| `MUC-R35` | SHALL | Article 17. Semantic Compatibility | Differences between semantic models SHALL be made explicit through mappings. |
| `MUC-R36` | SHALL | Article 17. Semantic Compatibility | Implicit semantic assumptions SHALL be avoided. |
| `MUC-R37` | SHALL | Article 18. Evolution | Meta-Universe standards SHALL support long-term evolution. |
| `MUC-R38` | SHOULD | Article 18. Evolution | Breaking semantic changes SHOULD be exceptional and accompanied by migration guidance. |
| `MUC-R39` | SHALL | Article 19. Technology Independence | Constitutional principles SHALL remain independent of programming languages, storage engines, communication protocols and implementation technologies. |
| `MUC-R40` | SHALL | Article 20. Constitutional Hierarchy | Lower layers SHALL NOT contradict higher layers. |
| `MUC-R41` | MAY | Article 21. Conformance | Additional rules MAY be introduced by subordinate standards, provided they do not violate the Constitution. |
| `MUC-R42` | SHOULD | Requirement Identifiers | Every normative statement in this Constitution carries a stable identifier of the form `MUC-Rnn`, catalogued in the Requirements Index (for example, `MUC-R03... |
| `MUC-R43` | MAY | Requirement Identifiers | Identifiers are generated from the text by the requirements tool (`mu-requirements`) and are assigned in reading order. During the Working Draft phase they M... |

## Core-Profile -- `02-architecture/Core-Profile.md`  (9 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `COREPR-R01` | SHALL | 1. Purpose | mandatory subset** an implementation SHALL support to call itself |
| `COREPR-R02` | MAY | 2. Scope | The Core Profile covers two roles. An implementation MAY claim either or both: |
| `COREPR-R03` | SHALL | 3. Core Model requirements | A Core Model implementation SHALL: |
| `COREPR-R04` | MAY | 3. Core Model requirements | A Core Model implementation MAY omit: external-standard import, Knowledge Quality |
| `COREPR-R05` | SHALL | 4. Core Federation requirements | A Core Federation implementation SHALL: |
| `COREPR-R06` | MAY | 4. Core Federation requirements | A Core Federation implementation MAY omit: Synchronization, Identity Binding, |
| `COREPR-R07` | SHALL | 5. Conformance statement | A Core Profile claim SHALL state which role(s) are supported and the validation |
| `COREPR-R08` | SHALL | 6. Architectural Invariants | - The Core Profile SHALL be a strict subset of the full specification; it SHALL |
| `COREPR-R09` | SHALL | 6. Architectural Invariants | - A Core claim SHALL be independently verifiable. |

## Data-Mastership -- `02-architecture/Data-Mastership.md`  (17 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `DATAMA-R01` | SHALL | 5.1 Pattern M: Model-Mastered | - Every projected copy SHALL be marked as generated: it declares its master, its generation time and a "do not edit here" notice in whatever form the target ... |
| `DATAMA-R02` | SHALL | 5.1 Pattern M: Model-Mastered | - Edits made in the external copy have **no authority**. An implementation SHOULD either lock the external copy, overwrite it on next publication, or capture... |
| `DATAMA-R03` | SHALL | 5.2 Pattern E: External-Mastered | - Harvesting SHALL land the unmodified capture under `raw/<system>/<dataset>/` with its provenance sidecar, per Model-Traversal-and-Layout §6; the semantic t... |
| `DATAMA-R04` | SHALL | 5.2 Pattern E: External-Mastered | - Every mirrored dataset SHALL carry **freshness metadata**: time of last successful harvest, declared cadence, and a staleness limit after which consumers S... |
| `DATAMA-R05` | SHALL | 5.3 Pattern H: Partitioned | - Each partition SHALL be declared as its own dataset with a single master (Pattern M or E). |
| `DATAMA-R06` | SHALL | 5.3 Pattern H: Partitioned | - The same field SHALL NOT be writable on both sides. Bidirectional mastership of one datum is non-conforming; if truly needed, split the datum (for example:... |
| `DATAMA-R07` | SHALL | 6. The Mastership Register (`sources.yaml`) | Every conforming repository SHALL contain a Mastership Register at its root, covering **every dataset the model holds or mirrors**. A dataset absent from the... |
| `DATAMA-R08` | SHALL | 6. The Mastership Register (`sources.yaml`) | Each entry SHALL declare: |
| `DATAMA-R09` | SHALL | 6. The Mastership Register (`sources.yaml`) | **Declared entries.** Real models pass through a transitional state the register must be able to tell the truth about: mastership is decided but the flow is ... |
| `DATAMA-R10` | SHOULD | 7. Conflict and Drift | - **Detection.** Implementations SHOULD detect drift between master and copy (content comparison, fingerprints, timestamps) at least at each flow run. |
| `DATAMA-R11` | SHALL | 8. Freshness and Trust | A consumer of a mirrored dataset SHALL be able to see, without leaving the model: the master system, the last harvest time, and whether the staleness limit i... |
| `DATAMA-R12` | SHALL | 9. AI Agent Rules | - **Before relying on a dataset**: SHALL consult the register; for mirrors, SHALL check freshness and prefer re-harvest over guessing when stale. |
| `DATAMA-R13` | SHALL | 9. AI Agent Rules | - **Before writing**: SHALL write only to the dataset's master. A correction to an external-mastered fact goes to the external system (or to a human with acc... |
| `DATAMA-R14` | SHOULD | 9. AI Agent Rules | - **When citing**: SHOULD state the master ("per Confluence Ops space, as harvested 2026-07-30") rather than presenting a mirror as origin. |
| `DATAMA-R15` | SHALL | 11. Validation | Structural validation (V1) SHALL check: the register exists, parses, and every declared `model_location` exists. Semantic validation (V2) SHOULD check: every... |
| `DATAMA-R16` | SHALL | 12. Architectural Invariants | Mastership SHALL preserve: |
| `DATAMA-R17` | SHALL | 12. Architectural Invariants | Mastership SHALL NEVER be implied by physical location alone: location gives a default reading, the register gives the law. |

## Extension-Model -- `02-architecture/Extension-Model.md`  (28 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `EXT-R01` | SHALL | 1. Purpose | This document defines how Meta-Universe Meta-Models SHALL import, reference and extend external semantic models while preserving interoperability, semantic i... |
| `EXT-R02` | SHALL | 3. Architectural Principle | Meta-Universe SHALL prefer **extension over duplication**. |
| `EXT-R03` | SHOULD | 3. Architectural Principle | Existing semantic standards SHOULD be imported whenever they already describe the required concept with sufficient precision. |
| `EXT-R04` | SHALL | 4. Semantic Package | An external standard SHALL NOT be imported as a loose collection of objects. It SHALL be imported as a **Semantic Package**: a single, versioned, self-descri... |
| `EXT-R05` | SHALL | 4. Semantic Package | A Semantic Package SHALL declare at minimum: |
| `EXT-R06` | SHALL | 5. Import Model | An imported model SHALL remain an independent semantic authority. |
| `EXT-R07` | SHALL | 5. Import Model | Importing a model SHALL NOT transfer ownership of: |
| `EXT-R08` | SHALL | 6. Imported Metadata | Every imported model SHALL declare at least: |
| `EXT-R09` | SHALL | 7. Imported Namespaces | Imported concepts SHALL preserve their original namespace whenever practical. |
| `EXT-R10` | SHALL | 7. Imported Namespaces | Local aliases MAY exist but SHALL NOT replace canonical references. |
| `EXT-R11` | MAY | 8. Extension Model | Local models MAY extend imported concepts. |
| `EXT-R12` | SHALL | 8. Extension Model | Extensions SHALL: |
| `EXT-R13` | SHALL | 9. Prohibited Modifications | An implementation SHALL NOT: |
| `EXT-R14` | SHALL | 9. Prohibited Modifications | If incompatible behavior is required, a new local concept SHALL be created. |
| `EXT-R15` | SHALL | 10. Semantic Mapping | Mappings SHALL explicitly describe the relationship between imported and local concepts. |
| `EXT-R16` | MAY | 10. Semantic Mapping | Supported mapping types MAY include: |
| `EXT-R17` | SHALL | 10. Semantic Mapping | Mappings SHALL be version-aware. |
| `EXT-R18` | SHALL | 11. Version Management | Imported models SHALL preserve references to their original versions. |
| `EXT-R19` | SHALL | 11. Version Management | Local extensions SHALL declare compatibility with the imported version. |
| `EXT-R20` | SHOULD | 11. Version Management | Changes in imported standards SHOULD trigger compatibility assessment rather than automatic migration. |
| `EXT-R21` | MAY | 12. Multi-Source Models | A Meta-Model MAY import multiple external standards simultaneously. |
| `EXT-R22` | SHALL | 12. Multi-Source Models | Conflicts SHALL be resolved explicitly through semantic mappings. |
| `EXT-R23` | SHALL | 13. Ownership | Ownership boundaries SHALL remain explicit. |
| `EXT-R24` | SHALL | 14. Traceability | Every imported concept SHALL remain traceable to its origin. |
| `EXT-R25` | SHOULD | 14. Traceability | Traceability SHOULD identify: |
| `EXT-R26` | SHOULD | 15. Federation | Federated universes SHOULD exchange canonical semantic references whenever both parties support the same imported standard. |
| `EXT-R27` | SHOULD | 15. Federation | When different standards are used, federation SHOULD rely on explicit semantic mappings rather than implicit assumptions. |
| `EXT-R28` | SHALL | 18. Architectural Invariants | Importing external models SHALL NEVER violate: |

## Internationalization -- `02-architecture/Internationalization.md`  (23 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `INTERN-R01` | MAY | 3. Principles | descriptions, documentation — MAY be translated. |
| `INTERN-R02` | SHALL | 3. Principles | SHALL NOT change what a concept means or its Semantic Fingerprint. |
| `INTERN-R03` | SHALL | 4. The Canonical Semantic Name Is Not Localized | A Canonical Semantic Name (CSN) SHALL |
| `INTERN-R04` | SHALL | 4. The Canonical Semantic Name Is Not Localized | be language-independent and SHALL NOT be localized. |
| `INTERN-R05` | SHALL | 4. The Canonical Semantic Name Is Not Localized | - A concept SHALL have exactly one CSN regardless of how many languages it is |
| `INTERN-R06` | SHALL | 4. The Canonical Semantic Name Is Not Localized | - A CSN SHALL NOT be translated, transliterated per-language, or varied by locale. |
| `INTERN-R07` | SHALL | 4. The Canonical Semantic Name Is Not Localized | - All federation interactions SHALL exchange CSNs, |
| `INTERN-R08` | SHALL | 5. What Is Localizable | The following are presentation and SHALL be treated as **non-semantic**: |
| `INTERN-R09` | SHALL | 6. Language Tags | Localized content SHALL be tagged with a language tag conforming to **BCP 47** |
| `INTERN-R10` | SHALL | 6. Language Tags | - Each localized value SHALL declare its language tag. |
| `INTERN-R11` | SHOULD | 6. Language Tags | - A model SHOULD declare a default language tag for content whose tag is absent. |
| `INTERN-R12` | SHALL | 6. Language Tags | - Language tags SHALL be compared case-insensitively per BCP 47 and SHOULD be |
| `INTERN-R13` | SHALL | 7. Attaching Localized Labels Without Affecting the Fingerprint | Localized labels SHALL attach to Objects, Properties and Projections as values of |
| `INTERN-R14` | SHALL | 7. Attaching Localized Labels Without Affecting the Fingerprint | - a concept with one CSN and ten translated Display Names SHALL produce the |
| `INTERN-R15` | SHALL | 7. Attaching Localized Labels Without Affecting the Fingerprint | - adding, editing or removing a translation SHALL NOT require a |
| `INTERN-R16` | SHALL | 7. Attaching Localized Labels Without Affecting the Fingerprint | - two Universes that present a concept in different languages SHALL still resolve |
| `INTERN-R17` | SHOULD | 7. Attaching Localized Labels Without Affecting the Fingerprint | User interfaces SHOULD present the localized Display Name appropriate to the |
| `INTERN-R18` | SHOULD | 7. Attaching Localized Labels Without Affecting the Fingerprint | for a requested locale, they SHOULD fall back to the default language. |
| `INTERN-R19` | SHALL | 10. Architectural Invariants | - The CSN SHALL be language-independent and SHALL NOT be localized. |
| `INTERN-R20` | SHALL | 10. Architectural Invariants | - Localized content SHALL be non-semantic and SHALL NOT affect the Semantic |
| `INTERN-R21` | SHALL | 10. Architectural Invariants | - Localized values SHALL carry BCP 47 language tags. |
| `INTERN-R22` | SHALL | 10. Architectural Invariants | - Federation SHALL exchange CSNs, never localized Display Names, for identity. |
| `INTERN-R23` | SHALL | 10. Architectural Invariants | - Changing a translation SHALL NOT constitute a semantic change. |

## Meta-Model-Composition -- `02-architecture/Meta-Model-Composition.md`  (22 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `METAMO-R01` | SHALL | 2. The Composition Problem | Meta-Universe SHALL prefer **composition over duplication** — the structural |
| `METAMO-R02` | SHALL | 3. Kinds of Concept | Every concept appearing in a Meta-Model SHALL be classified, for the purpose of |
| `METAMO-R03` | SHALL | 3. Kinds of Concept | snapshot in another. The author SHALL record the chosen kind so that validators and |
| `METAMO-R04` | SHALL | 4.1 EMBED | - SHALL preserve the embedded model's namespace, version and |
| `METAMO-R05` | SHALL | 4.1 EMBED | - SHALL NOT be flattened into ad-hoc host Properties; |
| `METAMO-R06` | SHALL | 4.2 REFERENCE | Property typed by an identifier scheme. The referent's attributes SHALL NOT be |
| `METAMO-R07` | SHALL | 4.2 REFERENCE | scheme *S*", carrying the scheme's URI and version. The members of *S* SHALL NOT |
| `METAMO-R08` | MAY | 4.2 REFERENCE | A reference MAY be **snapshotted** — embedded as an immutable value copy — when |
| `METAMO-R09` | SHALL | 4.2 REFERENCE | address as it stood at a point in time). A snapshot SHALL be marked as such and |
| `METAMO-R10` | SHALL | 4.2 REFERENCE | SHALL record the source identifier and the capture Event, so it is never mistaken |
| `METAMO-R11` | SHALL | 4.3 MIX-IN and ANNOTATE | A **Facet** SHALL be applied as a MIX-IN: a declared facet Package whose Properties |
| `METAMO-R12` | SHALL | 4.3 MIX-IN and ANNOTATE | versioned Object, `odrl:*` policy on a Contract). A Facet SHALL NOT be re-invented |
| `METAMO-R13` | SHALL | 4.3 MIX-IN and ANNOTATE | as bespoke domain fields, and SHALL NOT be buried in the domain payload — it is |
| `METAMO-R14` | SHOULD | 5. The Decision Rubric | A conforming Meta-Model SHOULD be able to justify each Property by naming the test |
| `METAMO-R15` | SHALL | 6. When Duplication Is Acceptable | the point*; it SHALL be marked as a snapshot with its source identifier and |
| `METAMO-R16` | MAY | 7. Compositional Roles of External Models | Roles are guidance, not law: a model MAY be embedded in one context and referenced |
| `METAMO-R17` | SHALL | 8. Expressing Composition in MMAS | SHALL preserve the linked model's **namespace, version, provenance and Semantic |
| `METAMO-R18` | SHALL | 8. Expressing Composition in MMAS | Fingerprint**, and SHALL NOT violate the import invariants of |
| `METAMO-R19` | MAY | 8. Expressing Composition in MMAS | version; validators MAY check membership and detect drift. |
| `METAMO-R20` | SHOULD | 8. Expressing Composition in MMAS | A Meta-Model SHOULD declare, for each Property, its **composition kind** |
| `METAMO-R21` | SHOULD | 11. Validation and Conformance | A conforming implementation SHOULD validate that: |
| `METAMO-R22` | SHALL | 12. Architectural Invariants | Composition SHALL NEVER violate: |

## MMAS-Conformance -- `02-architecture/MMAS-Conformance.md`  (12 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MMAS-CONF-R01` | MAY | 3. Conformance Axes | The MMAS Conformance Levels defined in this document measure the **MMAS axis** only. A Meta-Model MAY conform to MUC while providing only partial MMAS suppor... |
| `MMAS-CONF-R02` | SHALL | 5. Mandatory Requirements | Regardless of level, every MMAS-conforming Meta-Model SHALL: |
| `MMAS-CONF-R03` | SHOULD | 6. Conformance Statement | Every Meta-Model SHOULD publish a Conformance Statement. |
| `MMAS-CONF-R04` | SHOULD | 7. Evidence | Architectural conformance SHOULD be supported by objective evidence such as: |
| `MMAS-CONF-R05` | SHOULD | 7. Evidence | Self-declaration MAY be used but SHOULD be distinguishable from independently verified certification. |
| `MMAS-CONF-R06` | MAY | 8. Certification | Certification MAY verify MMAS conformance. |
| `MMAS-CONF-R07` | SHOULD | 8. Certification | Certification SHOULD evaluate: |
| `MMAS-CONF-R08` | MAY | 9. Evolution | A Meta-Model MAY improve its MMAS level over time. |
| `MMAS-CONF-R09` | SHOULD | 9. Evolution | Regression to a lower level SHOULD be explicitly documented. |
| `MMAS-CONF-R10` | SHALL | 9. Evolution | Changes affecting conformance SHALL be reflected in the published Conformance Statement. |
| `MMAS-CONF-R11` | SHALL | 10. Loss of Conformance | A Meta-Model SHALL lose MMAS conformance if it: |
| `MMAS-CONF-R12` | SHALL | 10. Loss of Conformance | Loss of conformance SHALL be documented and versioned. |

## MMAS-Core -- `02-architecture/MMAS-Core.md`  (25 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MMAS-CORE-R01` | SHALL | 1. Purpose | This document defines the fundamental architectural building blocks that every Meta-Model SHALL follow within the Meta-Universe ecosystem. |
| `MMAS-CORE-R02` | SHALL | 3. Architectural Principles | Every Meta-Model SHALL: |
| `MMAS-CORE-R03` | SHALL | 4. Composition Hierarchy | MMAS-Core defines a single, canonical composition hierarchy. Every Meta-Model SHALL be expressible as a strict nesting of the concepts below, and every confo... |
| `MMAS-CORE-R04` | SHALL | 5. Core Building Blocks | Every Meta-Model SHALL be composed from the following architectural concepts, which are the named levels of the Composition Hierarchy defined in Section 4. |
| `MMAS-CORE-R05` | SHALL | 5.1 Meta-Model | A Meta-Model SHALL have: |
| `MMAS-CORE-R06` | SHALL | 5.2 Bundle | Bundles SHALL: |
| `MMAS-CORE-R07` | SHALL | 5.3 Layer | Layers SHALL: |
| `MMAS-CORE-R08` | SHALL | 5.4 Object | Objects SHALL possess: |
| `MMAS-CORE-R09` | SHOULD | 5.5 Property | Every property SHOULD declare: |
| `MMAS-CORE-R10` | SHALL | 5.6 Relationship | Relationships SHALL explicitly define: |
| `MMAS-CORE-R11` | SHOULD | 5.7 Event | Events SHOULD be immutable and traceable. The Event primitive is defined in detail in Event. |
| `MMAS-CORE-R12` | SHALL | 5.8 Projection | A projection SHALL NOT redefine object identity. |
| `MMAS-CORE-R13` | SHALL | 5.10 Context | Context SHALL be explicit whenever meaning depends upon it. |
| `MMAS-CORE-R14` | SHALL | 6. Public Schema | Every Meta-Model SHALL expose a public schema. |
| `MMAS-CORE-R15` | SHALL | 6. Public Schema | The schema SHALL describe structure without requiring disclosure of instance data. |
| `MMAS-CORE-R16` | SHALL | 6. Public Schema | Schema discovery SHALL be possible independently from data access. |
| `MMAS-CORE-R17` | SHALL | 7. Separation of Schema and Instance | Knowledge exchange SHALL begin with schema discovery before instance disclosure. |
| `MMAS-CORE-R18` | MAY | 8. External Semantic Models | A Meta-Model MAY import external standards. |
| `MMAS-CORE-R19` | SHALL | 8. External Semantic Models | Imported concepts SHALL preserve references to: |
| `MMAS-CORE-R20` | SHALL | 8. External Semantic Models | Local extensions SHALL NOT modify the imported semantics. |
| `MMAS-CORE-R21` | SHALL | 8. External Semantic Models | Instead, they SHALL extend them. |
| `MMAS-CORE-R22` | SHALL | 9. Extensibility | Meta-Models SHALL evolve through extension rather than modification whenever practical. |
| `MMAS-CORE-R23` | SHALL | 9. Extensibility | Extensions SHALL: |
| `MMAS-CORE-R24` | MAY | 10. Technology Independence | Conforming implementations MAY use: |
| `MMAS-CORE-R25` | SHALL | 11. Architectural Invariants | Every MMAS-conforming Meta-Model SHALL preserve: |

## MMAS-Interchange -- `02-architecture/MMAS-Interchange.md`  (18 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MUIF-R01` | SHALL | 3. The MUIF Document Model | A MUIF document SHALL validate against `manifest.schema.json` (which references |
| `MUIF-R02` | SHALL | 4. Serialization | - **YAML** 1.2 MAY be used for authoring; it SHALL be losslessly convertible to |
| `MUIF-R03` | SHALL | 4. Serialization | the choice of JSON or YAML SHALL NOT affect the fingerprint. |
| `MUIF-R04` | SHALL | 5. Semantic vs Non-Semantic Content | following are **non-semantic** and SHALL be excluded from canonicalization: |
| `MUIF-R05` | SHALL | 5. Semantic vs Non-Semantic Content | self-declared fingerprint MUST NOT change the meaning of a model and therefore |
| `MUIF-R06` | SHALL | 5. Semantic vs Non-Semantic Content | MUST NOT change its fingerprint. Each schema marks such fields **NON-SEMANTIC** |
| `MUIF-R07` | SHALL | 6. Canonicalization Algorithm | - Strings SHALL be normalized to Unicode **NFC**. |
| `MUIF-R08` | SHALL | 6. Canonicalization Algorithm | - **Object keys** SHALL be sorted by ascending Unicode code point (ordinal). |
| `MUIF-R09` | SHALL | 6. Canonicalization Algorithm | - **Arrays SHALL be treated as sets**: each element is canonicalized, then |
| `MUIF-R10` | MAY | 6. Canonicalization Algorithm | v1.0; a future revision MAY introduce an explicit ordered-array tag — see |
| `MUIF-R11` | SHALL | 6. Canonicalization Algorithm | - Integers SHALL be emitted in shortest decimal form without leading zeros or |
| `MUIF-R12` | SHALL | 6. Canonicalization Algorithm | Two MUIF documents with the same semantic core SHALL yield the same fingerprint, |
| `MUIF-R13` | SHALL | 8. Conformance | A meta-model SHALL be exchangeable as MUIF to claim MMAS conformance at level |
| `MUIF-R14` | SHALL | 9. Architectural Invariants | - The Semantic Fingerprint SHALL be computed over the semantic core only. |
| `MUIF-R15` | SHALL | 9. Architectural Invariants | - The fingerprint SHALL be independent of serialization, key order, set order, |
| `MUIF-R16` | SHALL | 9. Architectural Invariants | - A change in meaning SHALL change the fingerprint; a change in formatting or |
| `MUIF-R17` | SHALL | 9. Architectural Invariants | labels SHALL NOT. |
| `MUIF-R18` | SHALL | 9. Architectural Invariants | - `metaModel.fingerprint` SHALL be excluded from its own computation. |

## MMAS-Package -- `02-architecture/MMAS-Package.md`  (30 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MMAS-PKG-R01` | MAY | 2. Scope | Implementations MAY use additional files provided they do not violate this specification. |
| `MMAS-PKG-R02` | SHALL | 3. Design Principles | A conforming package SHALL be: |
| `MMAS-PKG-R03` | SHALL | 3. Design Principles | Repository structure SHALL reflect semantic architecture rather than implementation technology. |
| `MMAS-PKG-R04` | SHOULD | 4. Canonical Repository Structure | Every Meta-Model SHOULD follow the canonical structure below. |
| `MMAS-PKG-R05` | MAY | 4. Canonical Repository Structure | Equivalent layouts MAY be used if semantic organization is preserved. |
| `MMAS-PKG-R06` | SHALL | 5. Repository Manifest | Every repository SHALL contain a manifest. |
| `MMAS-PKG-R07` | SHOULD | 5. Repository Manifest | The manifest SHOULD declare: |
| `MMAS-PKG-R08` | SHOULD | 6. Bundle Structure | Every Bundle SHOULD contain: |
| `MMAS-PKG-R09` | SHALL | 6. Bundle Structure | Bundles SHALL have a single semantic responsibility. |
| `MMAS-PKG-R10` | SHOULD | 7. Layer Structure | Each Layer SHOULD contain: |
| `MMAS-PKG-R11` | SHOULD | 7. Layer Structure | Layers SHOULD remain independently understandable. |
| `MMAS-PKG-R12` | SHOULD | 8. Documentation | Every public repository SHOULD include: |
| `MMAS-PKG-R13` | SHALL | 8. Documentation | Documentation SHALL remain synchronized with the published version. |
| `MMAS-PKG-R14` | SHOULD | 9. Examples | Reference examples SHOULD be stored separately from normative specifications. |
| `MMAS-PKG-R15` | SHALL | 9. Examples | Examples SHALL NOT redefine normative semantics. |
| `MMAS-PKG-R16` | SHOULD | 9. Examples | Example artifacts SHOULD identify the specification version they target. |
| `MMAS-PKG-R17` | SHOULD | 10. Imported Standards | Imported semantic models SHOULD be isolated under the imports/ directory. |
| `MMAS-PKG-R18` | SHOULD | 10. Imported Standards | Mappings between imported and local concepts SHOULD be stored under mappings/. |
| `MMAS-PKG-R19` | SHALL | 10. Imported Standards | Imported artifacts SHALL preserve references to their original source and version. |
| `MMAS-PKG-R20` | SHOULD | 11. Repository Metadata | A repository SHOULD expose machine-readable metadata sufficient for discovery. |
| `MMAS-PKG-R21` | SHALL | 12. Packaging | A distributable MMAS package SHALL preserve: |
| `MMAS-PKG-R22` | SHALL | 13. Semantic Distribution Package (SDP) | A conforming SDP SHALL contain: |
| `MMAS-PKG-R23` | SHALL | 13. Semantic Distribution Package (SDP) | An SDP SHALL be self-verifying: a consumer SHALL be able to recompute the Semantic Fingerprint from the contained structure, check it against `fingerprint.sh... |
| `MMAS-PKG-R24` | SHOULD | 14. Repository Evolution | Repository structure SHOULD evolve compatibly. |
| `MMAS-PKG-R25` | SHALL | 14. Repository Evolution | Structural changes that affect discovery or interoperability SHALL be versioned and documented. |
| `MMAS-PKG-R26` | SHOULD | 14. Repository Evolution | Migration guidance SHOULD accompany structural changes. |
| `MMAS-PKG-R27` | SHOULD | 15. AI-Native Requirements | A conforming repository SHOULD allow AI agents to: |
| `MMAS-PKG-R28` | SHOULD | 15. AI-Native Requirements | Repository layout SHOULD minimize ambiguity for automated reasoning. |
| `MMAS-PKG-R29` | SHALL | 16. Architectural Invariants | Repository organization SHALL preserve: |
| `MMAS-PKG-R30` | SHALL | 16. Architectural Invariants | Repository structure SHALL NEVER redefine semantic meaning. |

## Model-Traversal-and-Layout -- `02-architecture/Model-Traversal-and-Layout.md`  (27 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MODELT-R01` | SHALL | 1. Purpose | 1. **Lossless traversal.** A reader (human or AI agent) SHALL be able to walk the entire model bundle by bundle, layer by layer, visiting **every file exactl... |
| `MODELT-R02` | SHALL | 1. Purpose | 2. **Well-known locations.** Content that is not a semantic definition (raw source data, canonical source texts, generated artifacts, operating instructions)... |
| `MODELT-R03` | SHALL | 4. The Entry Point | A conforming repository SHALL be readable starting from exactly two files at its root: |
| `MODELT-R04` | SHALL | 4. The Entry Point | 1. **`BOOTSTRAP.md`** - the operating instructions: how to read this model, in what order, with what tools, and what an agent is expected to do and not do he... |
| `MODELT-R05` | SHOULD | 4. The Entry Point | Repositories that already use an ecosystem-specific entry file (for example `README.md`, `AGENTS.md` or `CLAUDE.md`) SHOULD make it a thin pointer to `BOOTST... |
| `MODELT-R06` | SHALL | 5. The Walk Declaration | - The **repository manifest** SHALL declare the ordered list of bundles (`bundles:` in reading order). |
| `MODELT-R07` | SHALL | 5. The Walk Declaration | - Each **bundle manifest** (`bundle.yaml`) SHALL declare the bundle's single semantic responsibility and the ordered list of its layers. |
| `MODELT-R08` | SHALL | 5. The Walk Declaration | - Each **layer manifest** (`layer.yaml`) SHALL enumerate the layer's content: files or glob patterns, each with a **kind** (§8) and a one-line **meaning**. |
| `MODELT-R09` | MAY | 5. The Walk Declaration | Enumeration MAY be **centralized instead of per-layer**: a repository whose file names carry the kind by convention (for example `{kind}-{id}-{memo}.md`) MAY... |
| `MODELT-R10` | SHALL | 5. The Walk Declaration | - Bundles SHALL be ordered so that a bundle appears **after** every bundle it depends on (foundation first). Cyclic bundle dependencies are non-conforming. |
| `MODELT-R11` | SHALL | 5. The Walk Declaration | - Layers within a bundle SHALL be ordered the same way. |
| `MODELT-R12` | SHALL | 5. The Walk Declaration | - Forward references (a file mentioning a concept defined later in the walk) are permitted, but the *declaration* order SHALL remain dependency-first, so tha... |
| `MODELT-R13` | SHALL | 5. The Walk Declaration | A walker that visits bundles, then layers, then enumerated files, each in declared order, performs the **canonical walk**. Two walkers performing the canonic... |
| `MODELT-R14` | MAY | 6. Well-Known Locations | Beyond the structural directories of MMAS-Package §4 (`bundles/`, `imports/`, `mappings/`, `schemas/`, `examples/`, `diagrams/`, `docs/`, `tools/`), this doc... |
| `MODELT-R15` | SHALL | 6. Well-Known Locations | - **`canon/`** holds the texts the model is *about* or *bound by*, when those texts must travel with the model. Layers SHALL reference canon files rather tha... |
| `MODELT-R16` | SHALL | 6. Well-Known Locations | - **`raw/`** SHALL be organized as `raw/<source-system>/<dataset>/...`. Every dataset directory SHALL carry a provenance sidecar (`_provenance.yaml`: source ... |
| `MODELT-R17` | SHALL | 6. Well-Known Locations | - **`artifacts/`** entries SHALL declare their generator and inputs (a sidecar or a header line suffices). A conforming repository can delete `artifacts/` en... |
| `MODELT-R18` | SHALL | 6. Well-Known Locations | - A repository SHOULD NOT invent parallel locations for these purposes (`_raw/`, `generated/`, `sources/` and similar). Where legacy layouts exist, the manif... |
| `MODELT-R19` | SHALL | 7. The Completeness Rule (No File Left Behind) | Every file in the repository SHALL fall into exactly one of three classes: |
| `MODELT-R20` | SHALL | 7. The Completeness Rule (No File Left Behind) | The **coverage check**: a walker SHALL be able to compare the full recursive file listing of the repository against the union of the three classes. Files in ... |
| `MODELT-R21` | SHALL | 8. File Kinds | Every enumerated file SHALL carry one kind. The base vocabulary: |
| `MODELT-R22` | SHALL | 8. File Kinds | Kinds answer "what is this file *in the model*", not "what format is it". A CSV may be `raw` (an export), `artifact` (a computed index) or `object` (a defini... |
| `MODELT-R23` | SHALL | 9. Authored, Harvested, Generated | The origin is implied by location for the well-known directories (§6) and SHALL be declared in the layer manifest elsewhere. Editing harvested or generated f... |
| `MODELT-R24` | SHALL | 11. AI-Native Requirements | A conforming repository SHALL allow an AI agent, without out-of-band knowledge, to: |
| `MODELT-R25` | SHOULD | 11. AI-Native Requirements | An agent that cannot satisfy the last point SHOULD refuse write operations on the model. |
| `MODELT-R26` | SHALL | 12. Architectural Invariants | Traversal and layout SHALL preserve: |
| `MODELT-R27` | SHALL | 12. Architectural Invariants | Layout and traversal SHALL NEVER redefine semantic meaning; they only make it reachable. |

## Naming-Conventions -- `02-architecture/Naming-Conventions.md`  (39 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `NAME-R01` | MAY | 2. Scope | Implementations MAY define additional local conventions provided they remain compatible with this specification. |
| `NAME-R02` | SHALL | 3. Naming Principles | Names SHALL be: |
| `NAME-R03` | SHALL | 3. Naming Principles | Names SHALL describe concepts rather than implementation details. |
| `NAME-R04` | SHALL | 4. Canonical Language | English SHALL be the canonical language for all normative names. |
| `NAME-R05` | MAY | 4. Canonical Language | Localized labels MAY be provided as metadata. |
| `NAME-R06` | SHALL | 4. Canonical Language | Canonical identifiers SHALL remain language-independent. |
| `NAME-R07` | SHOULD | 5. Identifier vs Display Name | Every significant artifact SHOULD distinguish between: |
| `NAME-R08` | MAY | 5. Identifier vs Display Name | Display names MAY change. |
| `NAME-R09` | SHOULD | 5. Identifier vs Display Name | Identifiers SHOULD remain stable. |
| `NAME-R10` | SHALL | 6. Canonical Semantic Name (CSN) | The distinction between Identifier and Display Name is generalized, for every public concept, into a **Canonical Semantic Name (CSN)**. Each public concept S... |
| `NAME-R11` | SHALL | 6. Canonical Semantic Name (CSN) | - Every public concept SHALL have exactly one CSN. |
| `NAME-R12` | SHALL | 6. Canonical Semantic Name (CSN) | - A CSN SHALL be immutable once published; renaming a concept SHALL be treated as a semantic change under Versioning and SHALL produce a new CSN, never a sil... |
| `NAME-R13` | SHALL | 6. Canonical Semantic Name (CSN) | - All **federation interactions SHALL exchange CSNs**. The Meta-Universe Federation Protocol (MUFP) transmits CSNs; it SHALL NOT rely on Display Names for id... |
| `NAME-R14` | SHOULD | 6. Canonical Semantic Name (CSN) | - User interfaces SHOULD present the localized Display Name while resolving it to the underlying CSN. |
| `NAME-R15` | SHALL | 6. Canonical Semantic Name (CSN) | - Display Names MAY differ across languages, contexts and presentations; the CSN SHALL remain the same. |
| `NAME-R16` | SHOULD | 6. Canonical Semantic Name (CSN) | To prevent name collisions across a federation, a CSN SHOULD be paired with the Semantic Fingerprint of the concept's defining version. Together, the CSN ide... |
| `NAME-R17` | SHALL | 6a. CSN Grammar and Identifier Scheme | A **Canonical Semantic Name** SHALL conform to the following ABNF (RFC 5234): |
| `NAME-R18` | SHALL | 6a. CSN Grammar and Identifier Scheme | An **Identifier** (the `id` of an Object, Relationship, Event, Contract or Projection, and the value of a Local Identity) is opaque and SHALL be stable for t... |
| `NAME-R19` | SHALL | 6a. CSN Grammar and Identifier Scheme | Identifiers SHALL be compared as exact byte strings; they SHALL NOT be case-folded or normalized. A Canonical Identity pairs a scheme with a value (`{ "schem... |
| `NAME-R20` | SHALL | 7. Namespace Convention | Every public concept SHALL belong to a namespace. |
| `NAME-R21` | SHALL | 7. Namespace Convention | Namespaces SHALL be globally unique within their semantic scope. |
| `NAME-R22` | SHOULD | 8. Meta-Model Naming | Meta-Models SHOULD use descriptive names. |
| `NAME-R23` | SHOULD | 9. Bundle Naming | Bundle names SHOULD be nouns representing semantic domains. |
| `NAME-R24` | SHALL | 10. Layer Naming | Layers SHALL represent one coherent semantic concern. |
| `NAME-R25` | SHOULD | 10. Layer Naming | Layer names SHOULD: |
| `NAME-R26` | SHOULD | 11. Object Naming | Object names SHOULD: |
| `NAME-R27` | SHOULD | 12. Property Naming | Property names SHOULD: |
| `NAME-R28` | SHOULD | 13. Relationship Naming | Relationship names SHOULD describe semantic meaning. |
| `NAME-R29` | SHOULD | 13. Relationship Naming | Generic names such as "link" or "relation" SHOULD be avoided. |
| `NAME-R30` | SHOULD | 14. Event Naming | Events SHOULD describe completed facts. |
| `NAME-R31` | SHOULD | 15. Contract Naming | Contracts SHOULD describe the business or semantic purpose. |
| `NAME-R32` | SHOULD | 16. File Naming | Specification documents SHOULD use: |
| `NAME-R33` | SHOULD | 16. File Naming | Example files SHOULD include the suffix: |
| `NAME-R34` | SHALL | 17. Reserved Terms | These terms SHALL NOT be redefined with incompatible meanings. |
| `NAME-R35` | SHALL | 18. Imported Standards | Imported concepts SHALL preserve their original names whenever practical. |
| `NAME-R36` | SHOULD | 18. Imported Standards | Local extensions SHOULD extend imported concepts instead of renaming them. |
| `NAME-R37` | SHALL | 19. Naming Stability | Identifiers SHALL remain stable across compatible versions. |
| `NAME-R38` | SHOULD | 19. Naming Stability | Renaming SHOULD be treated as a semantic change. |
| `NAME-R39` | SHALL | 19. Naming Stability | Migration guidance SHALL be provided whenever identifiers change. |

## Policy-Consistency -- `02-architecture/Policy-Consistency.md`  (21 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `POLICY-R01` | SHALL | 2. Normative Rules as First-Class | A **Normative Rule** is a binding statement (`SHALL` / `SHALL NOT`) with a stable |
| `POLICY-R02` | SHALL | 2. Normative Rules as First-Class | identity. Each rule SHALL declare: |
| `POLICY-R03` | SHALL | 3. Policy Consistency Check | a **Policy Consistency Check** SHALL be run. It evaluates whether the resulting |
| `POLICY-R04` | SHALL | 3. Policy Consistency Check | - A change that makes the rule set unsatisfiable SHALL be rejected as a |
| `POLICY-R05` | SHALL | 3. Policy Consistency Check | the contradicting rules SHALL be reported by identifier. |
| `POLICY-R06` | SHALL | 3. Policy Consistency Check | - The check SHALL operate at the level of rule semantics (predicates over the |
| `POLICY-R07` | MAY | 3. Policy Consistency Check | model), not text. An implementation MAY use a logic solver or a validating |
| `POLICY-R08` | SHALL | 4. Rule Precedence | - Higher-precedence rules override lower ones; the resolution SHALL be recorded as |
| `POLICY-R09` | SHALL | 4. Rule Precedence | SHALL have the highest precedence; no subordinate rule may override a |
| `POLICY-R10` | SHALL | 4. Rule Precedence | - Precedence resolves *prioritizable* conflicts. It SHALL NOT be used to paper |
| `POLICY-R11` | SHALL | 5. Deadlock Detection and Exception Handling | An implementation SHALL: |
| `POLICY-R12` | SHALL | 5. Deadlock Detection and Exception Handling | 1. **Detect** the deadlock rather than loop — a reasoning agent SHALL bound its |
| `POLICY-R13` | SHALL | 5. Deadlock Detection and Exception Handling | 3. **Escalate** immediately to a human (Human-in-the-Loop). The agent SHALL NOT |
| `POLICY-R14` | MAY | 5. Deadlock Detection and Exception Handling | unaffected work MAY continue. |
| `POLICY-R15` | SHALL | 5. Deadlock Detection and Exception Handling | SHALL itself pass the Policy Consistency Check before it takes effect. |
| `POLICY-R16` | SHALL | 6. Validation Hooks | normative rule set SHALL be satisfiable. |
| `POLICY-R17` | SHALL | 6. Validation Hooks | - A model that cannot demonstrate satisfiability of its declared rules SHALL NOT |
| `POLICY-R18` | SHALL | 7. Architectural Invariants | - The normative rule set SHALL be satisfiable; contradictions SHALL be rejected |
| `POLICY-R19` | SHALL | 7. Architectural Invariants | - Constitutional rules SHALL have the highest precedence. |
| `POLICY-R20` | SHALL | 7. Architectural Invariants | - Precedence resolutions SHALL be recorded, never silent. |
| `POLICY-R21` | SHALL | 7. Architectural Invariants | - A policy deadlock SHALL trigger detection, an Event, and human escalation — |

## Provenance-Graph -- `02-architecture/Provenance-Graph.md`  (19 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `PROVEN-R01` | SHALL | 2. Scope | - the standard query patterns a conforming implementation SHALL support; |
| `PROVEN-R02` | SHALL | 3. Principles | - **Edges are explicit.** Provenance relationships SHALL be declared, not |
| `PROVEN-R03` | SHALL | 3. Principles | - **The graph is queryable.** Impact, dependency and justification SHALL be |
| `PROVEN-R04` | SHALL | 4. Node Types | The Provenance Graph SHALL recognize the following node types: |
| `PROVEN-R05` | SHALL | 4. Node Types | Every node SHALL carry a stable identity and the |
| `PROVEN-R06` | SHALL | 5. Edge Types | The Provenance Graph SHALL recognize the following directed edge types: |
| `PROVEN-R07` | SHALL | 5. Edge Types | (the rules in force). An edge SHALL be created as part of, or referenced by, an |
| `PROVEN-R08` | SHALL | 6. Relationship to Event Causality | A `derivedFrom` edge between two conclusions SHALL be consistent with the |
| `PROVEN-R09` | SHALL | 6. Relationship to Event Causality | conclusion A, the Event that asserted B SHALL causally follow the Event that |
| `PROVEN-R10` | SHALL | 7. Standard Query Patterns | A conforming implementation SHALL be able to answer the following over the |
| `PROVEN-R11` | SHALL | 7.1 Impact — "what breaks if X changes?" | changes and SHALL be re-evaluated. |
| `PROVEN-R12` | SHALL | 9. Federation Behavior | Across a federation, the Provenance Graph SHALL preserve traceability without |
| `PROVEN-R13` | MAY | 9. Federation Behavior | surrendering sovereignty. A `derivedFrom` edge MAY point to a Source in another |
| `PROVEN-R14` | SHALL | 9. Federation Behavior | Universe; that edge SHALL be disclosed only through a |
| `PROVEN-R15` | SHALL | 11. Architectural Invariants | - The Provenance Graph SHALL be append-only and backed by immutable Events. |
| `PROVEN-R16` | SHALL | 11. Architectural Invariants | - Provenance edges SHALL be explicit, never inferred silently. |
| `PROVEN-R17` | SHALL | 11. Architectural Invariants | - `derivedFrom` SHALL be consistent with Event causality. |
| `PROVEN-R18` | SHALL | 11. Architectural Invariants | - Impact, dependency and justification SHALL be answerable by traversal. |
| `PROVEN-R19` | SHALL | 11. Architectural Invariants | - Cross-Universe provenance SHALL NOT bypass Contracts and Projections. |

## Semantic-Migration -- `02-architecture/Semantic-Migration.md`  (39 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `SEMANT-R01` | SHALL | 1. Purpose | defines a **Migration Manifest**, and fixes the invariant that *meaning SHALL |
| `SEMANT-R02` | SHALL | 3. The Three Migration Levels | A migration SHALL be reasoned about at three distinct levels, which MAY progress |
| `SEMANT-R03` | MAY | 3. The Three Migration Levels | MAY be quiet: it does not, by itself, change meaning. |
| `SEMANT-R04` | SHALL | 3. The Three Migration Levels | change SHALL NOT be quiet (see Section 5). |
| `SEMANT-R05` | SHALL | 3. The Three Migration Levels | A complete migration SHALL address all three levels. Structural migration moves |
| `SEMANT-R06` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | A Migration SHALL be recorded as one or more immutable |
| `SEMANT-R07` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | applicable, *Lifecycle Event*). Each migration Event SHALL declare: |
| `SEMANT-R08` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | A Migration SHALL be: |
| `SEMANT-R09` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | - **traceable** — every change SHALL be followable from its source to its result |
| `SEMANT-R10` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | SHALL be recorded so the change can be understood and, where the mapping is |
| `SEMANT-R11` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | Corrections to a migration SHALL themselves be expressed as new migration Events |
| `SEMANT-R12` | SHALL | 4. Migration as a Traceable, Reversible-Explainable Operation | that reference the Event being corrected. A migration Event SHALL NOT be edited |
| `SEMANT-R13` | SHALL | 5. The No-Silent-Meaning-Change Rule | Meaning SHALL NOT change without an explicit migration event. |
| `SEMANT-R14` | SHALL | 5. The No-Silent-Meaning-Change Rule | of any concept SHALL be accompanied by a migration Event and a Migration |
| `SEMANT-R15` | SHALL | 5. The No-Silent-Meaning-Change Rule | - Renaming a concept SHALL produce a new Canonical Semantic Name (CSN); |
| `SEMANT-R16` | SHALL | 5. The No-Silent-Meaning-Change Rule | the old CSN SHALL NOT be silently rewritten, and the mapping old → new SHALL be |
| `SEMANT-R17` | SHALL | 5. The No-Silent-Meaning-Change Rule | documentation, file location) SHALL NOT change the fingerprint and MAY be |
| `SEMANT-R18` | SHALL | 6. The Migration Manifest | Every Semantic Migration SHALL be governed by a machine-readable **Migration |
| `SEMANT-R19` | SHALL | 6. The Migration Manifest | to the next. A Manifest SHALL contain: |
| `SEMANT-R20` | SHALL | 6. The Migration Manifest | Each entry in `conceptMappings` SHALL declare a **change kind**: `renamed`, |
| `SEMANT-R21` | SHALL | 6. The Migration Manifest | is unchanged need not appear; absence from `conceptMappings` SHALL mean *meaning |
| `SEMANT-R22` | SHALL | 6. The Migration Manifest | A Migration Manifest SHALL itself be expressible as MUIF |
| `SEMANT-R23` | SHALL | 7. Compatibility Classification | Every Migration SHALL declare a compatibility classification, aligned with the |
| `SEMANT-R24` | MAY | 7. Compatibility Classification | consume the target model without adaptation. The model fingerprint MAY change |
| `SEMANT-R25` | MAY | 7. Compatibility Classification | (for example a rename with a recorded CSN mapping); consumers MAY continue |
| `SEMANT-R26` | SHALL | 7. Compatibility Classification | in a way that loses distinctions; consumers SHALL adapt, guided by the |
| `SEMANT-R27` | SHALL | 7. Compatibility Classification | The classification SHALL be derivable from the `conceptMappings` and SHALL be |
| `SEMANT-R28` | SHALL | 8. Preservation of Canonical Identity | Migration SHALL NOT break **Canonical Identity**. |
| `SEMANT-R29` | SHALL | 8. Preservation of Canonical Identity | - The stable identity of an Object, Relationship, Event or Contract SHALL survive |
| `SEMANT-R30` | SHALL | 8. Preservation of Canonical Identity | - Where a concept is split, each resulting concept SHALL declare its derivation |
| `SEMANT-R31` | SHALL | 8. Preservation of Canonical Identity | SHALL reference each source identity it absorbs. |
| `SEMANT-R32` | SHALL | 8. Preservation of Canonical Identity | - Historical Events and prior versions SHALL |
| `SEMANT-R33` | SHALL | 8. Preservation of Canonical Identity | remain available and SHALL NOT be rewritten by migration. |
| `SEMANT-R34` | SHALL | 11. Architectural Invariants | - Meaning SHALL NOT change without an explicit migration Event. |
| `SEMANT-R35` | SHALL | 11. Architectural Invariants | - Every Semantic Migration SHALL be governed by a Migration Manifest. |
| `SEMANT-R36` | SHALL | 11. Architectural Invariants | - Migration Events SHALL be immutable; corrections SHALL be new Events. |
| `SEMANT-R37` | SHALL | 11. Architectural Invariants | - Canonical Identity SHALL survive migration unchanged. |
| `SEMANT-R38` | SHALL | 11. Architectural Invariants | - The compatibility classification SHALL be consistent with the change in |
| `SEMANT-R39` | SHALL | 11. Architectural Invariants | - Structural Migration MAY be quiet; Semantic Migration SHALL NOT be. |

## Simulation-Sandbox -- `02-architecture/Simulation-Sandbox.md`  (10 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `SIMULA-R01` | SHALL | 2. Definition | A Sandbox SHALL: |
| `SIMULA-R02` | MAY | 3. What a Simulation Does | Within a Sandbox an agent MAY: |
| `SIMULA-R03` | SHALL | 4. Isolation Guarantees | - A Sandbox SHALL NOT mutate any canonical Object, Relationship, Event, Contract |
| `SIMULA-R04` | SHALL | 4. Isolation Guarantees | - A Sandbox SHALL NOT emit federation messages to real partners; any federation |
| `SIMULA-R05` | SHALL | 4. Isolation Guarantees | it simulates SHALL use simulated counterparts. |
| `SIMULA-R06` | SHALL | 4. Isolation Guarantees | - Simulated Events SHALL be marked as simulation and SHALL NOT enter the |
| `SIMULA-R07` | SHALL | 6. Architectural Invariants | - Simulation SHALL NOT alter canonical state or real systems. |
| `SIMULA-R08` | SHALL | 6. Architectural Invariants | - A Sandbox SHALL be derived from an identified, fingerprinted model version. |
| `SIMULA-R09` | SHALL | 6. Architectural Invariants | - Simulation results SHALL be traceable and clearly marked as simulated. |
| `SIMULA-R10` | SHALL | 6. Architectural Invariants | - A successful simulation SHALL NOT auto-apply; it informs a human decision. |

## Traceability -- `02-architecture/Traceability.md`  (32 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `TRACE-R01` | SHALL | 3. Guiding Principles | Every conforming Meta-Model SHALL preserve: |
| `TRACE-R02` | SHALL | 3. Guiding Principles | Traceability SHALL be considered a first-class architectural concern. |
| `TRACE-R03` | SHALL | 4. Provenance | Every significant semantic fact SHALL declare its provenance. |
| `TRACE-R04` | SHOULD | 4. Provenance | At minimum, provenance SHOULD identify: |
| `TRACE-R05` | SHALL | 4. Provenance | Unknown provenance SHALL be explicitly indicated. |
| `TRACE-R06` | SHOULD | 5. Semantic Lineage | Provenance records *where a fact came from*. **Semantic Lineage** is broader: it records the **history of the origin of meaning** — the chain of facts, sourc... |
| `TRACE-R07` | SHALL | 5. Semantic Lineage | Given Semantic Lineage, an AI agent SHALL be able to answer, for any significant derived fact: |
| `TRACE-R08` | SHALL | 5. Semantic Lineage | Semantic Lineage builds directly on the Event primitive, since each derivation step SHOULD be expressed as an immutable, traceable Event, and on Dependency T... |
| `TRACE-R09` | SHALL | 6. Ownership Traceability | Ownership SHALL remain traceable throughout the lifecycle of every significant semantic fact. |
| `TRACE-R10` | SHOULD | 6. Ownership Traceability | Ownership history SHOULD preserve: |
| `TRACE-R11` | SHALL | 7. Version Traceability | Every versioned artifact SHALL preserve references to: |
| `TRACE-R12` | SHALL | 7. Version Traceability | Version history SHALL remain reconstructable. |
| `TRACE-R13` | SHALL | 8. Relationship Traceability | Relationships SHALL remain traceable independently from the objects they connect. |
| `TRACE-R14` | SHOULD | 8. Relationship Traceability | Relationship history SHOULD include: |
| `TRACE-R15` | SHALL | 9. Event Traceability | Events SHALL be immutable. |
| `TRACE-R16` | SHOULD | 9. Event Traceability | Every event SHOULD preserve: |
| `TRACE-R17` | SHALL | 9. Event Traceability | Events SHALL NOT be silently modified. |
| `TRACE-R18` | SHALL | 10. Projection Traceability | Every projection SHALL preserve a reference to its source object. |
| `TRACE-R19` | SHOULD | 10. Projection Traceability | Projection metadata SHOULD identify: |
| `TRACE-R20` | SHALL | 11. Dependency Traceability | Dependencies between semantic artifacts SHALL remain explicit. |
| `TRACE-R21` | SHOULD | 11. Dependency Traceability | A conforming implementation SHOULD be able to determine: |
| `TRACE-R22` | SHALL | 12. Federation Traceability | Federated interactions SHALL preserve traceability across universes. |
| `TRACE-R23` | SHOULD | 12. Federation Traceability | Federation history SHOULD identify: |
| `TRACE-R24` | SHOULD | 13. Auditability | Every significant semantic action SHOULD remain auditable. |
| `TRACE-R25` | SHOULD | 13. Auditability | Audit records SHOULD support reconstruction of: |
| `TRACE-R26` | SHOULD | 14. Historical Preservation | Historical semantic information SHOULD remain available even after objects evolve. |
| `TRACE-R27` | SHALL | 14. Historical Preservation | Historical records SHALL NOT be silently rewritten. |
| `TRACE-R28` | SHOULD | 14. Historical Preservation | Corrections SHOULD be represented as new traceable events rather than destructive updates. |
| `TRACE-R29` | SHALL | 15. Architectural Invariants | Traceability SHALL NEVER compromise: |
| `TRACE-R30` | SHALL | 15. Architectural Invariants | Conversely, federation SHALL NEVER remove traceability. |
| `TRACE-R31` | SHOULD | 16. Minimum Traceability Metadata | Every significant artifact SHOULD expose, directly or indirectly: |
| `TRACE-R32` | MAY | 16. Minimum Traceability Metadata | Additional metadata MAY be defined by domain-specific Meta-Models. |

## Validation -- `02-architecture/Validation.md`  (18 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `VAL-R01` | MAY | 5. Validation Levels | V0–V3 are **mandatory** for any MMAS-conformant model. V4 is required for any model that participates in federation. V5 is OPTIONAL and applies to running im... |
| `VAL-R02` | SHALL | 5a. Abstract Test Procedures | Each validation level is defined by a set of **Abstract Test Procedures (ATPs)** — checks that a conforming validator SHALL perform. Each check has a stable ... |
| `VAL-R03` | SHALL | V5 — Runtime *(optional)* | A validator MAY add checks, but SHALL implement at least the Error-severity checks of every level it claims to verify. |
| `VAL-R04` | SHALL | 6. Severity Classification | A validation result SHALL classify each finding by severity: |
| `VAL-R05` | SHOULD | 6. Severity Classification | - **Warning** — a concern that does not block conformance but SHOULD be addressed. |
| `VAL-R06` | SHALL | 7. Validation Report | A validation run SHALL produce a **Validation Report** that includes: |
| `VAL-R07` | SHALL | 7. Validation Report | For each level attempted, the report SHALL record the status of every ATP check (Section 5a) by check ID. The machine-readable structure is defined by `schem... |
| `VAL-R08` | MAY | 7. Validation Report | The report is itself a traceable artifact and MAY be referenced by a Conformance Statement or a Certificate. |
| `VAL-R09` | SHALL | 8. Validation of Imported Standards | When a meta-model imports an external standard as a Semantic Package, the imported package SHALL be validated: |
| `VAL-R10` | SHALL | 9. Continuous Validation | Validation SHALL be applied across the meta-model lifecycle: |
| `VAL-R11` | SHALL | 9. Continuous Validation | A change that lowers a model's achieved validation level SHALL be treated as a significant change under the Change Process. |
| `VAL-R12` | SHOULD | 9a. Outcome Drift Detection | > purpose unmet; the model's hypothesis SHOULD be revisited. |
| `VAL-R13` | SHALL | 9a. Outcome Drift Detection | Outcome Drift detection is part of optional **V5 (Runtime)** validation. It SHALL |
| `VAL-R14` | SHOULD | 9a. Outcome Drift Detection | drift SHOULD be recorded as an Event and surfaced |
| `VAL-R15` | SHALL | 11. Architectural Invariants | - Validation SHALL be layered (V0 through V5). |
| `VAL-R16` | SHALL | 11. Architectural Invariants | - A higher level SHALL assume the lower levels have passed. |
| `VAL-R17` | SHALL | 11. Architectural Invariants | - A model SHALL NOT claim a validation level it has not achieved. |
| `VAL-R18` | SHALL | 11. Architectural Invariants | - Every validation result SHALL be explainable and traceable. |

## Versioning -- `02-architecture/Versioning.md`  (28 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `VER-R01` | SHALL | 2. Scope | Every version SHALL be explicitly declared. |
| `VER-R02` | SHALL | 3. Versioning Principles | Versioning SHALL: |
| `VER-R03` | SHALL | 3. Versioning Principles | No published version SHALL be silently modified. |
| `VER-R04` | SHALL | 4. Independent Versioning | Each architectural element SHALL have its own lifecycle and version. |
| `VER-R05` | SHALL | 4. Independent Versioning | Updating one element SHALL NOT require changing unrelated versions. |
| `VER-R06` | SHOULD | 5. Semantic Versioning | Specifications SHOULD follow Semantic Versioning. |
| `VER-R07` | MAY | 5. Semantic Versioning | Implementations MAY adopt compatible internal schemes provided semantic meaning is preserved. |
| `VER-R08` | SHALL | 6. Version Identity | Every versioned artifact SHALL declare: |
| `VER-R09` | SHALL | 7. Semantic Fingerprint | A version number declares *intent*; a **Semantic Fingerprint** declares *identity of meaning*. Each published meta-model version SHALL carry a Semantic Finge... |
| `VER-R10` | SHALL | 7. Semantic Fingerprint | The fingerprint SHOULD be a cryptographic digest (for example `sha256`) of a canonical, deterministically serialized form of the semantic structure. Two arti... |
| `VER-R11` | SHOULD | 7. Semantic Fingerprint | A versioned artifact SHOULD declare its fingerprint alongside its version identity: |
| `VER-R12` | SHALL | 7. Semantic Fingerprint | The fingerprint SHALL be reproducible: any conforming implementation given the same semantic structure SHALL compute the same value. The exact canonical seri... |
| `VER-R13` | SHALL | 8. Compatibility | Every published version SHALL state its compatibility with previous versions. |
| `VER-R14` | SHOULD | 8. Compatibility | Compatibility SHOULD be classified as: |
| `VER-R15` | MAY | 9. Coexistence | Multiple versions MAY coexist simultaneously. |
| `VER-R16` | SHOULD | 9. Coexistence | Implementations SHOULD support explicit version negotiation whenever federation involves different versions. |
| `VER-R17` | SHOULD | 10. Deprecation | Artifacts SHOULD be deprecated before removal. |
| `VER-R18` | SHALL | 10. Deprecation | A deprecation notice SHALL identify: |
| `VER-R19` | SHALL | 11. Migration | Breaking changes SHALL include migration guidance. |
| `VER-R20` | SHOULD | 11. Migration | Migration documentation SHOULD describe: |
| `VER-R21` | SHALL | 12. Imported Standards | Imported semantic standards SHALL preserve their original version identifiers. |
| `VER-R22` | SHALL | 12. Imported Standards | Local extensions SHALL maintain an explicit mapping between imported versions and local extensions. |
| `VER-R23` | SHALL | 13. Historical Preservation | Historical versions SHALL remain identifiable and reproducible. |
| `VER-R24` | SHOULD | 13. Historical Preservation | Previous versions SHOULD remain publicly available whenever possible. |
| `VER-R25` | SHALL | 13. Historical Preservation | Historical versions SHALL NOT be rewritten. |
| `VER-R26` | SHOULD | 14. Version Negotiation | Federated universes SHOULD declare supported versions during capability discovery. |
| `VER-R27` | SHOULD | 14. Version Negotiation | If incompatible versions are detected, implementations SHOULD: |
| `VER-R28` | SHALL | 15. Architectural Invariants | Version changes SHALL NEVER invalidate: |

## Conflict-Resolution -- `03-federation/Conflict-Resolution.md`  (26 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `CONFL-R01` | SHALL | 3. Conflict Principles | Conflict handling SHALL be: |
| `CONFL-R02` | SHALL | 3. Conflict Principles | Conflicts SHALL NEVER be silently resolved. |
| `CONFL-R03` | SHALL | 4. Definition | Conflict detection SHALL precede resolution. |
| `CONFL-R04` | SHALL | 4a. Conflict Preservation | A semantic conflict SHALL be treated as a **first-class lifecycle object**, not as a transient error to be discarded once resolved. This is the principle of ... |
| `CONFL-R05` | SHALL | 4a. Conflict Preservation | Resolving a conflict SHALL NOT erase the fact that it occurred. The Historical Trace SHALL preserve the conflict's existence, its detection, the alternatives... |
| `CONFL-R06` | MAY | 4a. Conflict Preservation | Domain Meta-Models MAY define additional conflict categories. |
| `CONFL-R07` | SHOULD | 6. Conflict Detection | Implementations SHOULD detect conflicts through: |
| `CONFL-R08` | SHALL | 6. Conflict Detection | Detected conflicts SHALL be recorded. |
| `CONFL-R09` | SHOULD | 7. Resolution Strategy | Every step SHOULD remain auditable. |
| `CONFL-R10` | SHALL | 8. Authority | Resolution SHALL respect constitutional authority. |
| `CONFL-R11` | SHALL | 8. Authority | No participant SHALL overwrite another Universe's authoritative semantics. |
| `CONFL-R12` | SHOULD | 9. Escalation | If a conflict cannot be resolved deterministically, it SHOULD be escalated. |
| `CONFL-R13` | MAY | 9. Escalation | Escalation MAY involve: |
| `CONFL-R14` | SHALL | 9. Escalation | Escalation decisions SHALL be traceable. |
| `CONFL-R15` | SHALL | 10. Contracts | Semantic Contracts SHALL participate in conflict resolution. |
| `CONFL-R16` | MAY | 10. Contracts | Applicable Contracts MAY determine: |
| `CONFL-R17` | SHALL | 11. Historical Integrity | Resolution SHALL preserve historical evidence. |
| `CONFL-R18` | SHALL | 11. Historical Integrity | Conflicts SHALL NOT be resolved by deleting: |
| `CONFL-R19` | SHALL | 11. Historical Integrity | Corrections SHALL be represented by new traceable artifacts. |
| `CONFL-R20` | SHALL | 12. Traceability | Every conflict SHALL preserve: |
| `CONFL-R21` | SHOULD | 13. Validation | Implementations SHOULD validate: |
| `CONFL-R22` | SHALL | 13. Validation | Validation SHALL be repeatable and deterministic. |
| `CONFL-R23` | SHALL | 14. Security Principles | Conflict handling SHALL preserve: |
| `CONFL-R24` | SHALL | 14. Security Principles | Conflict resolution SHALL NOT justify additional knowledge disclosure. |
| `CONFL-R25` | SHALL | 15. Architectural Invariants | Conflict Resolution SHALL preserve: |
| `CONFL-R26` | SHALL | 15. Architectural Invariants | Resolution SHALL restore semantic coherence without transferring semantic authority. |

## Consent-and-Disclosure -- `03-federation/Consent-and-Disclosure.md`  (33 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `DISC-R01` | SHALL | 3. Disclosure Principles | Knowledge disclosure SHALL be: |
| `DISC-R02` | SHALL | 3. Disclosure Principles | Knowledge SHALL NEVER be disclosed implicitly. |
| `DISC-R03` | SHALL | 3a. The Negotiation of Knowledge | Disclosure within the Meta-Universe SHALL proceed as a *negotiation of knowledge*, not as a grant of *access to data*. The canonical sequence is: |
| `DISC-R04` | SHALL | 3a. The Negotiation of Knowledge | The schema is public; the specific data is the subject of negotiation; the outcome is a Projection generated for one purpose, never an open channel into a st... |
| `DISC-R05` | SHOULD | 3a. The Negotiation of Knowledge | A participating Universe SHOULD expose public semantic structure before exposing instance data. |
| `DISC-R06` | MAY | 3a. The Negotiation of Knowledge | Schema discovery MAY include: |
| `DISC-R07` | MAY | 3a. The Negotiation of Knowledge | Knowledge structure MAY be public even when no instance data is disclosed. |
| `DISC-R08` | SHALL | 5. Purpose | Every disclosure request SHALL declare its purpose. |
| `DISC-R09` | SHALL | 5. Purpose | Purpose SHALL participate in authorization. |
| `DISC-R10` | SHALL | 5. Purpose | A disclosure approved for one purpose SHALL NOT automatically authorize another purpose. |
| `DISC-R11` | SHALL | 6. Consent | Where applicable, disclosure SHALL require explicit consent from the governing authority. |
| `DISC-R12` | MAY | 6. Consent | Consent MAY originate from: |
| `DISC-R13` | SHALL | 6. Consent | Consent SHALL be identifiable and traceable. |
| `DISC-R14` | MAY | 7. Disclosure Levels | Implementations MAY classify disclosure, for example: |
| `DISC-R15` | SHALL | 7. Disclosure Levels | Classification SHALL be explicit. |
| `DISC-R16` | SHOULD | 8. Projection-Based Disclosure | Knowledge SHOULD be disclosed through Projections. |
| `DISC-R17` | MAY | 8. Projection-Based Disclosure | A Projection MAY: |
| `DISC-R18` | SHALL | 8. Projection-Based Disclosure | The canonical Meta-Object SHALL remain unchanged. |
| `DISC-R19` | SHOULD | 9. Least Knowledge Principle | Only the minimum semantic knowledge necessary for the declared purpose SHOULD be disclosed. |
| `DISC-R20` | SHALL | 9. Least Knowledge Principle | Access SHALL be evaluated per request rather than assumed globally. |
| `DISC-R21` | SHOULD | 10. Authorization | Authorization SHOULD consider: |
| `DISC-R22` | SHALL | 10. Authorization | Successful authentication alone SHALL NOT imply authorization. |
| `DISC-R23` | MAY | 11. Revocation | Disclosure rights MAY be revoked. |
| `DISC-R24` | SHALL | 11. Revocation | Revocation SHALL: |
| `DISC-R25` | SHALL | 11. Revocation | Previously disclosed historical knowledge SHALL remain governed by applicable Contracts. |
| `DISC-R26` | SHOULD | 12. Auditability | Every disclosure SHOULD preserve: |
| `DISC-R27` | SHALL | 12. Auditability | Audit records SHALL remain reconstructable. |
| `DISC-R28` | SHALL | 13. Federation | Federated disclosure SHALL preserve: |
| `DISC-R29` | SHALL | 13. Federation | Receiving Universes SHALL respect contractual disclosure obligations. |
| `DISC-R30` | SHOULD | 14. Validation | Implementations SHOULD validate: |
| `DISC-R31` | SHALL | 14. Validation | Validation SHALL precede disclosure. |
| `DISC-R32` | SHALL | 15. Architectural Invariants | Knowledge disclosure SHALL preserve: |
| `DISC-R33` | SHALL | 15. Architectural Invariants | Disclosure SHALL NEVER redefine semantic truth. |

## Discovery -- `03-federation/Discovery.md`  (12 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `DISCOV-R01` | SHALL | 2. Location | A Universe SHALL publish its Discovery Document as JSON at the well-known URI |
| `DISCOV-R02` | SHALL | 2. Location | The document SHALL be served as `application/json` and SHOULD be cacheable. It |
| `DISCOV-R03` | SHALL | 2. Location | SHALL contain only **public** metadata: discoverability of a schema SHALL NOT |
| `DISCOV-R04` | SHALL | 3. Contents | The Discovery Document SHALL validate against |
| `DISCOV-R05` | SHALL | 3. Contents | `schemas/discovery.schema.json` and SHALL |
| `DISCOV-R06` | MAY | 3. Contents | \| `universe.id` \| The publishing Universe's identifier; `universe.did` MAY carry a Decentralized Identifier. \| |
| `DISCOV-R07` | SHOULD | 4. Use in Federation | An initiator SHOULD fetch the Discovery Document before sending `Hello`. The |
| `DISCOV-R08` | MAY | 4. Use in Federation | and the `endpoints.mufp` to which the handshake is sent. An agent MAY compare |
| `DISCOV-R09` | SHALL | 4. Use in Federation | A Universe SHALL NOT rely on the Discovery Document for authentication or trust; |
| `DISCOV-R10` | SHALL | 6. Architectural Invariants | - The Discovery Document SHALL expose schema existence without exposing data. |
| `DISCOV-R11` | SHALL | 6. Architectural Invariants | - Published fingerprints SHALL match the corresponding published schemas. |
| `DISCOV-R12` | SHALL | 6. Architectural Invariants | - Discovery SHALL NOT be a substitute for trust or authorization. |

## Federation-Contracts -- `03-federation/Federation-Contracts.md`  (31 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `FEDC-R01` | SHALL | 1. Purpose | Federation SHALL NOT occur without an applicable Federation Contract unless explicitly permitted by public policy. |
| `FEDC-R02` | SHALL | 3. Federation Principles | Every Federation Contract SHALL be: |
| `FEDC-R03` | SHALL | 3a. The Two-Level Contract Model | The two levels SHALL be understood as follows: |
| `FEDC-R04` | SHALL | 3a. The Two-Level Contract Model | MUFP **extends** the base Semantic Contract model; it does not reinvent it. Every requirement stated in this document SHALL be read as an addition to, never ... |
| `FEDC-R05` | SHALL | 4. Contract Parties | Every Federation Contract SHALL identify: |
| `FEDC-R06` | SHALL | 4. Contract Parties | Party identities SHALL use canonical identities. |
| `FEDC-R07` | SHALL | 5. Purpose | Every Federation Contract SHALL define one or more explicit purposes. |
| `FEDC-R08` | SHALL | 5. Purpose | Knowledge SHALL only be exchanged within declared purposes. |
| `FEDC-R09` | SHALL | 6. Scope of Federation | The Contract SHALL specify the federation scope, including: |
| `FEDC-R10` | SHALL | 6. Scope of Federation | Undefined scope SHALL NOT be assumed. |
| `FEDC-R11` | SHALL | 7. Knowledge Disclosure | Federation Contracts SHALL define: |
| `FEDC-R12` | MAY | 7. Knowledge Disclosure | Schema discovery MAY be broader than data disclosure. |
| `FEDC-R13` | SHALL | 8. Trust | Every Federation Contract SHALL define the trust basis. |
| `FEDC-R14` | MAY | 8. Trust | Trust MAY rely on: |
| `FEDC-R15` | SHALL | 8. Trust | Trust SHALL remain auditable. |
| `FEDC-R16` | SHOULD | 9. Responsibilities | Contracts SHOULD allocate responsibilities including: |
| `FEDC-R17` | SHALL | 9. Responsibilities | Responsibilities SHALL remain explicit. |
| `FEDC-R18` | SHALL | 10. Version Compatibility | Contracts SHALL declare supported: |
| `FEDC-R19` | SHALL | 10. Version Compatibility | Version incompatibilities SHALL be negotiated before semantic exchange. |
| `FEDC-R20` | SHOULD | 11. Lifecycle | Lifecycle transitions SHOULD be represented by Events. |
| `FEDC-R21` | MAY | 12. Amendment | Contracts MAY evolve through versioned amendments. |
| `FEDC-R22` | SHALL | 12. Amendment | Historical versions SHALL remain reconstructable. |
| `FEDC-R23` | SHALL | 12. Amendment | Existing obligations SHALL remain traceable. |
| `FEDC-R24` | SHALL | 13. Federation Termination | Termination SHALL preserve: |
| `FEDC-R25` | SHALL | 13. Federation Termination | Termination SHALL NOT invalidate historical semantic exchanges. |
| `FEDC-R26` | SHALL | 14. Security Principles | Federation Contracts SHALL support: |
| `FEDC-R27` | SHALL | 14. Security Principles | Receiving Universes SHALL NOT assume rights beyond those explicitly granted. |
| `FEDC-R28` | SHOULD | 15. Validation | Implementations SHOULD validate: |
| `FEDC-R29` | SHALL | 15. Validation | Validation SHALL NOT alter published Contracts. |
| `FEDC-R30` | SHALL | 16. Architectural Invariants | Every Federation Contract SHALL preserve: |
| `FEDC-R31` | SHALL | 16. Architectural Invariants | Federation SHALL exchange semantic knowledge without transferring semantic authority. |

## Federation-Lifecycle -- `03-federation/Federation-Lifecycle.md`  (26 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `FEDL-R01` | SHALL | 1. Purpose | MUFP SHALL be understood as the protocol for the **evolution of trust relationships between sovereign semantic spaces** — not as a technical integration that... |
| `FEDL-R02` | SHALL | 3. Lifecycle Principles | Every federation lifecycle SHALL be: |
| `FEDL-R03` | SHOULD | 3. Lifecycle Principles | Every lifecycle transition SHOULD be represented by one or more Events. |
| `FEDL-R04` | MAY | 4. Canonical Federation Lifecycle | Domain implementations MAY extend this lifecycle while preserving semantic consistency. |
| `FEDL-R05` | MAY | 5. Discovery | Discovery MAY include: |
| `FEDL-R06` | SHALL | 5. Discovery | Discovery SHALL NOT require disclosure of protected knowledge. |
| `FEDL-R07` | SHALL | 6. Evaluation | Evaluation SHALL precede federation establishment. |
| `FEDL-R08` | SHOULD | 7. Negotiation | Negotiation SHOULD establish: |
| `FEDL-R09` | SHALL | 7. Negotiation | Successful negotiation SHALL be explicit. |
| `FEDL-R10` | SHOULD | 8. Establishment | Establishment SHOULD generate one or more Federation Events. |
| `FEDL-R11` | MAY | 9. Active Federation | During active federation participants MAY: |
| `FEDL-R12` | SHALL | 9. Active Federation | All activities SHALL remain within applicable Contracts. |
| `FEDL-R13` | MAY | 10. Evolution | Federation MAY evolve through: |
| `FEDL-R14` | SHALL | 10. Evolution | Evolution SHALL preserve historical traceability. |
| `FEDL-R15` | MAY | 11. Suspension | Federation MAY be temporarily suspended. |
| `FEDL-R16` | SHALL | 11. Suspension | Suspension SHALL: |
| `FEDL-R17` | SHALL | 11. Suspension | Suspension SHALL NOT terminate historical obligations. |
| `FEDL-R18` | MAY | 12. Termination | Federation MAY terminate due to: |
| `FEDL-R19` | SHALL | 12. Termination | Termination SHALL preserve: |
| `FEDL-R20` | SHALL | 13. Historical Preservation | Historical federation records SHALL remain reconstructable. |
| `FEDL-R21` | SHOULD | 13. Historical Preservation | Historical information SHOULD include: |
| `FEDL-R22` | SHALL | 13. Historical Preservation | Historical preservation SHALL outlive active federation. |
| `FEDL-R23` | SHOULD | 14. Validation | Implementations SHOULD validate: |
| `FEDL-R24` | SHALL | 14. Validation | Validation SHALL occur before every major lifecycle transition. |
| `FEDL-R25` | SHALL | 15. Architectural Invariants | The Federation Lifecycle SHALL preserve: |
| `FEDL-R26` | SHALL | 15. Architectural Invariants | Lifecycle transitions SHALL modify the federation relationship, not the ownership of semantic knowledge. |

## Federation-Profiles -- `03-federation/Federation-Profiles.md`  (24 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `FEDP-R01` | SHALL | 3. Definition | Profiles extend MUFP but SHALL NOT contradict MUC, MMAS or MUFP. |
| `FEDP-R02` | SHALL | 3a. From Specification to Ecosystem | The lower three layers are universal and SHALL remain so. Industry-specific and scenario-specific behaviour — Enterprise HR, Healthcare, Government, AI Agent... |
| `FEDP-R03` | MAY | 3a. From Specification to Ecosystem | - Organizations, consortia and communities MAY publish their own profiles **without changing the base standard**. |
| `FEDP-R04` | SHALL | 4. Design Principles | Every Federation Profile SHALL be: |
| `FEDP-R05` | SHOULD | 4. Design Principles | Profiles SHOULD minimize federation negotiation effort. |
| `FEDP-R06` | SHOULD | 5. Profile Components | A Federation Profile SHOULD define: |
| `FEDP-R07` | MAY | 6. Profile Categories | Communities MAY define additional profiles. |
| `FEDP-R08` | SHOULD | 7. Capability Declaration | Participating Universes SHOULD declare supported Federation Profiles during discovery. |
| `FEDP-R09` | SHOULD | 7. Capability Declaration | Capability declarations SHOULD include: |
| `FEDP-R10` | SHOULD | 7. Capability Declaration | Profile compatibility SHOULD be negotiated before federation begins. |
| `FEDP-R11` | SHALL | 8. Versioning | Federation Profiles SHALL use independent semantic versioning. |
| `FEDP-R12` | SHALL | 8. Versioning | Historical profile versions SHALL remain available for interoperability with legacy participants. |
| `FEDP-R13` | SHALL | 8. Versioning | Breaking profile changes SHALL require a new major version. |
| `FEDP-R14` | MAY | 9. Extension Model | Profiles MAY extend: |
| `FEDP-R15` | SHALL | 9. Extension Model | Extensions SHALL be additive whenever possible. |
| `FEDP-R16` | SHOULD | 10. Validation | Implementations SHOULD validate: |
| `FEDP-R17` | SHALL | 10. Validation | Failure to satisfy mandatory requirements SHALL prevent profile conformance. |
| `FEDP-R18` | SHALL | 11. Traceability | Every profile SHALL preserve: |
| `FEDP-R19` | SHALL | 11. Traceability | Profile evolution SHALL remain auditable. |
| `FEDP-R20` | SHALL | 12. Governance | Every Federation Profile SHALL identify its governing authority. |
| `FEDP-R21` | MAY | 12. Governance | Profiles MAY be maintained by: |
| `FEDP-R22` | SHALL | 12. Governance | Governance SHALL remain transparent. |
| `FEDP-R23` | SHALL | 13. Architectural Invariants | Every Federation Profile SHALL preserve: |
| `FEDP-R24` | SHALL | 13. Architectural Invariants | Profiles SHALL standardize federation behavior without redefining semantic truth. |

## Identity-Binding -- `03-federation/Identity-Binding.md`  (32 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `IDB-R01` | SHALL | 3. Architectural Principles | Identity Binding SHALL be: |
| `IDB-R02` | SHALL | 3. Architectural Principles | Binding SHALL NOT modify canonical identities. |
| `IDB-R03` | SHALL | 4. Canonical Identity | Every Meta-Object SHALL possess one canonical Identity within its authoritative Universe. |
| `IDB-R04` | SHALL | 4. Canonical Identity | Canonical identities SHALL remain immutable. |
| `IDB-R05` | MAY | 5. Local Identity | A participating Universe MAY assign a local identifier for operational purposes. |
| `IDB-R06` | SHALL | 5. Local Identity | - SHALL remain local; |
| `IDB-R07` | SHALL | 5. Local Identity | - SHALL reference the canonical identity; |
| `IDB-R08` | SHALL | 5. Local Identity | - SHALL NOT replace the canonical identity; |
| `IDB-R09` | SHALL | 5. Local Identity | - SHALL remain traceable. |
| `IDB-R10` | SHALL | 6. Identity Binding | Bindings SHALL identify: |
| `IDB-R11` | SHALL | 6a. No Global Identifier — Agreement Instead | The Meta-Universe SHALL NOT depend on any universal identifier shared by all participants, and no Universe SHALL be required to adopt another Universe's iden... |
| `IDB-R12` | SHALL | 6a. No Global Identifier — Agreement Instead | - Each Universe SHALL retain sole authority over its own canonical identities. |
| `IDB-R13` | MAY | 6a. No Global Identifier — Agreement Instead | - A Universe MAY decline to recognize any external identity; recognition is never automatic. |
| `IDB-R14` | SHALL | 6a. No Global Identifier — Agreement Instead | - Shared identity SHALL arise only through an explicit Identity Binding — a stated, mutual agreement that two identities refer to the same semantic entity. |
| `IDB-R15` | SHALL | 6a. No Global Identifier — Agreement Instead | - Every binding SHALL be versioned, traceable and governed by a Semantic Contract. |
| `IDB-R16` | MAY | 6a. No Global Identifier — Agreement Instead | Domain standards MAY define additional types. |
| `IDB-R17` | SHOULD | 8. Establishment | Identity Binding SHOULD follow this sequence: |
| `IDB-R18` | SHOULD | 9. Identity Resolution | Conforming implementations SHOULD resolve: |
| `IDB-R19` | MAY | 9. Identity Resolution | Resolution MAY require authorization. |
| `IDB-R20` | SHALL | 10. Federation | Federated Universes SHALL exchange canonical identities whenever practical. |
| `IDB-R21` | SHALL | 10. Federation | Where local identifiers are exchanged, corresponding Identity Bindings SHALL also be available. |
| `IDB-R22` | SHALL | 10. Federation | Federation SHALL preserve identity continuity. |
| `IDB-R23` | MAY | 11. Evolution | Bindings MAY evolve. |
| `IDB-R24` | SHALL | 11. Evolution | Changes SHALL be represented through new Events. |
| `IDB-R25` | SHALL | 11. Evolution | Historical bindings SHALL remain reconstructable. |
| `IDB-R26` | SHALL | 11. Evolution | Retiring a binding SHALL NOT alter historical references. |
| `IDB-R27` | SHOULD | 12. Validation | Implementations SHOULD validate: |
| `IDB-R28` | SHALL | 12. Validation | Validation SHALL NOT silently rewrite bindings. |
| `IDB-R29` | SHALL | 13. Security Principles | Identity Binding SHALL follow: |
| `IDB-R30` | MAY | 13. Security Principles | Identity metadata MAY be disclosed independently from protected object data. |
| `IDB-R31` | SHALL | 14. Architectural Invariants | Identity Binding SHALL preserve: |
| `IDB-R32` | SHALL | 14. Architectural Invariants | Binding SHALL NEVER imply transfer of semantic authority. |

## MUFP -- `03-federation/MUFP.md`  (31 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MUFP-R01` | SHALL | 1. Purpose | MUFP federates **knowledge, not data**. It is an instrument of *semantic diplomacy* rather than data transport. Before any datum is exchanged, the participat... |
| `MUFP-R02` | SHALL | 3. Design Principles | Federation SHALL be: |
| `MUFP-R03` | SHALL | 3. Design Principles | Federation SHALL NEVER transfer semantic sovereignty. |
| `MUFP-R04` | SHALL | 4. Constitutional Foundation | Every federated interaction SHALL preserve: |
| `MUFP-R05` | SHALL | 4. Constitutional Foundation | No federation activity SHALL violate constitutional principles. |
| `MUFP-R06` | SHALL | 5. Federation Model | Knowledge exchange SHALL occur through Projections governed by Semantic Contracts. |
| `MUFP-R07` | SHALL | 6. The Canonical Federation Sequence | MUFP defines a canonical eight-stage sequence through which a federation comes into being. The ordering is normative in intent: meaning, trust, rules and pur... |
| `MUFP-R08` | MAY | 6. The Canonical Federation Sequence | Implementations MAY optimize, parallelize or revisit stages provided the semantic guarantee holds: no protected knowledge is exchanged before meaning, trust,... |
| `MUFP-R09` | SHOULD | 7. Discovery | Federation SHOULD begin with public discovery. |
| `MUFP-R10` | SHOULD | 7. Discovery | A Universe SHOULD expose: |
| `MUFP-R11` | SHALL | 7. Discovery | Discovery SHALL NOT require disclosure of protected instance data. |
| `MUFP-R12` | SHOULD | 8. Capability Negotiation | Participating Universes SHOULD negotiate: |
| `MUFP-R13` | SHALL | 8. Capability Negotiation | Negotiation SHALL precede semantic exchange. |
| `MUFP-R14` | SHALL | 9. Trust | Trust SHALL be explicit. |
| `MUFP-R15` | MAY | 9. Trust | Trust MAY be established through: |
| `MUFP-R16` | SHALL | 9. Trust | Trust SHALL remain traceable. |
| `MUFP-R17` | SHALL | 10. Semantic Contracts | Every federation SHALL be governed by one or more Semantic Contracts. |
| `MUFP-R18` | SHALL | 10. Semantic Contracts | Contracts SHALL define: |
| `MUFP-R19` | SHALL | 10. Semantic Contracts | Contracts SHALL be versioned. |
| `MUFP-R20` | SHALL | 11. Projection Exchange | Participating Universes SHALL exchange Projections instead of transferring ownership of Meta-Objects. |
| `MUFP-R21` | SHALL | 11. Projection Exchange | Every Projection SHALL preserve: |
| `MUFP-R22` | SHOULD | 12. Version Compatibility | Federation participants SHOULD declare supported versions. |
| `MUFP-R23` | SHOULD | 12. Version Compatibility | If incompatible versions exist, implementations SHOULD: |
| `MUFP-R24` | SHALL | 12. Version Compatibility | Compatibility SHALL remain explicit. |
| `MUFP-R25` | SHALL | 13. Traceability | Every federation activity SHALL remain traceable. |
| `MUFP-R26` | SHOULD | 13. Traceability | Traceability SHOULD include: |
| `MUFP-R27` | SHALL | 14. Security Principles | Federation SHALL follow these principles: |
| `MUFP-R28` | SHALL | 14. Security Principles | Protected knowledge SHALL NOT be disclosed implicitly. |
| `MUFP-R29` | SHALL | 15. Failure Handling | Federation failures SHALL preserve: |
| `MUFP-R30` | SHALL | 15. Failure Handling | Partial federation SHALL be preferred over silent inconsistency. |
| `MUFP-R31` | SHALL | 17. Contrast with Data-Transfer Protocols | MUFP is frequently mistaken for an alternative to REST, GraphQL, gRPC or OData. It is not. Those technologies answer a single question — *"how is data transf... |

## MUFP-Messages -- `03-federation/MUFP-Messages.md`  (32 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MUFPM-R01` | SHOULD | 1. Purpose | A developer SHOULD be able to implement a minimal, interoperable MUFP endpoint |
| `MUFPM-R02` | SHALL | 4. The MUFP Envelope | - `messageId` SHALL be unique per sender; receivers SHALL treat re-delivery of |
| `MUFPM-R03` | SHALL | 4. The MUFP Envelope | - `inReplyTo` SHALL be present on every response and SHALL reference the request. |
| `MUFPM-R04` | SHALL | 4. The MUFP Envelope | - `federationId` SHALL be present once Establishment has occurred. |
| `MUFPM-R05` | MAY | 4. The MUFP Envelope | - `signature` is OPTIONAL in this version and is defined by the forthcoming |
| `MUFPM-R06` | SHALL | 5. State Machine | A responder SHALL reject any message that is not legal in the current state with |
| `MUFPM-R07` | SHALL | 5. State Machine | an `Error` of code `MUFP-E-STATE` (see §7). The protocol SHALL NOT skip stages: |
| `MUFPM-R08` | SHALL | 5. State Machine | for example, a `ProjectionRequest` received before `CONTRACTED` SHALL be refused. |
| `MUFPM-R09` | SHALL | 6. Message Catalog | SHALL be valid per MMAS-Interchange and |
| `MUFPM-R10` | SHALL | 6. Message Catalog | SHALL carry the Semantic Fingerprint required for verification. |
| `MUFPM-R11` | MAY | 7. Error Taxonomy | `MUFP-E-FINGERPRINT-MISMATCH` enforces `MUIF-R12`. An `Error` MAY cite the |
| `MUFPM-R12` | SHALL | 8. Version Negotiation | The responder SHALL select, for each, the highest version it also supports, and |
| `MUFPM-R13` | SHALL | 8. Version Negotiation | has no common version, the responder SHALL return `MUFP-E-VERSION-UNSUPPORTED` |
| `MUFPM-R14` | SHALL | 8. Version Negotiation | and the federation SHALL NOT proceed. |
| `MUFPM-R15` | MAY | 9. Identity Agreement and Revocation | a versioned, traceable Identity Agreement. Either party MAY later send `Revoke` |
| `MUFPM-R16` | SHALL | 9. Identity Agreement and Revocation | identity SHALL fail with `MUFP-E-REVOKED` until a new binding is established. |
| `MUFPM-R17` | SHALL | 9. Identity Agreement and Revocation | Revocation SHALL be recorded as an Event; |
| `MUFPM-R18` | SHALL | 9. Identity Agreement and Revocation | history SHALL be preserved (the binding is not erased, it is ended). |
| `MUFPM-R19` | SHALL | 10. HTTP/JSON Binding | This is one concrete, REQUIRED-to-interoperate binding. Other bindings (gRPC, |
| `MUFPM-R20` | MAY | 10. HTTP/JSON Binding | messaging) MAY be defined later. |
| `MUFPM-R21` | SHALL | 10. HTTP/JSON Binding | producer SHALL deliver `SyncEvent` envelopes by `POST` to that URL; otherwise |
| `MUFPM-R22` | MAY | 10. HTTP/JSON Binding | the consumer MAY poll by sending a `SyncEvent` request of its own with an empty |
| `MUFPM-R23` | SHALL | 10. HTTP/JSON Binding | `upTo`. Each `SyncEvent` SHALL be acknowledged with `SyncAck`. |
| `MUFPM-R24` | SHALL | 10. HTTP/JSON Binding | - **Idempotency:** receivers SHALL deduplicate by `messageId`. |
| `MUFPM-R25` | SHALL | 12. Conformance — Minimal Endpoint | A **minimal MUFP endpoint** (the basis for MUFP Level 1) SHALL: |
| `MUFPM-R26` | SHOULD | 13. Security Considerations | Until then, implementations SHOULD run the binding over authenticated TLS and |
| `MUFPM-R27` | SHOULD | 13. Security Considerations | SHOULD treat unsigned envelopes as unverified. |
| `MUFPM-R28` | SHALL | 14. Architectural Invariants | - Knowledge (a Projection) SHALL NOT be exchanged before `CONTRACTED` and a |
| `MUFPM-R29` | SHALL | 14. Architectural Invariants | - The protocol SHALL NOT skip stages of the canonical sequence. |
| `MUFPM-R30` | SHALL | 14. Architectural Invariants | - Every MUIF payload SHALL be fingerprint-verified on receipt. |
| `MUFPM-R31` | SHALL | 14. Architectural Invariants | - Revocation SHALL be possible at any time and SHALL be recorded as history. |
| `MUFPM-R32` | SHALL | 14. Architectural Invariants | - Protocol outcomes SHALL travel in the Envelope, not in transport status codes. |

## Security-Model -- `03-federation/Security-Model.md`  (38 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `SECURI-R01` | SHALL | 1. Purpose | threat model, the protections every implementation SHALL provide, the |
| `SECURI-R02` | SHALL | 2. Scope | mandates the properties that suite SHALL provide. |
| `SECURI-R03` | SHALL | 3. Security Principles | - **Trust is not security.** Security SHALL hold even when trust is high. |
| `SECURI-R04` | SHALL | 3. Security Principles | - **Verify, then use.** Every received artifact SHALL be authenticated and |
| `SECURI-R05` | SHALL | 3. Security Principles | - **Least knowledge by construction.** The protocol SHALL make over-disclosure |
| `SECURI-R06` | SHALL | 3. Security Principles | - **History is evidence.** Security-relevant events SHALL be recorded as |
| `SECURI-R07` | SHALL | 5. Threat Model | For each principal threat, the REQUIRED mitigation: |
| `SECURI-R08` | SHALL | 5. Threat Model | \| # \| Threat \| Mitigation (SHALL) \| |
| `SECURI-R09` | SHALL | 5. Threat Model | \| T3 \| **Poisoned Semantic Mapping** \| Mappings SHALL declare an authority and be fingerprint-pinned to specific model versions; a mapping that does not m... |
| `SECURI-R10` | SHALL | 5. Threat Model | \| T4 \| **Event / lineage poisoning** \| Events SHALL be immutable and provenance-signed; derived facts SHALL be recomputable from signed source Events. \| |
| `SECURI-R11` | SHALL | 5. Threat Model | \| T5 \| **Projection leakage / over-disclosure** \| No Projection SHALL be returned without an accepted Contract and a declared purpose; fields outside the ... |
| `SECURI-R12` | SHALL | 5. Threat Model | \| T6 \| **Replay** of a captured Envelope \| Envelopes SHALL carry a unique `messageId` and `sentAt`; receivers SHALL reject duplicates and stale timestamps... |
| `SECURI-R13` | SHALL | 5. Threat Model | \| T7 \| **Man-in-the-middle** on the channel \| The transport binding SHALL provide authenticated encryption (e.g. TLS); Envelopes SHOULD additionally be si... |
| `SECURI-R14` | SHALL | 5. Threat Model | \| T8 \| **Privilege escalation via stale trust/contract** \| Revocation SHALL take effect immediately and propagate (Section 8); references to revoked eleme... |
| `SECURI-R15` | SHALL | 5. Threat Model | \| T9 \| **Repudiation** \| Security-relevant actions (binding, disclosure, revocation) SHALL be recorded as signed Events, preserving non-repudiation. \| |
| `SECURI-R16` | SHOULD | 5. Threat Model | \| T10 \| **Denial of service** \| Endpoints SHOULD rate-limit (`MUFP-E-RATE-LIMITED`) and bound the cost of validation and fingerprinting. \| |
| `SECURI-R17` | SHOULD | 6. Envelope Authentication and Integrity | - Every MUFP Envelope SHOULD carry a |
| `SECURI-R18` | SHALL | 6. Envelope Authentication and Integrity | - A receiver SHALL verify the signature against a key bound to the `from` |
| `SECURI-R19` | SHALL | 6. Envelope Authentication and Integrity | identity before acting on the message. An unsigned envelope SHALL be treated |
| `SECURI-R20` | SHALL | 6. Envelope Authentication and Integrity | as **unverified** and SHALL NOT be used to disclose protected knowledge. |
| `SECURI-R21` | SHALL | 6. Envelope Authentication and Integrity | - Every MUIF payload inside a body SHALL independently pass fingerprint |
| `SECURI-R22` | SHALL | 7. Trust Vector Computation | single scalar. A policy SHALL define, per purpose, the minimum required score on |
| `SECURI-R23` | SHALL | 7. Trust Vector Computation | threshold. The decision SHALL record the vector and the policy applied, so it can |
| `SECURI-R24` | SHALL | 7. Trust Vector Computation | be explained, traced and revisited. Trust SHALL NOT be reduced to one averaged |
| `SECURI-R25` | SHALL | 8. Revocation and Propagation | - Revocation SHALL take effect on receipt and SHALL be recorded as an immutable |
| `SECURI-R26` | SHALL | 8. Revocation and Propagation | - After revocation, any reference to the revoked element SHALL fail with |
| `SECURI-R27` | SHALL | 8. Revocation and Propagation | `MUFP-E-REVOKED`, and the federation state machine SHALL downgrade to the state |
| `SECURI-R28` | SHALL | 8. Revocation and Propagation | - A party that has shared a revoked Projection downstream SHALL propagate the |
| `SECURI-R29` | SHOULD | 8. Revocation and Propagation | - Revocation propagation SHOULD be timely; the maximum propagation delay SHOULD |
| `SECURI-R30` | SHALL | 9. Privacy and Personal Data | - **Purpose binding.** Personal data SHALL be disclosed only for the explicit |
| `SECURI-R31` | SHOULD | 9. Privacy and Personal Data | SHOULD identify the data-subject role so that data-subject rights (access, |
| `SECURI-R32` | SHALL | 9. Privacy and Personal Data | disclosure happened and *that* it was later revoked; it SHALL NOT be used to |
| `SECURI-R33` | SHOULD | 10. Security Considerations for Federation Documents | Every document in `03-federation/` SHOULD carry a brief **Security |
| `SECURI-R34` | SHALL | 12. Architectural Invariants | - Security SHALL NOT depend on trust being high. |
| `SECURI-R35` | SHALL | 12. Architectural Invariants | - Every crossing artifact SHALL be authenticated and integrity-verified. |
| `SECURI-R36` | SHALL | 12. Architectural Invariants | - Revocation SHALL be immediate, recorded and propagated. |
| `SECURI-R37` | SHALL | 12. Architectural Invariants | - Personal data SHALL be purpose-bound and minimized. |
| `SECURI-R38` | SHALL | 12. Architectural Invariants | - The audit of a decision SHALL survive erasure of the data the decision concerned. |

## Semantic-Mapping -- `03-federation/Semantic-Mapping.md`  (29 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `MAP-R01` | SHALL | 3. Mapping Principles | Every Semantic Mapping SHALL be: |
| `MAP-R02` | SHALL | 3. Mapping Principles | Mappings SHALL describe semantic correspondence. |
| `MAP-R03` | SHALL | 3. Mapping Principles | They SHALL NOT redefine canonical meaning. |
| `MAP-R04` | SHOULD | 4a. The Canonical-Meaning Hub Model | The Meta-Universe SHOULD instead map each local semantics to a **canonical meaning** recognized by the federation parties. Each participant maintains mapping... |
| `MAP-R05` | SHALL | 4a. The Canonical-Meaning Hub Model | A canonical meaning MAY be an agreed neutral concept, or an external standard adopted as the reference (for example O*NET, ESCO, HR-XML or Schema.org). The h... |
| `MAP-R06` | SHOULD | 4b. The Semantic Mapping Registry | A Semantic Mapping Registry SHOULD hold reusable mappings such as those between O*NET, ESCO, HR-XML and Schema.org, each carrying its authority, version and ... |
| `MAP-R07` | SHALL | 4b. The Semantic Mapping Registry | Registry mappings SHALL remain subject to every requirement of this document — they are ordinary Semantic Mappings that happen to be published for reuse. |
| `MAP-R08` | MAY | 5. Mapping Types | Domain standards MAY introduce additional mapping types. |
| `MAP-R09` | SHOULD | 6. Mapping Components | Every Semantic Mapping SHOULD define: |
| `MAP-R10` | SHALL | 7. Mapping Authority | Every Mapping SHALL identify the authority responsible for publishing it. |
| `MAP-R11` | MAY | 7. Mapping Authority | Mappings MAY be authored by: |
| `MAP-R12` | SHALL | 7. Mapping Authority | Authority SHALL remain explicit. |
| `MAP-R13` | SHALL | 8. Version Compatibility | Mappings SHALL identify the versions of both participating semantic models. |
| `MAP-R14` | SHALL | 8. Version Compatibility | Mappings SHALL be reviewed whenever either side evolves. |
| `MAP-R15` | SHALL | 8. Version Compatibility | Historical mappings SHALL remain reconstructable. |
| `MAP-R16` | SHOULD | 9. Imported Standards | Mappings SHOULD be used when integrating external standards such as: |
| `MAP-R17` | SHALL | 9. Imported Standards | Imported concepts SHALL retain their original identities. |
| `MAP-R18` | MAY | 10. Transformation | Some mappings MAY require semantic transformation. |
| `MAP-R19` | SHALL | 10. Transformation | Transformation rules SHALL be: |
| `MAP-R20` | SHALL | 10. Transformation | Transformation SHALL NOT silently alter semantic meaning. |
| `MAP-R21` | SHOULD | 11. Federation | Federation participants SHOULD exchange canonical mappings before exchanging semantic knowledge. |
| `MAP-R22` | SHALL | 11. Federation | Mappings SHALL support Projection exchange without requiring schema duplication. |
| `MAP-R23` | SHOULD | 12. Validation | A conforming implementation SHOULD validate: |
| `MAP-R24` | SHOULD | 12. Validation | Mappings failing validation SHOULD NOT be used automatically. |
| `MAP-R25` | SHALL | 13. Traceability | Every Mapping SHALL preserve: |
| `MAP-R26` | SHALL | 13. Traceability | Traceability SHALL survive federation. |
| `MAP-R27` | SHALL | 14. Architectural Invariants | Every Semantic Mapping SHALL preserve: |
| `MAP-R28` | SHALL | 14. Architectural Invariants | Mappings SHALL connect meanings. |
| `MAP-R29` | SHALL | 14. Architectural Invariants | They SHALL NOT replace meanings. |

## Synchronization -- `03-federation/Synchronization.md`  (31 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `SYNC-R01` | SHALL | 3. Synchronization Principles | Synchronization SHALL be: |
| `SYNC-R02` | SHALL | 3. Synchronization Principles | Synchronization SHALL NEVER transfer semantic authority. |
| `SYNC-R03` | SHALL | 4. Definition | Synchronization SHALL preserve canonical Identity while allowing receiving Universes to maintain local operational representations. |
| `SYNC-R04` | SHALL | 4a. Three Kinds of Synchronization | MUFP SHALL synchronize Projections, Identity Bindings, Semantic Mappings, Events and Contracts. MUFP SHALL NOT replicate databases and SHALL NOT synchronize ... |
| `SYNC-R05` | SHALL | 4b. Semantic Coherence | Where this document says "synchronization", it SHALL be read as the pursuit of Semantic Coherence: a coherent, traceable, contract-governed alignment of shar... |
| `SYNC-R06` | SHALL | 5. Synchronization Model | The authoritative Universe SHALL remain the source of semantic truth. |
| `SYNC-R07` | SHALL | 5. Synchronization Model | Receiving Universes SHALL synchronize authorized Projections rather than maintaining independent authoritative copies. |
| `SYNC-R08` | MAY | 5. Synchronization Model | Synchronization MAY be: |
| `SYNC-R09` | SHOULD | 6. Synchronization Scope | Every synchronization process SHOULD define: |
| `SYNC-R10` | SHALL | 6. Synchronization Scope | Undefined scope SHALL NOT be assumed. |
| `SYNC-R11` | MAY | 7. Synchronization Triggers | Synchronization MAY be initiated by: |
| `SYNC-R12` | SHALL | 7. Synchronization Triggers | Triggers SHALL remain traceable. |
| `SYNC-R13` | SHOULD | 8. Event-Based Synchronization | Events SHOULD be the preferred synchronization mechanism. |
| `SYNC-R14` | MAY | 8. Event-Based Synchronization | Event Streams MAY be used to: |
| `SYNC-R15` | SHOULD | 8. Event-Based Synchronization | Receiving Universes SHOULD process Events in semantic order. |
| `SYNC-R16` | SHOULD | 9. Drift Detection | Participating Universes SHOULD detect semantic drift. |
| `SYNC-R17` | MAY | 9. Drift Detection | Drift MAY result from: |
| `SYNC-R18` | SHALL | 9. Drift Detection | Detected drift SHALL be recorded and evaluated. |
| `SYNC-R19` | SHALL | 10. Conflict Resolution | Synchronization conflicts SHALL NOT be resolved implicitly. |
| `SYNC-R20` | SHOULD | 10. Conflict Resolution | Conflict resolution SHOULD consider: |
| `SYNC-R21` | MAY | 10. Conflict Resolution | Manual escalation MAY be required. |
| `SYNC-R22` | SHALL | 11. Version Compatibility | Synchronization SHALL verify: |
| `SYNC-R23` | SHALL | 11. Version Compatibility | Incompatible synchronization SHALL be rejected or negotiated. |
| `SYNC-R24` | SHALL | 12. Traceability | Every synchronization activity SHALL preserve: |
| `SYNC-R25` | SHALL | 12. Traceability | Historical synchronization SHALL remain reconstructable. |
| `SYNC-R26` | SHALL | 13. Security Principles | Synchronization SHALL follow: |
| `SYNC-R27` | SHALL | 13. Security Principles | Receiving Universes SHALL receive only the knowledge authorized by applicable Contracts. |
| `SYNC-R28` | SHOULD | 14. Validation | Implementations SHOULD validate: |
| `SYNC-R29` | SHALL | 14. Validation | Validation SHALL precede synchronization. |
| `SYNC-R30` | SHALL | 15. Architectural Invariants | Projection Synchronization SHALL preserve: |
| `SYNC-R31` | SHALL | 15. Architectural Invariants | Synchronization SHALL synchronize representations, not semantic authority. |

## Trust-Model -- `03-federation/Trust-Model.md`  (32 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `TRUST-R01` | SHALL | 3. Trust Principles | Every trust relationship SHALL be: |
| `TRUST-R02` | SHALL | 3. Trust Principles | Trust SHALL NEVER be assumed implicitly. |
| `TRUST-R03` | SHALL | 4. Definition | Trust SHALL be based upon objective evidence rather than assumptions. |
| `TRUST-R04` | MAY | 4. Definition | Trust MAY differ depending on purpose, scope or context. |
| `TRUST-R05` | MAY | 5. Trust Participants | Trust relationships MAY exist between: |
| `TRUST-R06` | SHALL | 5. Trust Participants | Every participant SHALL possess a canonical Identity. |
| `TRUST-R07` | MAY | 6. Trust Evidence | Trust MAY be established using one or more forms of evidence, including: |
| `TRUST-R08` | MAY | 6. Trust Evidence | Additional evidence MAY be defined by domain-specific standards. |
| `TRUST-R09` | SHALL | 6a. The Trust Vector | Trust within the Meta-Universe SHALL NOT be modelled as a single binary or scalar value. Trust is **multidimensional**: a participant may be wholly trusted a... |
| `TRUST-R10` | SHALL | 6a. The Trust Vector | A Universe MAY, for example, fully trust another's *identity*, only partially trust its *semantic model*, decline to trust its *governance*, and trust only *... |
| `TRUST-R11` | SHALL | 6a. The Trust Vector | Domain-specific standards MAY add dimensions to the Trust Vector but SHALL NOT collapse the existing dimensions into a single value. |
| `TRUST-R12` | MAY | 7. Trust Levels | Trust **levels** classify the strength of trust *within a single dimension* of the Trust Vector; they are not a substitute for the Vector itself. Implementat... |
| `TRUST-R13` | SHALL | 7. Trust Levels | A participant therefore holds not one level but a level *per dimension* — for example, Authoritative Identity Trust together with Limited Governance Trust. T... |
| `TRUST-R14` | SHALL | 8. Purpose-Aware Trust | Trust SHALL be evaluated for a specific purpose. |
| `TRUST-R15` | SHALL | 8. Purpose-Aware Trust | A participant trusted for one purpose SHALL NOT automatically be trusted for another. |
| `TRUST-R16` | SHALL | 8. Purpose-Aware Trust | Purpose SHALL participate in authorization decisions. |
| `TRUST-R17` | MAY | 9. Context-Aware Trust | Trust MAY depend upon Context. |
| `TRUST-R18` | SHALL | 9. Context-Aware Trust | Context SHALL remain explicit. |
| `TRUST-R19` | SHOULD | 10. Trust Establishment | Trust establishment SHOULD be repeatable and auditable. |
| `TRUST-R20` | MAY | 11. Trust Evolution | Trust MAY evolve over time. |
| `TRUST-R21` | SHOULD | 11. Trust Evolution | Trust changes SHOULD be represented through Events. |
| `TRUST-R22` | SHALL | 11. Trust Evolution | Historical trust decisions SHALL remain reconstructable. |
| `TRUST-R23` | SHALL | 11. Trust Evolution | Trust SHALL support continuous reassessment. |
| `TRUST-R24` | MAY | 12. Trust Revocation | Trust MAY be revoked. |
| `TRUST-R25` | SHALL | 12. Trust Revocation | Revocation SHALL: |
| `TRUST-R26` | SHALL | 12. Trust Revocation | Revocation SHALL NOT invalidate historical federation activities. |
| `TRUST-R27` | SHALL | 13. Trust and Security | Trust SHALL complement, not replace, security. |
| `TRUST-R28` | SHALL | 13. Trust and Security | The two concepts SHALL remain independent. |
| `TRUST-R29` | SHOULD | 14. Validation | A conforming implementation SHOULD validate: |
| `TRUST-R30` | SHALL | 14. Validation | Validation SHALL remain deterministic and explainable. |
| `TRUST-R31` | SHALL | 15. Architectural Invariants | Every trust relationship SHALL preserve: |
| `TRUST-R32` | SHALL | 15. Architectural Invariants | Trust SHALL NEVER transfer semantic authority. |

## Context -- `04-core-concepts/Context.md`  (31 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `CTX-R01` | SHALL | 2. Definition | A Context is an explicit semantic frame that defines how information SHALL be interpreted. |
| `CTX-R02` | SHALL | 2. Definition | Context SHALL describe the circumstances surrounding knowledge rather than the knowledge itself. |
| `CTX-R03` | SHALL | 2. Definition | Without Context, semantic interpretation SHALL be considered incomplete. |
| `CTX-R04` | SHALL | 3. Context Principles | Every Context SHALL be: |
| `CTX-R05` | SHALL | 3. Context Principles | Context SHALL influence interpretation without modifying canonical identity. |
| `CTX-R06` | MAY | 4. Scope | Context MAY apply to: |
| `CTX-R07` | MAY | 4. Scope | Different Contexts MAY coexist for the same semantic artifact. |
| `CTX-R08` | MAY | 5. Context Dimensions | A Context MAY include one or more of the following dimensions: |
| `CTX-R09` | MAY | 5. Context Dimensions | Domain Meta-Models MAY define additional context dimensions. |
| `CTX-R10` | SHOULD | 6. Core Components | Every Context SHOULD define: |
| `CTX-R11` | SHALL | 7. Context and Identity | Context SHALL NEVER redefine canonical Identity. |
| `CTX-R12` | MAY | 7. Context and Identity | The same Meta-Object MAY participate in multiple Contexts while preserving a single canonical Identity. |
| `CTX-R13` | SHALL | 8. Context and Projection | Every Projection SHALL declare its Context. |
| `CTX-R14` | MAY | 8. Context and Projection | Different Contexts MAY produce different Projections of the same Meta-Object. |
| `CTX-R15` | SHALL | 8. Context and Projection | These Projections SHALL remain semantically traceable to the same source object. |
| `CTX-R16` | MAY | 9. Context and Contracts | Semantic Contracts MAY restrict or authorize Contexts. |
| `CTX-R17` | SHALL | 9. Context and Contracts | Knowledge disclosed under one Context SHALL NOT automatically be valid for another Context. |
| `CTX-R18` | SHOULD | 9. Context and Contracts | Purpose and Context SHOULD be evaluated together during authorization. |
| `CTX-R19` | MAY | 10. Context and Time | Context MAY vary over time. |
| `CTX-R20` | SHOULD | 10. Context and Time | Temporal Context SHOULD identify: |
| `CTX-R21` | SHALL | 10. Context and Time | Historical Context SHALL remain reconstructable. |
| `CTX-R22` | SHALL | 11. Federation | Federated Universes SHALL preserve Context whenever semantic interpretation depends upon it. |
| `CTX-R23` | SHALL | 11. Federation | If Context cannot be preserved, the receiving Universe SHALL be informed of the semantic limitation. |
| `CTX-R24` | SHALL | 11. Federation | Implicit Context assumptions SHALL be avoided. |
| `CTX-R25` | SHALL | 12. Traceability | Every Context SHALL preserve: |
| `CTX-R26` | SHALL | 12. Traceability | Context evolution SHALL remain auditable. |
| `CTX-R27` | SHOULD | 13. Validation | A conforming implementation SHOULD validate: |
| `CTX-R28` | SHALL | 13. Validation | Validation SHALL evaluate Context without altering it. |
| `CTX-R29` | SHALL | 14. Architectural Invariants | Every Context SHALL preserve: |
| `CTX-R30` | SHALL | 14. Architectural Invariants | Context SHALL interpret meaning. |
| `CTX-R31` | SHALL | 14. Architectural Invariants | It SHALL NOT replace meaning. |

## Contract -- `04-core-concepts/Contract.md`  (39 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `CON-R01` | SHALL | 2. Definition | A Contract SHALL define: |
| `CON-R02` | SHALL | 2. Definition | No semantic disclosure SHALL be assumed without an applicable Contract. |
| `CON-R03` | SHALL | 3. Contract Principles | Every Semantic Contract SHALL be: |
| `CON-R04` | SHALL | 3. Contract Principles | Contracts SHALL govern access to knowledge, not ownership of knowledge. |
| `CON-R05` | MAY | 4. Scope | Semantic Contracts MAY govern: |
| `CON-R06` | MAY | 4. Scope | Domain Meta-Models MAY define additional contract types. |
| `CON-R07` | SHOULD | 5. Core Components | Every Contract SHOULD define: |
| `CON-R08` | MAY | 6. Contract Types | Additional types MAY be introduced by domain standards. |
| `CON-R09` | SHALL | 7. Purpose | Every Contract SHALL declare an explicit purpose. |
| `CON-R10` | SHALL | 7. Purpose | Purpose SHALL participate in authorization decisions. |
| `CON-R11` | MAY | 7. Purpose | The same semantic knowledge MAY be disclosed under one purpose and denied under another. |
| `CON-R12` | SHALL | 7. Purpose | Purpose SHALL remain traceable. |
| `CON-R13` | SHALL | 8. Parties | Every Contract SHALL identify its participating parties. |
| `CON-R14` | MAY | 8. Parties | Participants MAY include: |
| `CON-R15` | SHALL | 8. Parties | Party identities SHALL be canonical. |
| `CON-R16` | SHALL | 9. Permissions and Restrictions | Contracts SHALL explicitly define: |
| `CON-R17` | SHALL | 9. Permissions and Restrictions | Implicit permissions SHALL NOT be assumed. |
| `CON-R18` | SHOULD | 9a. Executable Semantic Contract | A Semantic Contract SHOULD be capable of expression as an **Executable Semantic Contract** — an active control mechanism rather than a static document. Where... |
| `CON-R19` | SHOULD | 9a. Executable Semantic Contract | An Executable Semantic Contract SHOULD make machine-evaluable at least: |
| `CON-R20` | SHALL | 9a. Executable Semantic Contract | - **which fields are hidden** — attributes that SHALL NOT appear in any exposed Projection; |
| `CON-R21` | SHALL | 9a. Executable Semantic Contract | - **which events are sent to the owner** — the Events that SHALL be reported back to the owning Universe (for example access, derivation or redistribution); |
| `CON-R22` | SHALL | 9a. Executable Semantic Contract | - **which actions are forbidden** — operations the consuming party SHALL NOT perform on the licensed knowledge; |
| `CON-R23` | SHALL | 9a. Executable Semantic Contract | - **under which conditions the contract terminates** — the triggers (expiry, breach, revocation, purpose change) upon which the license ends and consumption ... |
| `CON-R24` | SHOULD | 9a. Executable Semantic Contract | An Executable Semantic Contract turns the contract from a description of intent into an enforced boundary: a conforming implementation SHOULD deny any exposu... |
| `CON-R25` | SHOULD | 10. Lifecycle | A Contract SHOULD progress through explicit lifecycle states such as: |
| `CON-R26` | SHOULD | 10. Lifecycle | Lifecycle transitions SHOULD be represented through Events. |
| `CON-R27` | SHALL | 11. Federation | Semantic federation SHALL rely upon Semantic Contracts. |
| `CON-R28` | SHALL | 11. Federation | Federation SHALL occur only within the scope defined by applicable Contracts. |
| `CON-R29` | SHALL | 11. Federation | Contracts SHALL preserve: |
| `CON-R30` | SHALL | 11. Federation | Federation SHALL NOT imply unrestricted knowledge sharing. |
| `CON-R31` | SHALL | 12. Traceability | Every Contract SHALL preserve: |
| `CON-R32` | SHALL | 12. Traceability | Traceability SHALL remain auditable. |
| `CON-R33` | MAY | 13. Versioning | Contracts MAY evolve through versioned revisions. |
| `CON-R34` | SHALL | 13. Versioning | Historical versions SHALL remain reconstructable. |
| `CON-R35` | SHALL | 13. Versioning | A new version SHALL NOT invalidate historical obligations retroactively unless explicitly governed by the Contract. |
| `CON-R36` | SHOULD | 14. Validation | A conforming implementation SHOULD validate: |
| `CON-R37` | SHALL | 14. Validation | Validation SHALL NOT modify published Contracts. |
| `CON-R38` | SHALL | 15. Architectural Invariants | Every Semantic Contract SHALL preserve: |
| `CON-R39` | SHALL | 15. Architectural Invariants | Contracts SHALL NEVER redefine the semantic meaning of exchanged knowledge. |

## Dimension -- `04-core-concepts/Dimension.md`  (25 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `DIM-R01` | MAY | 2. Definition | A Dimension is **not** a folder of objects. Two Dimensions within the same Universe MAY share the very same base objects — for example a single `Person` obje... |
| `DIM-R02` | MAY | 3. Relationship to Universe | A Universe MAY contain one or more Dimensions. |
| `DIM-R03` | SHALL | 3. Relationship to Universe | Every Dimension SHALL belong to exactly one Universe. |
| `DIM-R04` | SHALL | 3. Relationship to Universe | A Dimension SHALL NOT exist outside a Universe. |
| `DIM-R05` | SHALL | 5. Internal Structure | A Dimension SHALL contain one or more Namespaces. |
| `DIM-R06` | MAY | 6. Semantic Autonomy | A Dimension MAY define: |
| `DIM-R07` | SHALL | 6. Semantic Autonomy | Such rules SHALL remain compatible with the parent Universe and SHALL NOT violate MUC. |
| `DIM-R08` | SHALL | 7. Identity | Every Dimension SHALL possess: |
| `DIM-R09` | SHALL | 7. Identity | Identifiers SHALL remain stable throughout the Dimension lifecycle. |
| `DIM-R10` | SHALL | 8. Ownership | Every Dimension SHALL declare a responsible owner or steward. |
| `DIM-R11` | MAY | 8. Ownership | The owner MAY differ from the owner of the parent Universe. |
| `DIM-R12` | MAY | 8. Ownership | Responsibility for governance MAY be delegated while constitutional authority remains with the Universe. |
| `DIM-R13` | SHALL | 9. Namespace Management | Namespaces SHALL be managed within a Dimension. |
| `DIM-R14` | SHALL | 9. Namespace Management | Namespace uniqueness SHALL be guaranteed within the scope of the Dimension. |
| `DIM-R15` | MAY | 9. Namespace Management | Multiple Dimensions MAY contain namespaces with identical local names provided their fully-qualified semantic identities remain unique. |
| `DIM-R16` | SHALL | 10. Federation | Federation SHALL be established between Universes. |
| `DIM-R17` | MAY | 10. Federation | A Universe MAY selectively expose one or more Dimensions through federation. |
| `DIM-R18` | SHALL | 10. Federation | The decision to expose a Dimension SHALL be governed by the parent Universe. |
| `DIM-R19` | MAY | 11. Visibility | Dimensions MAY be classified as: |
| `DIM-R20` | SHALL | 11. Visibility | Visibility affects discoverability but SHALL NOT affect semantic identity. |
| `DIM-R21` | MAY | 12. Evolution | Dimensions MAY evolve independently. |
| `DIM-R22` | MAY | 12. Evolution | Evolution MAY include: |
| `DIM-R23` | SHALL | 12. Evolution | Evolution SHALL preserve identifier stability and constitutional compliance. |
| `DIM-R24` | SHALL | 14. Architectural Invariants | Every Dimension SHALL preserve: |
| `DIM-R25` | SHALL | 14. Architectural Invariants | A Dimension SHALL NEVER claim sovereignty independent of its parent Universe. |

## Event -- `04-core-concepts/Event.md`  (17 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `EVT-R01` | SHALL | 2. Definition | An Event SHALL: |
| `EVT-R02` | SHALL | 5. Components of an Event | Every Event SHALL declare: |
| `EVT-R03` | SHOULD | 5. Components of an Event | \| **Causality** \| References to the Events or facts that caused it (optional but RECOMMENDED). \| |
| `EVT-R04` | SHOULD | 6. Categories of Events | Events SHOULD be classified to support reasoning and federation: |
| `EVT-R05` | SHALL | 7. Temporal Model | Every Event SHALL be associated with at least one time: |
| `EVT-R06` | SHOULD | 7. Temporal Model | These MAY differ. A change in the real world may be recorded later, and the difference itself is semantically meaningful. Implementations SHOULD preserve bot... |
| `EVT-R07` | SHALL | 8. Identity, Provenance and Immutability | Each Event SHALL possess a stable Identity, independent of the entities it affects. |
| `EVT-R08` | SHALL | 8. Identity, Provenance and Immutability | Each Event SHALL declare its provenance: the actor, the authority under which it was asserted, and the source of the assertion. |
| `EVT-R09` | SHALL | 8. Identity, Provenance and Immutability | Once recorded, an Event SHALL NOT be modified or deleted. Corrections are themselves expressed as new Events that reference the Event being corrected. This p... |
| `EVT-R10` | MAY | 9. Causality | Events MAY reference the Events or facts that caused them, forming a causal graph. |
| `EVT-R11` | MAY | 10. Federation of Events | An Event MAY be disclosed to another Universe only: |
| `EVT-R12` | MAY | 11. Event Streams | Event Streams are the mechanism through which Universes observe meaningful change over time. A federated partner MAY subscribe — under contract — to a stream... |
| `EVT-R13` | SHALL | 14. Architectural Invariants | - Events SHALL be immutable. |
| `EVT-R14` | SHALL | 14. Architectural Invariants | - State SHALL be derivable from Events. |
| `EVT-R15` | SHALL | 14. Architectural Invariants | - Events SHALL declare provenance. |
| `EVT-R16` | SHALL | 14. Architectural Invariants | - Events SHALL NOT cross Universe boundaries without an explicit Semantic Contract. |
| `EVT-R17` | SHALL | 14. Architectural Invariants | - History SHALL NOT be rewritten; only appended to. |

## Identity -- `04-core-concepts/Identity.md`  (42 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `ID-R01` | SHALL | 2. Definition | Identity SHALL represent *what the entity is*, not *how it is described*. |
| `ID-R02` | SHALL | 2. Definition | Identity SHALL remain independent of: |
| `ID-R03` | SHALL | Local Identity | A Local Identity is *how the object appears inside a particular Universe*. A consuming Universe MAY assign its own local identifier when it references an ent... |
| `ID-R04` | MAY | Federated Identity Mapping | **Example.** `employee:12345` in a company Universe, `citizen:99821` in a government Universe, and `student:A-10455` in a university Universe MAY all be proj... |
| `ID-R05` | SHALL | Federated Identity Mapping | A Federated Identity Mapping SHALL be traceable, SHALL identify the governing authority, and SHALL remain revocable in accordance with the agreement that est... |
| `ID-R06` | SHALL | 3. Identity Principles | Every Identity SHALL satisfy the following principles: |
| `ID-R07` | SHALL | 3. Identity Principles | Identity SHALL NEVER encode business meaning that may change over time. |
| `ID-R08` | MAY | 4. Identity Scope | Domain-specific standards MAY introduce additional identity-bearing concepts. |
| `ID-R09` | SHALL | 5. Canonical Identity | Every identity SHALL consist of a canonical identifier. |
| `ID-R10` | SHALL | 5. Canonical Identity | Display names SHALL NOT be considered identifiers. |
| `ID-R11` | MAY | 6. Identity Lifecycle | An Identity MAY transition through the following lifecycle: |
| `ID-R12` | SHALL | 6. Identity Lifecycle | The identifier SHALL remain permanently reserved, even after retirement. |
| `ID-R13` | SHALL | 6. Identity Lifecycle | Identifiers SHALL NOT be reused. |
| `ID-R14` | SHALL | 7. Identity and Ownership | Identity SHALL remain independent from ownership. |
| `ID-R15` | MAY | 7. Identity and Ownership | Ownership MAY change. |
| `ID-R16` | SHALL | 7. Identity and Ownership | Identity SHALL NOT. |
| `ID-R17` | SHALL | 7. Identity and Ownership | Ownership transfers SHALL preserve the original identity. |
| `ID-R18` | SHALL | 8. Identity and Projection | A Projection SHALL reference the identity of its source object. |
| `ID-R19` | MAY | 8. Identity and Projection | Multiple projections MAY exist simultaneously. |
| `ID-R20` | SHALL | 8. Identity and Projection | All projections SHALL preserve the same canonical identity. |
| `ID-R21` | SHALL | 8. Identity and Projection | Projection-specific identifiers MAY exist locally but SHALL NOT replace the canonical identity. |
| `ID-R22` | SHALL | 9. Identity Across Federation | Federated Universes SHALL preserve canonical identities whenever referring to the same semantic entity. |
| `ID-R23` | SHALL | 9. Identity Across Federation | If local identifiers are required, explicit Federated Identity Mappings SHALL be maintained. |
| `ID-R24` | SHALL | 9. Identity Across Federation | Identity mappings SHALL remain traceable. |
| `ID-R25` | SHALL | 9. Identity Across Federation | Federation SHALL exchange Identity Agreements through MUFP. There SHALL be no central identity registry. The assertion that two Universes refer to the same e... |
| `ID-R26` | SHALL | 10. Imported Identities | Imported concepts SHALL preserve their original identities whenever possible. |
| `ID-R27` | MAY | 10. Imported Identities | Local identifiers MAY be introduced as aliases. |
| `ID-R28` | SHALL | 10. Imported Identities | Aliases SHALL explicitly reference the canonical identity. |
| `ID-R29` | SHALL | 10. Imported Identities | Imported identity SHALL remain authoritative. |
| `ID-R30` | SHOULD | 11. Identity Resolution | Conforming implementations SHOULD support identity resolution. |
| `ID-R31` | SHOULD | 11. Identity Resolution | Resolution SHOULD determine: |
| `ID-R32` | MAY | 11. Identity Resolution | Resolution MAY require authorization. |
| `ID-R33` | SHALL | 12. Identity Evolution | Identity SHALL survive: |
| `ID-R34` | SHALL | 12. Identity Evolution | Identity SHALL NOT survive semantic replacement by a different entity. |
| `ID-R35` | SHALL | 12. Identity Evolution | Replacement SHALL create a new identity. |
| `ID-R36` | SHALL | 13. Identity Collision | Two distinct semantic entities SHALL NEVER intentionally share the same canonical identity. |
| `ID-R37` | SHALL | 13. Identity Collision | If a collision is detected, it SHALL be resolved through governance and traceable correction procedures. |
| `ID-R38` | SHALL | 13. Identity Collision | Collision SHALL NEVER be resolved by silently changing historical identities. |
| `ID-R39` | SHOULD | 14. Identity Metadata | Every identity SHOULD expose: |
| `ID-R40` | MAY | 14. Identity Metadata | Additional metadata MAY be defined by domain-specific Meta-Models. |
| `ID-R41` | SHALL | 15. Architectural Invariants | Identity SHALL preserve: |
| `ID-R42` | SHALL | 15. Architectural Invariants | Identity SHALL NEVER depend upon implementation details. |

## Lifecycle -- `04-core-concepts/Lifecycle.md`  (30 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `LIFE-R01` | SHALL | 1a. Three Independent Times | A single Meta-Object does not advance along one timeline but along **three independent times**, which SHALL NOT be conflated: |
| `LIFE-R02` | MAY | 1a. Three Independent Times | These three times run in parallel and combine freely. One Meta-Object MAY, at the same instant, be **Active** as an object, carry an **active version 3.2**, ... |
| `LIFE-R03` | SHALL | 1a. Three Independent Times | Every transition in each of the three times SHALL be recorded through the Event primitive on the Semantic Timeline, so that the three histories remain indepe... |
| `LIFE-R04` | MAY | 2. Scope | Domain Meta-Models MAY define additional lifecycle states and transitions. |
| `LIFE-R05` | SHALL | 3. Lifecycle Principles | Every Lifecycle SHALL be: |
| `LIFE-R06` | SHALL | 3. Lifecycle Principles | Lifecycle SHALL describe semantic state rather than implementation state. |
| `LIFE-R07` | MAY | 4. Canonical Lifecycle | Domain-specific models MAY omit or extend intermediate states while preserving semantic consistency. |
| `LIFE-R08` | SHALL | Retired | The artifact is no longer active and SHALL NOT be reused. |
| `LIFE-R09` | SHALL | Retired | Retirement SHALL NOT invalidate historical references. |
| `LIFE-R10` | SHALL | 6. Lifecycle Transitions | Transitions SHALL occur through explicit Events. |
| `LIFE-R11` | SHALL | 6. Lifecycle Transitions | Silent state transitions SHALL NOT occur. |
| `LIFE-R12` | SHALL | 7. Identity | Lifecycle transitions SHALL NEVER modify canonical Identity. |
| `LIFE-R13` | MAY | 8. Ownership | Ownership MAY change during the lifecycle. |
| `LIFE-R14` | SHALL | 8. Ownership | Ownership changes SHALL be represented through traceable Events. |
| `LIFE-R15` | SHALL | 8. Ownership | Ownership changes SHALL NOT affect Identity. |
| `LIFE-R16` | MAY | 9. Versioning | A new version MAY remain in Draft while an older version remains Active. |
| `LIFE-R17` | SHALL | 9. Versioning | Version history SHALL remain reconstructable. |
| `LIFE-R18` | SHALL | 9. Versioning | The Object Lifecycle, the Version Lifecycle and the Projection Lifecycle SHALL each be tracked independently. A transition in one SHALL NOT imply a transitio... |
| `LIFE-R19` | SHALL | 10. Traceability | Every lifecycle transition SHALL preserve: |
| `LIFE-R20` | SHALL | 10. Traceability | Lifecycle history SHALL remain auditable. |
| `LIFE-R21` | MAY | 11. Federation | Lifecycle state MAY influence federation. |
| `LIFE-R22` | SHOULD | 11. Federation | Federation participants SHOULD evaluate lifecycle state before consuming semantic artifacts. |
| `LIFE-R23` | MAY | 11. Federation | Retired or Deprecated artifacts MAY still be exchanged for historical or analytical purposes. |
| `LIFE-R24` | SHOULD | 12. Validation | A conforming implementation SHOULD validate: |
| `LIFE-R25` | SHALL | 12. Validation | Validation SHALL evaluate lifecycle behavior without modifying historical records. |
| `LIFE-R26` | SHALL | 13. Historical Preservation | Historical lifecycle states SHALL remain reconstructable. |
| `LIFE-R27` | SHALL | 13. Historical Preservation | Archived and Retired artifacts SHALL preserve: |
| `LIFE-R28` | SHALL | 13. Historical Preservation | Historical integrity SHALL take precedence over physical deletion. |
| `LIFE-R29` | SHALL | 14. Architectural Invariants | Lifecycle SHALL preserve: |
| `LIFE-R30` | SHALL | 14. Architectural Invariants | Lifecycle SHALL govern state, not truth. |

## Namespace -- `04-core-concepts/Namespace.md`  (30 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `NS-R01` | SHALL | 1a. The Three Governance Axes | Whereas the Universe answers *who governs* and the Dimension answers *in which context*, the Namespace answers *how concepts are organized, named and made di... |
| `NS-R02` | SHALL | 2. Historical Note | Beginning with Meta-Universe v2, the term **Namespace** SHALL be used. |
| `NS-R03` | SHALL | 3. Definition | Namespaces are logical constructs and SHALL NOT imply physical storage. |
| `NS-R04` | SHALL | 4. Relationship to Higher Levels | A Namespace SHALL belong to one and only one Dimension. |
| `NS-R05` | SHALL | 5. Responsibilities | A Namespace SHALL: |
| `NS-R06` | SHALL | 5. Responsibilities | Namespaces SHALL NOT define constitutional rules. |
| `NS-R07` | SHALL | 6. Identity | Every Namespace SHALL declare: |
| `NS-R08` | SHALL | 6. Identity | Identifiers SHALL remain stable. |
| `NS-R09` | SHOULD | 7. Canonical Naming | Every public concept SHOULD be referenced using its canonical semantic name. |
| `NS-R10` | SHALL | 7. Canonical Naming | Canonical names SHALL remain stable across compatible versions. |
| `NS-R11` | SHALL | 8. Ownership | Every Namespace SHALL have a responsible owner or steward. |
| `NS-R12` | MAY | 8. Ownership | Ownership MAY be delegated by the governing Dimension. |
| `NS-R13` | SHOULD | 9. Public Schema | A Namespace SHOULD expose a public schema describing: |
| `NS-R14` | SHALL | 9. Public Schema | Publishing a schema SHALL NOT imply disclosure of instance data. |
| `NS-R15` | MAY | 10. Imports | Namespaces MAY import concepts from external standards or other Namespaces. |
| `NS-R16` | SHALL | 10. Imports | Imported concepts SHALL preserve: |
| `NS-R17` | SHALL | 10. Imports | Local extensions SHALL be additive and SHALL NOT redefine imported semantics. |
| `NS-R18` | SHOULD | 11. Federation | Federation SHOULD exchange canonical namespace references and semantic mappings. |
| `NS-R19` | SHALL | 11. Federation | Equivalent concepts in different Namespaces SHALL be connected through explicit mappings rather than duplicate definitions. |
| `NS-R20` | SHALL | 11a. Unit of Publication and Discovery | - SHALL be the artifact that is **published to registries**; |
| `NS-R21` | SHALL | 11a. Unit of Publication and Discovery | - SHALL be the artifact **imported by other meta-models**; |
| `NS-R22` | SHALL | 11a. Unit of Publication and Discovery | - SHALL carry its own **Semantic Fingerprint**, identifying its semantic content independently of its name; |
| `NS-R23` | SHALL | 11a. Unit of Publication and Discovery | - SHALL be capable of passing **MMAS Validation** as a coherent, self-describing unit; |
| `NS-R24` | SHALL | 11a. Unit of Publication and Discovery | - SHALL **federate via MUFP**, exchanging canonical namespace references, Semantic Fingerprints and semantic mappings. |
| `NS-R25` | SHALL | 11a. Unit of Publication and Discovery | Because the Namespace is what other parties import and depend upon, it SHALL remain self-contained with respect to its declared imports, provenance and versi... |
| `NS-R26` | MAY | 12. Evolution | Namespaces MAY evolve independently. |
| `NS-R27` | MAY | 12. Evolution | Compatible evolution MAY include: |
| `NS-R28` | SHALL | 12. Evolution | Breaking changes SHALL follow the Meta-Universe Change Process. |
| `NS-R29` | SHALL | 14. Architectural Invariants | Every Namespace SHALL preserve: |
| `NS-R30` | SHALL | 14. Architectural Invariants | Namespace evolution SHALL NEVER invalidate existing semantic identities. |

## Object -- `04-core-concepts/Object.md`  (40 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `OBJ-R01` | SHALL | 1. Purpose | Every meaningful entity represented within a Meta-Universe SHALL be modeled as a Meta-Object or as a specialization of a Meta-Object. |
| `OBJ-R02` | SHALL | 2. Definition | A Meta-Object SHALL NEVER be copied between Universes. When an entity owned by one Universe is needed by another, only Projections cross the boundary — each ... |
| `OBJ-R03` | SHALL | 2a. Not a Database Record | A conforming implementation SHALL treat the Meta-Object as the architectural point of truth and SHALL NOT conflate it with any physical storage of its attrib... |
| `OBJ-R04` | SHALL | 3. Object Principles | Every Meta-Object SHALL satisfy the following principles: |
| `OBJ-R05` | MAY | 4. Object Categories | Domain Meta-Models MAY define additional categories. |
| `OBJ-R06` | SHALL | 5. Identity | Every Meta-Object SHALL possess one canonical Identity. |
| `OBJ-R07` | SHALL | 5. Identity | Identity SHALL: |
| `OBJ-R08` | SHALL | 5. Identity | Identity SHALL NOT encode mutable business meaning. |
| `OBJ-R09` | SHALL | 6. Ownership | Every Meta-Object SHALL have an authoritative owner. |
| `OBJ-R10` | SHALL | 6. Ownership | Ownership SHALL remain explicitly traceable. |
| `OBJ-R11` | MAY | 6. Ownership | Ownership MAY be delegated without changing object identity. |
| `OBJ-R12` | SHALL | 7. Lifecycle | Every Meta-Object SHALL possess a lifecycle. |
| `OBJ-R13` | MAY | 7. Lifecycle | Domain Meta-Models MAY introduce additional states. |
| `OBJ-R14` | SHALL | 7. Lifecycle | Lifecycle SHALL remain explicit. |
| `OBJ-R15` | MAY | 8. Properties | Meta-Objects MAY contain Properties. |
| `OBJ-R16` | SHALL | 8. Properties | Properties SHALL NOT redefine object identity. |
| `OBJ-R17` | SHALL | 8. Properties | Property evolution SHALL remain traceable. |
| `OBJ-R18` | MAY | 9. Relationships | Meta-Objects MAY participate in Relationships. |
| `OBJ-R19` | SHALL | 9. Relationships | Relationships SHALL be first-class semantic artifacts. |
| `OBJ-R20` | MAY | 9. Relationships | Relationships MAY possess: |
| `OBJ-R21` | SHALL | 9. Relationships | Relationships SHALL NOT be represented merely as implementation references. |
| `OBJ-R22` | SHOULD | 10. Events | Every significant change affecting a Meta-Object SHOULD be represented as an Event. |
| `OBJ-R23` | MAY | 11. Projections | A Meta-Object MAY have zero or more Projections. |
| `OBJ-R24` | SHALL | 11. Projections | All Projections SHALL reference the same canonical Identity. |
| `OBJ-R25` | SHALL | 12. Traceability | Every Meta-Object SHALL preserve: |
| `OBJ-R26` | SHALL | 12. Traceability | Traceability SHALL survive federation. |
| `OBJ-R27` | MAY | 13. Federation | A Meta-Object MAY participate in federation. |
| `OBJ-R28` | SHALL | 13. Federation | Federation SHALL exchange semantic Projections rather than transferring ownership of the Meta-Object. A Meta-Object SHALL NEVER be copied between Universes. |
| `OBJ-R29` | SHALL | 13. Federation | Each Projection exchanged across a boundary SHALL reference exactly one Meta-Object, linked through its Canonical Identity and governed by the applicable fed... |
| `OBJ-R30` | SHALL | 13. Federation | The authoritative Universe SHALL remain the source of truth for the canonical object. |
| `OBJ-R31` | SHOULD | 14. Public Metadata | Every public Meta-Object SHOULD expose at least: |
| `OBJ-R32` | MAY | 14. Public Metadata | Additional metadata MAY require authorization. |
| `OBJ-R33` | SHALL | 15. Imported Objects | Objects imported from external standards SHALL preserve: |
| `OBJ-R34` | MAY | 15. Imported Objects | Imported objects MAY be locally extended. |
| `OBJ-R35` | SHALL | 15. Imported Objects | Extensions SHALL remain additive. |
| `OBJ-R36` | SHALL | 16. Object Replacement | Replacing one Meta-Object with another SHALL create a new Identity. |
| `OBJ-R37` | SHALL | 16. Object Replacement | Historical references SHALL continue to reference the original object. |
| `OBJ-R38` | SHALL | 16. Object Replacement | Replacement SHALL remain explicitly traceable. |
| `OBJ-R39` | SHALL | 17. Architectural Invariants | Every Meta-Object SHALL preserve: |
| `OBJ-R40` | SHALL | 17. Architectural Invariants | Implementations SHALL distinguish between the Meta-Object itself and any of its Projections. |

## Projection -- `04-core-concepts/Projection.md`  (33 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `PROJ-R01` | MAY | 1b. Federation Without Loss of Sovereignty | One Meta-Object MAY carry many Projections at once, for example: |
| `PROJ-R02` | SHALL | 1b. Federation Without Loss of Sovereignty | All such Projections SHALL reference the **same Canonical Identity**, SHALL be governed by **Semantic Contracts**, and SHALL exist for **different declared P... |
| `PROJ-R03` | SHALL | 2. Definition | A Projection SHALL: |
| `PROJ-R04` | SHALL | 3. Projection Principles | Every Projection SHALL be: |
| `PROJ-R05` | MAY | 3. Projection Principles | Different Projections MAY legitimately expose different subsets or interpretations of the same Meta-Object. |
| `PROJ-R06` | SHALL | 4. Relationship to Meta-Object | Every Projection SHALL reference one canonical Meta-Object. |
| `PROJ-R07` | SHALL | 4. Relationship to Meta-Object | A Projection SHALL NEVER redefine: |
| `PROJ-R08` | SHALL | 5. Projection Context | Every Projection SHALL declare its context. |
| `PROJ-R09` | SHALL | 5. Projection Context | Context SHALL be explicit. |
| `PROJ-R10` | SHALL | 6. Purpose | Every Projection SHALL declare its intended purpose. |
| `PROJ-R11` | MAY | 7. Projection Profiles | Projection behavior MAY be standardized through Projection Profiles. |
| `PROJ-R12` | SHOULD | 7. Projection Profiles | A Projection Profile SHOULD define: |
| `PROJ-R13` | SHOULD | 7. Projection Profiles | Profiles SHOULD be reusable. |
| `PROJ-R14` | SHALL | 8. Identity | Every Projection SHALL preserve the canonical Identity of its source Meta-Object. |
| `PROJ-R15` | MAY | 8. Identity | Projection-specific identifiers MAY exist locally. |
| `PROJ-R16` | SHALL | 8. Identity | Local identifiers SHALL NOT replace the canonical Identity. |
| `PROJ-R17` | SHALL | 9. Ownership | Ownership of a Projection SHALL remain traceable. |
| `PROJ-R18` | MAY | 9. Ownership | Delegated stewardship MAY be recorded without changing semantic authority. |
| `PROJ-R19` | SHOULD | 10. Lifecycle | A Projection SHOULD have an explicit lifecycle. |
| `PROJ-R20` | SHOULD | 10. Lifecycle | Lifecycle transitions SHOULD be represented through Events. |
| `PROJ-R21` | SHOULD | 11. Federation | Federation SHOULD exchange Projections rather than Meta-Objects. |
| `PROJ-R22` | SHALL | 11. Federation | A receiving Universe SHALL treat the Projection as a context-specific representation rather than an authoritative replacement. |
| `PROJ-R23` | SHALL | 12. Disclosure | Projection disclosure SHALL be governed by Semantic Contracts. |
| `PROJ-R24` | MAY | 12. Disclosure | Contracts MAY define: |
| `PROJ-R25` | SHALL | 12. Disclosure | Disclosure SHALL always be purpose-driven. |
| `PROJ-R26` | SHALL | 13. Traceability | Every Projection SHALL preserve: |
| `PROJ-R27` | SHALL | 13. Traceability | Traceability SHALL remain reconstructable. |
| `PROJ-R28` | MAY | 14. Evolution | A Projection MAY evolve independently from other Projections of the same Meta-Object. |
| `PROJ-R29` | SHALL | 14. Evolution | Evolution SHALL NOT invalidate the canonical Identity or semantic authority of the source Meta-Object. |
| `PROJ-R30` | SHALL | 14. Evolution | Changes SHALL remain versioned and traceable. |
| `PROJ-R31` | SHOULD | 15. Validation | A conforming implementation SHOULD validate: |
| `PROJ-R32` | SHALL | 16. Architectural Invariants | Every Projection SHALL preserve: |
| `PROJ-R33` | SHALL | 16. Architectural Invariants | A Projection SHALL NEVER become the semantic authority over its source Meta-Object. |

## Relationship -- `04-core-concepts/Relationship.md`  (33 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `REL-R01` | SHALL | 2. Definition | A Relationship SHALL describe meaning rather than implementation. |
| `REL-R02` | SHALL | 2. Definition | Implementation-specific references, foreign keys or graph edges SHALL NOT be considered semantic relationships unless they explicitly represent semantic mean... |
| `REL-R03` | SHALL | 3. Relationship Principles | Every Relationship SHALL: |
| `REL-R04` | SHOULD | 4. Core Components | Every Relationship SHOULD define: |
| `REL-R05` | MAY | 4. Core Components | Additional metadata MAY be defined by domain Meta-Models. |
| `REL-R06` | MAY | 5. Relationship Types | Domain Meta-Models MAY introduce additional relationship types. |
| `REL-R07` | MAY | 5a. Relationship Profile | A **Relationship Profile** is a standardized, reusable class of relation that MAY be shared across meta-models so that the same connection means the same thi... |
| `REL-R08` | SHALL | 5a. Relationship Profile | A Relationship Profile SHOULD define its semantic meaning, expected source and target categories, default cardinality and typical temporal behavior. Meta-Mod... |
| `REL-R09` | SHALL | 6. Cardinality | Relationship cardinality SHALL be explicit whenever applicable. |
| `REL-R10` | SHALL | 6. Cardinality | Cardinality SHALL describe semantics rather than database implementation. |
| `REL-R11` | SHALL | 7. Identity | Every significant Relationship SHALL possess a canonical Identity. |
| `REL-R12` | SHALL | 7. Identity | Identity SHALL remain stable throughout the lifecycle of the Relationship. |
| `REL-R13` | SHALL | 7. Identity | Changing relationship attributes SHALL NOT create a new identity. |
| `REL-R14` | SHALL | 7. Identity | Replacing the semantic meaning SHALL create a new Relationship. |
| `REL-R15` | SHALL | 8. Ownership | Every Relationship SHALL have an authoritative owner. |
| `REL-R16` | SHALL | 8. Ownership | Ownership SHALL remain traceable. |
| `REL-R17` | SHOULD | 9. Lifecycle | A Relationship SHOULD progress through explicit lifecycle states such as: |
| `REL-R18` | SHALL | 9. Lifecycle | Lifecycle transitions SHALL be represented through Events. |
| `REL-R19` | MAY | 10. Temporal Validity | A Relationship MAY include temporal validity. |
| `REL-R20` | SHALL | 10. Temporal Validity | The temporal validity and lifecycle of a Relationship SHALL be expressed through the Event primitive and recorded on the Semantic Timeline, so that *when* a ... |
| `REL-R21` | SHALL | 10. Temporal Validity | Temporal validity SHALL NOT affect canonical identity. |
| `REL-R22` | SHOULD | 11. Events | Creation, modification and retirement of Relationships SHOULD be represented by immutable Events. |
| `REL-R23` | SHALL | 11. Events | Historical states SHALL remain reconstructable. |
| `REL-R24` | MAY | 12. Federation | Relationships MAY span Objects originating from different Universes. |
| `REL-R25` | SHALL | 12. Federation | Cross-Universe Relationships SHALL: |
| `REL-R26` | SHALL | 12. Federation | Federation SHALL NOT transfer ownership of participating Objects. |
| `REL-R27` | SHALL | 13. Imported Relationships | Imported Relationships SHALL preserve: |
| `REL-R28` | SHALL | 13. Imported Relationships | Local extensions SHALL remain additive. |
| `REL-R29` | SHALL | 14. Traceability | Every Relationship SHALL preserve: |
| `REL-R30` | SHALL | 14. Traceability | Relationship history SHALL remain auditable. |
| `REL-R31` | SHOULD | 15. Validation | A conforming implementation SHOULD validate: |
| `REL-R32` | SHALL | 16. Architectural Invariants | Every Relationship SHALL preserve: |
| `REL-R33` | SHALL | 16. Architectural Invariants | Relationships SHALL NEVER be reduced to implementation-only links. |

## Universe -- `04-core-concepts/Universe.md`  (32 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `UNI-R01` | SHALL | 2. Definition | A Universe SHALL be characterized by its constitutional laws, governing authority, identity system and trust system rather than by any inventory of the objec... |
| `UNI-R02` | MAY | 2a. Kinds of Universe | A Universe MAY be of one of three kinds. All three kinds are equal in standing, governed by the **same Constitution** (MUC) and federated through the **same ... |
| `UNI-R03` | SHALL | Virtual Universe | A Virtual Universe is a fully artificial jurisdiction, owned by AI agents or digital organizations. It governs semantic reality that exists only within the M... |
| `UNI-R04` | SHALL | Virtual Universe | A Universe SHALL declare its kind as part of its public metadata. The kind SHALL NOT alter the constitutional obligations of the Universe. |
| `UNI-R05` | SHALL | 3. Characteristics | Every Universe SHALL possess: |
| `UNI-R06` | MAY | 3. Characteristics | Universes MAY be public, private or hybrid. |
| `UNI-R07` | SHALL | 4. Sovereignty | A Universe SHALL remain sovereign. |
| `UNI-R08` | SHALL | 4. Sovereignty | Federation SHALL NOT transfer: |
| `UNI-R09` | SHALL | 5. Semantic Authority | No external Universe SHALL redefine these decisions. |
| `UNI-R10` | SHALL | 6. Internal Structure | A Universe SHALL contain one or more Dimensions. |
| `UNI-R11` | SHALL | 7. Ownership | Every Universe SHALL declare its governing owner. |
| `UNI-R12` | MAY | 7. Ownership | Ownership MAY belong to: |
| `UNI-R13` | SHALL | 7. Ownership | Ownership SHALL remain explicit. |
| `UNI-R14` | SHALL | 8. Identity | Every Universe SHALL expose a stable global identifier. |
| `UNI-R15` | SHALL | 8. Identity | Identifiers SHALL remain stable throughout the lifetime of the Universe. |
| `UNI-R16` | MAY | 8. Identity | Names MAY evolve. |
| `UNI-R17` | SHALL | 8. Identity | Identifiers SHALL NOT. |
| `UNI-R18` | MAY | 9. Federation | A Universe MAY participate in federation. |
| `UNI-R19` | SHALL | 9. Federation | Federation SHALL occur through MUFP. |
| `UNI-R20` | SHALL | 9. Federation | Participation SHALL be voluntary. |
| `UNI-R21` | MAY | 9. Federation | Universes MAY: |
| `UNI-R22` | SHALL | 9. Federation | Isolation SHALL NOT affect constitutional conformance. |
| `UNI-R23` | SHOULD | 10. Public Metadata | A conforming Universe SHOULD expose public metadata including: |
| `UNI-R24` | SHALL | 10. Public Metadata | Public metadata SHALL NOT require disclosure of private semantic knowledge. |
| `UNI-R25` | MAY | 11. Discovery | A Universe MAY support semantic discovery. |
| `UNI-R26` | SHOULD | 11. Discovery | Discovery SHOULD begin with public metadata and schema discovery before any request for instance data. |
| `UNI-R27` | SHALL | 11. Discovery | Schema discovery SHALL be independent from data disclosure. |
| `UNI-R28` | SHALL | 12. Evolution | Evolution SHALL preserve: |
| `UNI-R29` | MAY | 12. Evolution | Federated universes MAY evolve at different rates. |
| `UNI-R30` | SHALL | 12. Evolution | Version negotiation SHALL resolve interoperability. |
| `UNI-R31` | SHALL | 14. Architectural Invariants | Every Universe SHALL preserve: |
| `UNI-R32` | SHALL | 14. Architectural Invariants | No federation activity SHALL violate these invariants. |

## Virtual-Projection -- `04-core-concepts/Virtual-Projection.md`  (8 requirements)

| ID | Level | Section | Statement |
|----|-------|---------|-----------|
| `VIRTUA-R01` | MAY | 2. Cold and Hot Descriptive Facts | The boundary is a modelling decision recorded on the fact; a fact MAY be promoted |
| `VIRTUA-R02` | SHALL | 3. Definition | A Virtual Projection SHALL: |
| `VIRTUA-R03` | SHALL | 3. Definition | A Virtual Projection SHALL NOT mutate canonical state, and reading it SHALL NOT |
| `VIRTUA-R04` | MAY | 5. Hot Facts and Events | threshold it MAY additionally emit an Event (for |
| `VIRTUA-R05` | SHALL | 7. Validation | A model SHALL NOT record a hot fact as a cold, materialized fact without an |
| `VIRTUA-R06` | SHALL | 8. Architectural Invariants | - Reading a Virtual Projection SHALL NOT change the model. |
| `VIRTUA-R07` | SHALL | 8. Architectural Invariants | - Hot facts SHALL NOT be committed into the canonical model as if cold. |
| `VIRTUA-R08` | SHALL | 8. Architectural Invariants | - A Virtual Projection SHALL be contract-governed and provenance-bearing. |