# Vercy (Meta-Universe) - full text > Open standards for federated semantic systems: how independent universes of > meaning describe reality, build meta-models (MMAS), and federate knowledge > (MUFP) under a shared constitution (MUC), preserving identity, context, > ownership, trust and traceability. This file concatenates every document of the specification, the process library and the courses. Each document is introduced by a `## ` line carrying its canonical URL; quote the URL, not this file, when citing a passage. Site: https://ver.cy/ Map: https://ver.cy/llms.txt Index: https://ver.cy/spec-index.yaml Agent instructions: https://ver.cy/AGENTS.md Meta-model catalogue: https://ver.cy/models/ (tabular index at https://ver.cy/models/world-models.csv, one machine-readable spec per model at https://ver.cy/models//spec.yaml) Translations of every document below exist in Russian, Spanish, Greek and Chinese under /ru/, /es/, /el/ and /zh/ with the same path. They are informative; the English text on this page is the authoritative one. License: Apache-2.0 Generated: 2026-08-22 Documents: 143 ======================================================================== # Specification ======================================================================== ## https://ver.cy/spec/docs/README.md

Meta-Universe

🌌 Meta-Universe

Open Standards for Federated Semantic Systems

A common semantic foundation for AI, organizations, software, devices and digital ecosystems —
so that independent universes of meaning can understand one another without giving up their sovereignty.

![Status](https://img.shields.io/badge/status-v2%20draft-orange) ![Specification](https://img.shields.io/badge/specification-living-blue) ![License](https://img.shields.io/badge/license-Apache--2.0-green) ![Conformance](https://img.shields.io/badge/conformance-MUC%20%7C%20MMAS%20%7C%20MUFP-purple) ![Docs](https://img.shields.io/badge/documents-60%2B-lightgrey)

Why · Stack · Core Ideas · Standards · Repository · Existing Standards · Roadmap · Ecosystem · Start Here

--- > 📋 **Status:** Working Draft — see [STATUS.md](STATUS.md). Not yet to be cited as a finalized standard. Machine-readable index: [`spec-index.yaml`](spec-index.yaml). ## Why Meta-Universe? Every organization builds its own models. Every AI system creates its own context. Every product invents its own ontology. Today we integrate **data**. Tomorrow we must federate **meaning**. **Meta-Universe** is an open *family of standards* that lets independent semantic universes exchange knowledge while preserving **Identity, Context, Ownership, Trust, Traceability and Autonomy**. It is **not** another ontology, database or platform. It is the **constitutional, architectural and federation layer** *above* existing semantic standards.
Why aren't existing tools enough? | Approach | What it gives | What it misses | |----------|---------------|----------------| | **Graph DB** | flexible storage of nodes & edges | no sovereignty, no contracts, no projection of meaning | | **Ontology (RDF/OWL)** | shared vocabularies | no federation lifecycle, trust model or disclosure control | | **API (REST/GraphQL/gRPC)** | data transport | answers *how to transfer data*, not *how to agree on meaning* | | **MDM / Data Catalog** | a single source of record | centralization; one owner of truth | Meta-Universe answers a different question: **how can two sovereign universes safely agree on a shared understanding of knowledge?**
--- ## The Meta-Universe Stack ```mermaid flowchart TB APP[Applications] DMM[Domain Meta-Models
Employee · AISMM · ELMM · ...] MUFP[MUFP — Meta-Universe Federation Protocol] MMAS[MMAS — Meta-Model Architecture Standard] MUC[MUC — Meta-Universe Constitution] APP --> DMM --> MUFP --> MMAS --> MUC classDef base fill:#1a1a2e,color:#fff,stroke:#888; class MUC,MMAS,MUFP base; ``` ```text Applications ▲ Domain Meta-Models (Employee, AISMM, ELMM, ...) ▲ MUFP — Meta-Universe Federation Protocol ▲ MMAS — Meta-Model Architecture Standard ▲ MUC — Meta-Universe Constitution ``` Each layer depends only on the layers below it. Lower layers never depend on higher ones. --- ## Core Ideas | Principle | In one line | |-----------|-------------| | 🌍 **Reality First** | Models describe reality rather than replace it. | | 🆔 **Universal Identity** | Every Meta-Object has one stable, global identity. | | 🪞 **Projection** | Each universe sees its own context-specific projection — never the raw object. | | 🌐 **Federation** | Universes exchange projections, not ownership. | | 🤝 **Knowledge Contracts** | Knowledge is disclosed through explicit, purpose-bound contracts. | | 🛡️ **Trust** | Trust is established, never assumed — and never confused with security. | | 📜 **Traceability** | Every significant fact can be traced to its origin and its lineage. | | 🔗 **Semantic Interoperability** | Schemas are shared before data is exchanged. | See the full [Manifesto](00-foundation/Vision.md#the-meta-universe-manifesto) and the seventeen [Principles](00-foundation/Principles.md). --- ## Standards Family | Standard | Purpose | Status | |----------|---------|--------| | **MUC** — [Meta-Universe Constitution](01-constitution/Meta-Universe-Constitution.md) | The fundamental laws and invariants (21 articles, 6 chapters) | 🟧 Working Draft | | **MMAS** — [Meta-Model Architecture Standard](02-architecture/MMAS-Core.md) | How to build, version, validate and package a meta-model | 🟧 Working Draft | | **MUFP** — [Meta-Universe Federation Protocol](03-federation/MUFP.md) | How sovereign universes discover, trust and exchange knowledge | 🟧 Working Draft | | **Core Concepts** — [04-core-concepts](04-core-concepts/) | The shared semantic vocabulary (Object, Relationship, Event, Contract, Projection, …) | 🟧 Working Draft | > **Document status legend:** 🟥 Planned · 🟧 Working Draft · 🟦 Draft · 🟩 Frozen / Stable --- ## The Five Semantic Primitives ```mermaid flowchart LR O["Object
what exists"] R["Relationship
how it connects"] E["Event
how it changes"] C["Contract
on what terms"] P["Projection
how it appears"] O --- R --- E --- C --- P ``` A single **Meta-Object** (a *Semantic Point of Truth*) is connected by **Relationships**, evolves through **Events**, is governed by **Contracts**, and is seen through context-specific **Projections** — all interpreted within a **Context**. --- ## Repository Map The repository is organized **by semantics, not by file type** — each folder answers a question. ```text 00-foundation/ Why the standard exists (Vision, Principles, Terminology, Glossary, FAQ) 01-constitution/ Which laws it obeys (MUC, Governance, Change-Process, Conformance, Definitions) 02-architecture/ How meta-models are built (MMAS, Versioning, Validation, Packaging, ...) 03-federation/ How universes interact (MUFP, Trust, Identity Binding, Mapping, ...) 04-core-concepts/ The fundamental concepts (Universe, Object, Event, Projection, Context, ...) 05-reference-architecture/ How to apply it (Architecture, Stack, Patterns, Anti-Patterns, Diagrams) 06-ecosystem/ How it lives in the world (Registry, Compatibility, Certification, Roadmap) 07-guides/ How to start (Getting-Started, Federation-Guide, AI-Agent-Guide, ...) examples/ How it looks in practice LICENSE Apache-2.0 ``` --- ## Relationship with Existing Standards Meta-Universe **unifies** rather than **replaces**. It is a layer that lets these standards coexist and federate. | Existing standard | Meta-Universe relationship | |-------------------|----------------------------| | OData | imported & projected as business entities | | RDF / OWL | imported as semantic graphs; federated, not centralized | | Schema.org | imported as public web vocabulary | | OpenAPI | described as a projection / service contract | | BPMN | imported as process semantics | | FHIR | imported as a domain (healthcare) meta-model | | ArchiMate | imported as enterprise-architecture semantics | External standards are imported as versioned **[Semantic Packages](02-architecture/Extension-Model.md)**, aligned through **[Semantic Mappings](03-federation/Semantic-Mapping.md)**, and composed via **[Meta-Model Composition](02-architecture/Meta-Model-Composition.md)** — the rule for when a concept is a field, a nested model, or a reference — using the **[Connector Catalogue](06-ecosystem/Connector-Catalogue.md)** as the shared set of joints between the **[1180 catalogued standards](06-ecosystem/External-Models-Registry.md)**. --- ## Roadmap | Version | Theme | |---------|-------| | **v1.0 / v1.1** | First conceptual model (Universe → Dimension → Galaxy → Object → Projection) | | **v2.0 (current)** | Full standards family: MUC + MMAS + MUFP + Core Concepts + Reference Architecture + Ecosystem + Guides | | **Future** | Candidate standards — SVF, MMQS, SMS, MUDL, Semantic Package Registry; reference meta-models; tooling & SDKs | See the detailed [Roadmap](06-ecosystem/Roadmap.md) and the consolidated *Candidate Future Standards*. --- ## Ecosystem Meta-Universe is designed as a **family of repositories**: | Repository | Purpose | |------------|---------| | **Meta-Universe** (this repo) | The ISO-like open standard: MUC, MMAS, MUFP, Core Concepts | | **meta-universe-reference-models** *(planned)* | Full reference meta-models (Employee, Organization, Product, AI Agent, …) | | [software-meta-model](https://github.com/orkestron-ai/software-meta-model) | A domain meta-model built on these standards | | [product-landscape-meta-model](https://github.com/orkestron-ai/product-landscape-meta-model) | The federation layer above AISMM: a whole product landscape as one model | | [meta-orchestrator-state](https://github.com/orkestron-ai/meta-orchestrator-state) | A polity modelled as one Dimension (Axiacracy / MOS): the largest known application | | software-agents-contracts | Contract → Protocol → Deliverable specification for AI agents | Compatible domain meta-models include AISMM, the Employee Meta-Model, the Enterprise Landscape Meta-Model and the Product Landscape Meta-Model. Two in-depth case studies document how these concepts behave in real systems: [The Orkestron Ecosystem](06-ecosystem/Case-Study-Orkestron-Ecosystem.md) (a production ecosystem of meta-models and federated projections) and [Axiacracy / Meta-Orchestrator State](06-ecosystem/Case-Study-Axiacracy-MOS.md) (a whole state as a large meta-universe). --- ## Start Here ```text Vision → Principles → Terminology → Glossary → Constitution → MMAS → MUFP → Core Concepts → Reference Architecture → Guides ``` 1. **[Vision](00-foundation/Vision.md)** — why Meta-Universe exists (+ the Manifesto) 2. **[Principles](00-foundation/Principles.md)** — the seventeen architectural values 3. **[Terminology](00-foundation/Terminology.md)** & **[Glossary](00-foundation/Glossary.md)** — the language 4. **[Constitution (MUC)](01-constitution/Meta-Universe-Constitution.md)** — the fundamental laws 5. **[MMAS](02-architecture/MMAS-Core.md)** — how to build a meta-model 6. **[MUFP](03-federation/MUFP.md)** — how to federate 7. **[Core Concepts](04-core-concepts/)** & **[Reference Architecture](05-reference-architecture/)** 8. **[Guides](07-guides/)** — Getting Started, Federation, AI Agents, Migration New to the project? The **[FAQ](00-foundation/FAQ.md)** answers the most common first questions. --- ## Freeze Rule 1. Documents are created in dependency order. 2. Approved documents become **Frozen**. 3. Frozen documents change only through an explicit [Change Request](01-constitution/Change-Process.md). 4. Later documents build on Frozen documents. --- ## Contributing Meta-Universe is an open specification. Contributions, reviews and proposals are welcome — start with **[CONTRIBUTING.md](CONTRIBUTING.md)**, the project **[GOVERNANCE.md](GOVERNANCE.md)**, the **[Code of Conduct](CODE_OF_CONDUCT.md)** and the **[Security Policy](SECURITY.md)**. Changes flow through the [Change Process](01-constitution/Change-Process.md); please read the [Principles](00-foundation/Principles.md) and the [Constitution](01-constitution/Meta-Universe-Constitution.md) first — every contribution must remain consistent with both. Implementers: the **[Core Profile](02-architecture/Core-Profile.md)** defines the minimal mandatory subset to be "Meta-Universe Core conformant". --- ## License Copyright © Orkestron.AI. Licensed under the **Apache License 2.0** — see [LICENSE](LICENSE). --- > **Meta-Universe is a federation of sovereign semantic universes connected through shared standards, contracts and trust.** ## https://ver.cy/spec/docs/AGENTS.md # AGENTS.md — Reading Meta-Universe as an AI agent This file is the entry point for an AI agent (or any automated tool) ingesting this repository. It tells you what to read first and which artifacts are machine-readable. ## What this is Meta-Universe is a **family of open standards** for federated semantic systems: how independent "universes" of meaning describe reality, build meta-models, and federate knowledge while preserving identity, context, ownership, trust and traceability. It is a specification, not a runtime. ## Read in this order 1. **`spec-index.yaml`** — the machine-readable index of every document (id, class, status, path). Start here to enumerate the spec. 2. **`00-foundation/Terminology.md`** — the normative vocabulary. Resolve terms here, not from prose. 3. **`01-constitution/Meta-Universe-Constitution.md`** — the fundamental laws (21 articles). Each normative statement has an ID (`MUC-Rnn`). 4. **`REQUIREMENTS-INDEX.md`** — every RFC 2119 requirement across all normative documents, with stable IDs. Cite these IDs. 5. **`02-architecture/MMAS-Interchange.md`** + **`schemas/`** — the MUIF serialization and JSON Schemas: the concrete, validatable face of the model. 6. **`03-federation/MUFP-Messages.md`** — the wire protocol (envelopes, state machine, errors) for federating. ## Machine-readable artifacts | Artifact | Use | |----------|-----| | `spec-index.yaml` | Enumerate documents and their status. | | `schemas/*.schema.json` | Validate MUIF models, MUFP envelopes, discovery and validation reports (JSON Schema 2020-12). | | `REQUIREMENTS-INDEX.md` | Address individual normative requirements by ID. | | `mu-fingerprint` (see `tools/`) | Compute the reproducible Semantic Fingerprint of a model. | | `mu-validate` (see `tools/`) | Validate a MUIF model against the V0–V2 checks. | | `/.well-known/meta-universe.json` | A Universe's discovery document (see `examples/well-known/`). | ## Worked examples - `examples/minimal-person/` — smallest model + fingerprint reproducibility. - `examples/federation-acme-govtax/` — two universes federate end-to-end. - `examples/federation-handshake/` — a MUFP message transcript. - `examples/interop/` — mapping to RDF/OWL, Schema.org, FHIR, FOAF. ## Working ON a conformant model (not this spec repo) If you were pointed at a *model repository* (it has `BOOTSTRAP.md`, `manifest.yaml`, `sources.yaml`), your operating instructions are **`07-guides/Agent-Operations.md`**: read BOOTSTRAP → manifest → sources before content; walk bundles in declared order; write **only** to the dataset's declared master; never hand-edit `raw/`, mirrors or `artifacts/`; re-run the coverage walker after structural changes; refuse writes when mastership is undeclared. The connected human-readable map of the whole standard is **`00-foundation/Overview.md`**. ## Building an agent on Meta-Universe See **`07-guides/AI-Integration-Patterns.md`** and **`07-guides/AI-Agent-Guide.md`**: load meta-models as tool schemas, retrieve meaning via Projections + Events (not raw rows), enforce an Executable Semantic Contract in the loop, and produce traceable results. ## Rules of engagement - Treat **Terminology** and the **Constitution** as authoritative; do not infer normative meaning from informative prose. - A model "means the same thing" iff its **Semantic Fingerprint** matches. - Never treat schema discoverability as data access. ## https://ver.cy/spec/docs/CHANGELOG.md # Changelog All notable changes to the Meta-Universe specification are recorded here. This project follows the evolution and versioning rules defined in [Versioning](02-architecture/Versioning.md) and [Change-Process](01-constitution/Change-Process.md). ## [Unreleased] ### Added - **Model-Traversal-and-Layout** (Normative, MU-V2-ARCH-017, `02-architecture/`): the lossless traversal contract for Meta-Model repositories: single entry point (`BOOTSTRAP.md` + `manifest.yaml`), declared bundle/layer walk order, total file classification (kind + origin), the completeness rule (every file enumerated, well-known or excluded; orphans fail V1), and reserved locations `canon/`, `raw/`, `artifacts/`, `bootstrap/`. - **Data-Mastership** (Normative, MU-V2-ARCH-018, `02-architecture/`): Systems of Record for Meta-Models: one master per dataset; three lawful patterns (model-mastered with write-back projections, external-mastered with harvested mirrors, partitioned); the `sources.yaml` Mastership Register; flow, freshness, conflict and AI-agent write rules. - [MMAS-Package](02-architecture/MMAS-Package.md) §4 canonical tree extended with `BOOTSTRAP.md`, `sources.yaml`, `canon/`, `raw/`, `artifacts/` and pointers to the two new standards. ### Added (description, agents, learning) - **Overview** (Informative, MU-V2-FOUND-006, `00-foundation/`): the complete, connected description of the whole standard: the idea, the M1-M4 layers, the eight-room map, the life of a meta-model, reading paths per persona, honest status. The single entry point for humans. - **Agent-Operations** (Informative, MU-V2-GUIDE-010, `07-guides/`): operating instructions for AI agents working on a conformant model: cold-start, authority-aware answering, write rules, harvest/publish recipes, refusal conditions, team etiquette. [AGENTS.md](AGENTS.md) now routes agents to it. - **Vercy Learn** ([ver.cy/learn](https://ver.cy/learn/)): three structured courses for humans (Foundations · Building a meta-model · Vercy for AI agents; 15 lessons), maintained site-side, linked from the spec. ### Changed - Pilot feedback (first ARCH-017/018 pilot on a production AISMM model): [Model-Traversal-and-Layout](02-architecture/Model-Traversal-and-Layout.md) now blesses **centralized classification rules** (`kind_rules` in the repository manifest with the `{prefix}` placeholder) as an equivalent alternative to per-layer enumeration for convention-named files; [Data-Mastership](02-architecture/Data-Mastership.md) register entries gained a **`status` lifecycle field** (`active` / `declared` / `suspended` / `retired`), making "mastership decided, flow not yet built" a lawful, visible, validated state instead of hidden debt. - **Case studies** (Informative, `06-ecosystem/`): [The Orkestron Ecosystem](06-ecosystem/Case-Study-Orkestron-Ecosystem.md) (MU-V2-ECO-010): a production ecosystem of meta-models (AISMM, PLMM, BKM, agent contracts) and federated realm projections; and [Axiacracy / Meta-Orchestrator State](06-ecosystem/Case-Study-Axiacracy-MOS.md) (MU-V2-ECO-011): a whole polity modelled as one Dimension with 38 namespaces, the largest known application of the standard. - **Seed entries** (Informative) in [Registered-Meta-Models](06-ecosystem/Registered-Meta-Models.md) §17: first concrete registry references (AISMM 3.1, PLMM 0.1, BKM 0.4, the MOS namespace family). - Case-study cross-references from [Known-Implementations](06-ecosystem/Known-Implementations.md) §8 and the README Ecosystem section. ## [2.0.0-draft] — Working Draft The first full standards-family release. Meta-Universe is no longer a single conceptual document but an ISO-like family of standards: **MUC + MMAS + MUFP + Core Concepts + Reference Architecture + Ecosystem + Guides**. ### Added - **Standard Header** across every document (Document Class, Normative / Informative References, Copyright, Apache-2.0 License). - **The Meta-Universe Manifesto** (Vision) — fifteen quotable beliefs. - **Event** (`04-core-concepts/Event.md`) — the missing semantic primitive, with the *Semantic Timeline* (reconstruct any past state of knowledge). - **Validation** (`02-architecture/Validation.md`) — layered validation levels V0–V5 and the relationship to Conformance and Certification. - Concept additions throughout the spec, including: Semantic Fingerprint, Canonical Semantic Name (CSN), Semantic Lineage, Semantic Package, Semantic Distribution Package (SDP), Trust Vector, Negotiation of Knowledge, Conflict Preservation, Semantic Coherence, Relationship Profile, Executable Semantic Contract, Federation of Registries, multidimensional Compatibility, and a consolidated *Candidate Future Standards* list (SVF, MMQS, SMS, MUDL, Semantic Package Registry). ### Changed - **Principles** reorganized into four value families (Reality, Federation, Architecture, Longevity). - **Constitution (MUC)** restructured into six chapters with continuously numbered articles; added **Article 10 — Semantic Discovery** and **Article 15 — Security and Confidentiality**. - **README** rebuilt as a GitHub landing page (navigation, Mermaid diagrams, collapsible sections, status legend, ecosystem map). - License changed to **Apache-2.0**. ### Migrating from v1.x See [Migration-from-v1](07-guides/Migration-from-v1.md). The key concept rename is **Galaxy → Namespace**; the architecture is now *Universe → Dimension → Namespace → Object → Projection*. ## https://ver.cy/spec/docs/CODE_OF_CONDUCT.md # Code of Conduct ## Our pledge We pledge to make participation in the Meta-Universe community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. ## Our standards Examples of behavior that contributes to a positive environment: - Using welcoming and inclusive language. - Respecting differing viewpoints and experiences. - Gracefully accepting constructive criticism. - Focusing on what is best for the community and the standard. Unacceptable behavior includes harassment, personal or political attacks, publishing others' private information, and other conduct that could reasonably be considered inappropriate in a professional setting. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the maintainers at **conduct@orkestron.ai**. All complaints will be reviewed and investigated promptly and fairly. Maintainers are obligated to respect the privacy and security of the reporter of any incident. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1. ## https://ver.cy/spec/docs/CONTRIBUTING.md # Contributing to Meta-Universe Thank you for helping build an open standard. Contributions of all kinds — issues, reviews, proposals, examples, tooling — are welcome. ## Before you start 1. Read the [Principles](00-foundation/Principles.md) and the [Constitution](01-constitution/Meta-Universe-Constitution.md). Every change must remain consistent with both. 2. Skim [STATUS.md](STATUS.md) and the [Governance](GOVERNANCE.md) model. ## How changes work All changes flow through the [Change Process](01-constitution/Change-Process.md) as a **Change Request (CR)** — a pull request that states: - **Type:** Editorial · Corrective · Evolutionary · Breaking (plus the [Semantic Change Classification](01-constitution/Change-Process.md) where it applies). - **Affected requirement IDs** (from [REQUIREMENTS-INDEX.md](REQUIREMENTS-INDEX.md)). - **Compatibility impact** and, for breaking changes, migration guidance. A CR to a Normative document is reviewed by the owning body (see [GOVERNANCE.md](GOVERNANCE.md)) and goes through a public review period. ## Authoring rules - **English only.** Match the calm, RFC/ISO register of the surrounding text. - Use the **Standard Header** (see any existing document) and flat `#` section headings. - Use RFC 2119 keywords (`SHALL`/`SHOULD`/`MAY`) **only** in Normative documents. - Keep all JSON valid and all examples machine-checkable. ## Before you open a PR Run the local checks with the reference tools (see [`tools/`](tools/) and [`tests/`](tests/) for how to invoke them): - **`mu-test`** — the Semantic Test Kit must pass. - **`mu-requirements`** — regenerate `REQUIREMENTS-INDEX.md` if you changed normative text. - **`mu-spec-index`** — regenerate `spec-index.yaml` if you added or renamed a document. If you changed a model, confirm its fingerprint with **`mu-fingerprint `** and validate it with **`mu-validate `**. ## Developer Certificate of Origin By submitting a contribution you certify that you wrote it (or have the right to submit it) and that it may be distributed under the project's [Apache-2.0](LICENSE) license, including its patent grant. ## Reporting security issues Do **not** open a public issue for vulnerabilities. See [SECURITY.md](SECURITY.md). ## Conduct All participation is governed by the [Code of Conduct](CODE_OF_CONDUCT.md). ## https://ver.cy/spec/docs/GOVERNANCE.md # Governance How the **Meta-Universe specification** is stewarded. This is the *operational* companion to the normative [Governance](01-constitution/Governance.md) document: that one defines governance *as a constitutional principle*; this one says *how the project is actually run today*. ## 1. Guiding principle Meta-Universe aims to be an **organization-independent** open standard, like the work of W3C/IETF/ISO. It is currently **steward-led** by Orkestron.AI during the Working Draft phase, with the explicit intent to migrate to neutral, multi-party governance as adoption grows. Steward-led today; community-governed by design. ## 2. Bodies (roles, not yet a legal organization) These are roles in the governance architecture; they may be filled by one or many parties: | Body | Owns | Mandate | |------|------|---------| | **Constitution Council** | MUC | Changes to the Constitution only | | **Architecture Board** | MMAS (incl. MUIF, Validation) | Meta-model architecture | | **Federation Working Group** | MUFP (incl. Messages, Security) | Federation protocol | | **Domain Registry Authority** | Registries | Compatible-model registry stewardship | | **Certification Authority** | Conformance levels | Certification criteria | ## 3. Decision-making - Changes follow the [Change Process](01-constitution/Change-Process.md) and are proposed as Change Requests (CRs) via pull request. - A CR to a Normative document requires review by the owning body (Section 2) and a **public review period**. Editorial CRs may be merged by maintainers. - Decisions are made by **rough consensus**; where consensus fails, the owning body decides, records the rationale, and the decision is auditable. - All decisions are public and traceable. Nothing is decided in private. ## 4. Maintainers Maintainers triage issues, review CRs, and steward releases. During the Working Draft phase, maintainers are appointed by the steward; the path to community maintainership will be published before the first stable release. ## 5. Intellectual property and patents - The specification text and all code/schemas are licensed under **[Apache License 2.0](LICENSE)**, which includes an explicit **patent grant** from contributors. - By contributing, you agree your contribution is licensed under Apache-2.0 and that you have the right to license it (a Developer Certificate of Origin–style affirmation; see [CONTRIBUTING.md](CONTRIBUTING.md)). - Implementations are free, including commercial implementations. There are no royalty or membership requirements to implement Meta-Universe. - If a future neutral body is formed, an explicit IPR policy (covering essential claims and a non-assertion covenant) will be adopted at that time. ## 6. Releases and versioning Releases follow [Versioning](02-architecture/Versioning.md) and the [Freeze Rule](README.md#freeze-rule). A document becomes *Frozen* only after its owning body approves it; *Stable* releases bundle frozen documents. ## 7. Naming decision (recorded) The name **"Meta-Universe"** and the *Universe / Dimension / Namespace* vocabulary are a deliberate, retained choice: they convey sovereignty and bounded semantic worlds. The project explicitly distinguishes itself from consumer "metaverse" (VR/AR) products; positioning materials state this up front. This decision is recorded here so it is not silently revisited. ## 8. Evolution of this document This governance model will itself evolve toward neutrality. Changes to it are made transparently and announced through the normal Change Process. ## https://ver.cy/spec/docs/MATURATION-ROADMAP.md # Meta-Universe — Specification Maturation Roadmap **Working document — NOT part of the normative specification.** This is the internal plan for taking Meta-Universe v2 from *Working Draft* to a mature, implementable, citable standard. It is distinct from the product-facing [Roadmap](06-ecosystem/Roadmap.md): that one describes where the ecosystem is going; this one describes how the *specification itself* is finished and hardened. Status: Draft · Owner: Orkestron.AI · Consolidates two independent critical reviews (internal "Self" review + Grok review, June 2026). --- ## 1. Current maturity scorecard | Dimension | Now | Target (mature) | |-----------|-----|-----------------| | Conceptual maturity | 8.5–9 / 10 | keep | | Specification maturity (precision, no ambiguity) | 6–6.5 / 10 | 8.5+ | | Practical / tooling maturity (examples, validation, implementability) | 5–5.5 / 10 | 8+ | | Adoption & tooling readiness | 5 / 10 | 8+ | | **Overall** | **~6.8–7.2 / 10** | **8.5+** | **Diagnosis (both reviews agree):** the conceptual skeleton and the values are strong; the gap is **formalization and executable artifacts**. Without them the spec remains "beautiful philosophy" rather than something that can be implemented, validated and relied upon during federation. --- ## 2. Where the two reviews converge (and what each added) | Theme | Self | Grok | Verdict | |-------|:----:|:----:|---------| | Formal core + canonical serialization + reproducible Semantic Fingerprint | ✅ | ✅ | **Keystone** | | MUFP is "a protocol" in name only (no messages/states/errors) | ✅ | ✅ | Critical | | Validation/Conformance not testable / not reproducible | ✅ | ✅ | Critical | | No executable examples / reference meta-models | ✅ | ✅ | Critical | | Security & privacy / threat model thin | ✅ | ✅ | Critical | | Demonstrate (not assert) interop with RDF/FHIR/Schema.org | ✅ | ➖ | Important | | Identifier scheme + CSN grammar | ✅ | ➖ | Important | | Governance operational + IPR/patent policy + repo hygiene | ✅ | ➖ | Important | | Executable Discovery + machine-readable spec index | ✅ | ➖ | Important | | Core Profile / MVP conformance | ✅ | ➖ | Important | | Canonical diagrams + MUDL | ✅ | ✅ | Important | | v1.1 continuity (M1–M4 layers dropped) | ✅ | ➖ | Important | | Status-of-document banners | ✅ | ➖ | Polish | | **MU Interchange Format (MUIF) as a named artifact** | ➖ | ✅ | Adopted | | **Semantic Test Kit + golden files** | ➖ | ✅ | Adopted | | **Semantic Coherence Score (graded certification)** | ➖ | ✅ | Adopted | | **Queryable Provenance Graph ("what breaks if X changes")** | ➖ | ✅ | Adopted | | **Decentralized Registry on DID + Verifiable Credentials** | ➖ | ✅ | Adopted | | **Minimal reference CLI (mu-validate / mu-fingerprint / mu-diff)** | ➖ | ✅ | Adopted | | **De-duplication / single-source shared sections; merge Best-Practices↔Design-Recommendations** | ➖ | ✅ | Adopted | | **i18n / multilingual model** | ➖ | ✅ | Adopted | --- ## 3. Guiding principles for the maturation pass 1. **Formalization first.** Every abstract claim must acquire a concrete, testable face (schema, grammar, message, test, or example). 2. **MUIF is the keystone.** Fingerprint, Validation, Migration, tooling and examples all depend on a canonical interchange format. It is built first. 3. **Every normative `SHALL` gets a stable Requirement ID** so it can be cited, validated and tested mechanically. 4. **Nothing is "done" without an executable artifact** (a file in `examples/`, `schemas/`, or `tests/`), not only prose. 5. **Preserve the concepts that reviewers praised** (Event/Semantic Timeline, Projection-not-Copy, Identity Agreement, Composition Hierarchy, Federation of Registries, Anti-Patterns). Maturation hardens them; it does not rewrite them. --- ## 4. The roadmap Workstreams are grouped into three phases. Each lists: **Source** (Self / Grok / Both), **Deliverables** (concrete files), **Acceptance criteria**, **Depends on**. ### Phase 1 — v2.1 "Make it implementable" (Critical) #### WS1 — MUIF: Meta-Universe Interchange Format · Source: Grok (+Self) The canonical machine-readable face of the abstract model — the keystone. - **Deliverables:** `02-architecture/MMAS-Interchange.md`; `schemas/` with JSON Schema for `Meta-Model`, `Object`, `Relationship`, `Event`, `Contract`, `Projection`, `Manifest`; a precise **canonicalization algorithm** for Semantic Fingerprint (normalization rules → byte stream → sha256). - **Acceptance:** two independent serializations of the same model produce an identical fingerprint; a sample model validates against the schemas. - **Depends on:** — (built first). #### WS2 — MUFP protocol specification · Source: Both Turn "semantic diplomacy" into an implementable protocol. - **Deliverables:** expand `03-federation/MUFP.md` + new `03-federation/MUFP-Messages.md`: state machine for the 9-stage lifecycle, message catalog (Discovery, Capability, Trust, Contract, Schema, Projection Exchange, Sync, Conflict, Terminate), envelope format, error taxonomy, version negotiation, Identity-Agreement revocation flow, one concrete binding (HTTP/JSON) and a worked handshake + projection-exchange transcript. - **Acceptance:** a developer can implement a minimal MUFP endpoint from the doc alone; every message has a schema in `schemas/`. - **Depends on:** WS1. #### WS3 — Validation criteria + Conformance testability · Source: Both - **Deliverables:** complete `02-architecture/Validation.md` with explicit, per-level (V0–V5) checks and a sample Validation Report; **Requirement IDs** added to every normative `SHALL` across MUC/MMAS/MUFP; generated `REQUIREMENTS-INDEX.md`; Abstract Test Procedures mapping each level to checks; wire `06-ecosystem/Certification.md` to reproducible Validation output. - **Acceptance:** each V-level lists checks that a tool could run; "MMAS A4" and "MUFP Level 3" become verifiable, not declarative. - **Depends on:** WS1. #### WS4 — Golden example + reference meta-models · Source: Both - **Deliverables:** one end-to-end scenario (e.g. *Acme HR ↔ Government Tax federate over `Person`*) threaded through the docs and materialized under `examples/`: 2–3 meta-models (incl. **Employee**) in MUIF + fingerprint + validation report + the federation transcript from WS2. - **Acceptance:** every example validates (WS3) and round-trips a stable fingerprint (WS1); a reader can follow one object from Identity → Mapping → Contract → Projection → Sync → Conflict. - **Depends on:** WS1, WS2, WS3. #### WS5 — Security & privacy model · Source: Both - **Deliverables:** `03-federation/Security-Model.md` (threat model: spoofed Identity Bindings, poisoned Semantic Lineage, Projection leakage, Event replay, malicious Mappings, revocation propagation); "Security Considerations" section in every federation doc; concrete **Trust Vector** computation + **Identity Agreement / Trust revocation** mechanics; privacy/PII handling and a data-subject (GDPR-style) alignment note. - **Acceptance:** every federation interaction in WS2/WS4 has a stated threat + mitigation; Trust Vector is computed from defined inputs. - **Depends on:** WS2. ### Phase 2 — v2.2 "Make it verifiable & clean" (Important) #### WS6 — Semantic Test Kit + golden files · Source: Grok Reproducible conformance: abstract tests + reference artifacts per V-level under `tests/` with pass/fail golden files. **Depends on:** WS3, WS4. #### WS7 — Interop appendix (demonstrated, not asserted) · Source: Self Real mappings `Object → RDF triple / OWL class`, plus Schema.org and FHIR, and one fully imported Semantic Package, under `examples/interop/`. **Depends on:** WS1. #### WS8 — Identifier scheme + CSN grammar · Source: Self Normative identifier scheme (or pluggable scheme registry) and an **ABNF grammar for CSN**; folds into MUIF/Naming-Conventions. **Depends on:** WS1. #### WS9 — Executable Discovery + machine-readable spec index · Source: Self `/.well-known/meta-universe.json` specification (public schemas, supported MUC/MMAS/MUFP versions, capabilities); `spec-index.yaml` (every doc: ID, class, status, version, dependencies); `AGENTS.md` / `llms.txt` AI-onboarding entry point. **Depends on:** WS1, WS3. #### WS10 — Structural cleanup & de-duplication · Source: Grok Single-source the repeated blocks (Architectural Invariants / Future Directions / Final Statement); merge-or-clearly-split **Best-Practices ↔ Design-Recommendations**; sharpen **Terminology (normative) ↔ Glossary (explanatory) ↔ Definitions (constitutional)** boundaries; **reconcile the dropped v1.1 M1–M4 layers** in `Architecture.md` / `Migration-from-v1.md`; add "Status of This Document" banners. **Depends on:** —. #### WS11 — Canonical diagrams + MUDL draft · Source: Both A canonical diagram set (Stack, Federation lifecycle, Projection, Identity Binding, Event flow) as SVG/Mermaid assets under `assets/`; first MUDL draft (`05-reference-architecture/MUDL.md`). **Depends on:** WS1. #### WS12 — Governance, IPR & repo hygiene + Core Profile · Source: Self Operational `GOVERNANCE.md` (ratification, quorum, neutrality decision), **IPR/patent policy**, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `.github/` templates; define a **Core Profile / MVP conformance** subset; make an explicit branding decision (Meta-Universe vs "metaverse" confusion). **Depends on:** WS3, WS5. ### Phase 3 — v3.0 "Make it an ecosystem" (Valuable) #### WS13 — Minimal reference CLI · Source: Grok `mu-validate`, `mu-fingerprint`, `mu-diff` (semantic diff over fingerprint + lineage). Spec + minimal reference implementation. **Depends on:** WS1, WS3, WS6. #### WS14 — Semantic Migration Standard (SMS) · Source: Both Standardize migration of *meaning* between versions (v1→v2 is already live). **Depends on:** WS1, WS3. #### WS15 — Semantic Coherence Score · Source: Grok Automated metric (Event completeness, Relationship consistency, Projection coverage, provenance presence) enabling **graded** certification instead of binary pass/fail. **Depends on:** WS3, WS6. #### WS16 — Queryable Provenance Graph · Source: Grok Make Semantic Lineage a first-class queryable artifact: "what breaks if X changes", "show all conclusions depending on this Event". **Depends on:** WS1. #### WS17 — Decentralized Registry profile (DID + VC) · Source: Grok Realize Federation of Registries on Decentralized Identifiers + Verifiable Credentials. **Depends on:** WS5, WS9. #### WS18 — AI integration patterns + i18n · Source: Both Tool-calling schemas, structured-output constraints, RAG over Projections+Events, a worked Executable Semantic Contract in an agent loop; multilingual model for namespaces/labels/docs. **Depends on:** WS1, WS4. ### Phase 4 — Refinements from external review (Gemini) A third review (Gemini) was assessed. Much of it was already covered — the critique partly conflated Meta-Universe (this federation standard) with AISMM/FCD (a domain meta-model + dev methodology built *on top* of it). Several of its headline recommendations already exist here: **Federated/Mesh** is the standard's core ([Federation of Registries](06-ecosystem/Registered-Meta-Models.md), MUFP, Namespace publication); **Temporal / time-travel reasoning** is [Event → Semantic Timeline](04-core-concepts/Event.md); **graph-poisoning as attack surface** is the [Security Model](03-federation/Security-Model.md). The genuinely net-new items are captured below. #### WS19 — Virtual Projections & Hot/Cold Descriptive Facts · Source: Gemini 2.2 / 3.1 Distinguish *cold* descriptive facts (schema, API, dependencies) from *hot* facts (metrics, runtime state). Hot facts attach as **Virtual Stream Views** — live, contract-governed projections an agent reads on the fly without mutating the model. **Depends on:** WS1 (Projection/Event/Synchronization). #### WS20 — Policy Consistency, Precedence & Deadlock Handling · Source: Gemini 2.3 + 2.4 A **pre-merge Policy Consistency Check** (logical non-contradiction of normative rules) before changes enter the canon; explicit rule **precedence/weights**; and **deadlock detection** with mandatory human-in-the-loop escalation. Realizes the "AI Reasoning Validation" arm of SVF. **Depends on:** WS3 (Validation), Change-Process. #### WS21 — Outcome Drift Detection · Source: Gemini 3.1 A "ghost-agent" audit comparing declared *purpose/hypothesis* (Model Canon) against observed *outcomes* (descriptive metrics): code can be valid, tests green, yet the business goal unmet → flag a semantic-outcome drift. Extends V5 runtime validation. **Depends on:** WS3, WS19. #### WS22 — Simulated Sandbox Projections · Source: Gemini 3.3 A semantic **what-if**: simulate a proposed change in an isolated projected layer (a digital shadow), run synthetic load, assess side effects across the model *before* proposing it — without mutating canonical state. **Depends on:** WS1, WS20. #### WS23 — Zero-Knowledge Policy Attestation · Source: Gemini 3.4 For B2B federation, let one Universe **prove** its code/actions conform to agreed security/compliance policies **without revealing** its graph or logic, using zero-knowledge proofs and Verifiable Credentials. **Depends on:** WS5 (Security), WS17 (DID/VC). --- ## 5. Critical path & execution order ```text WS1 (MUIF) ─┬─> WS2 (MUFP) ─┬─> WS4 (golden example) ─> WS6 (test kit) │ └─> WS5 (security) ─> WS12 (governance/profile) ├─> WS3 (validation/req-IDs) ─> WS4, WS6, WS9, WS14, WS15 ├─> WS7 (interop) ├─> WS8 (identifiers/CSN) ├─> WS11 (diagrams) └─> WS16 (provenance graph) └─> WS9 (discovery/index) WS10 (cleanup) runs in parallel, no dependency. Phase 3 (WS13–18) follows once Phase 1–2 artifacts exist. ``` **Start point: WS1 (MUIF).** It unblocks almost everything. ## 6. Progress log - **2026-06-27 — WS1 (MUIF) ✅ delivered.** - `02-architecture/MMAS-Interchange.md` — normative MUIF + canonicalization algorithm. - `schemas/` — JSON Schema 2020-12 for manifest + 5 primitives + common defs. - `tools/mu-fingerprint.ps1` — reference canonicalizer (also seeds WS13). - `examples/minimal-person/` — same model in two serializations, **verified to produce an identical fingerprint** `sha256:a628b2af…b04a639d`. - Cross-linked from `02-architecture/Versioning.md`. - *Next:* WS2 (MUFP protocol) and WS3 (Validation criteria + Requirement IDs). - **2026-06-27 — WS3 (Validation + Conformance testability) ✅ delivered.** - `02-architecture/Validation.md` — added Abstract Test Procedures: per-level checks `V0-01 … V5-02`, each with severity and the requirement IDs it enforces. - `REQUIREMENTS-INDEX.md` + `tools/mu-requirements.ps1` — reproducible catalog of **1000** RFC 2119 requirements across 36 normative docs, IDs `-Rnn`. - `schemas/validation-report.schema.json` + `examples/minimal-person/validation-report.json` — machine-readable report; minimal-person passes V0–V4 (fingerprint check verified). - MUC gained a "Requirement Identifiers" section; `Certification.md` now defines assessment as reproducible against the ATPs/levels and the Requirements Index. - *Next:* WS2 (MUFP protocol), then WS4 (golden federation example). - **2026-06-27 — WS2 (MUFP protocol) ✅ delivered.** - `03-federation/MUFP-Messages.md` (FED-011) — envelope, state machine, 22-message catalog, 12-code error taxonomy, version negotiation, revocation, HTTP/JSON binding, minimal-endpoint conformance. - `schemas/mufp-envelope.schema.json` — envelope + conditional message bodies. - `examples/federation-handshake/transcript.json` — 10-envelope handshake, structurally verified; data moves only at the last message. - `MUFP.md` now points to the wire protocol. - *Next:* WS4 (golden federation example over two full meta-models). - **2026-06-27 — WS4 (golden end-to-end example) ✅ delivered.** - `examples/federation-acme-govtax/` — two sovereign universes (Acme employee MM, Government taxpayer MM) with different vocabularies federate over one Person: **Identity → Mapping → Contract → Projection → Synchronization → Conflict**. - Real fingerprints (acme `0b4965f1…`, gov `d51f639e…`, contract `44582ad8…`) all recomputed and verified; both models pass V0–V4 validation reports. - 17-envelope `transcript.json` — structurally verified; **first knowledge moves at message 14**; conflict detected + resolved with causality preserved. - Threaded into `examples/README.md` and `07-guides/Federation-Guide.md`. - **Phase 1 (v2.1 Critical) is now substantially complete** (WS1–WS4 done; WS5 Security-Model remains). - **2026-06-27 — WS5–WS18 ✅ delivered (Phases 1–3 substantially complete).** - **WS5** `03-federation/Security-Model.md` (FED-012): threat model T1–T10, Trust Vector computation, envelope signing/replay, revocation propagation, privacy/PII. - **WS8** CSN ABNF grammar + identifier scheme in Naming-Conventions. - **WS13** `tools/mu-validate.ps1` — reference validator (V0–V2 ATPs → report). - **WS6** `tests/` Semantic Test Kit — 7 fixtures, `run-tests.ps1` (ALL PASS) + golden report. - **WS9** `03-federation/Discovery.md` (FED-013) + `schemas/discovery.schema.json` + `/.well-known` example; `tools/mu-spec-index.ps1` → `spec-index.yaml` (77 docs); `AGENTS.md` + `llms.txt`. - **WS7** `examples/interop/` (Schema.org/FHIR/FOAF + Object→RDF/OWL). - **WS11** `assets/` Mermaid diagram set + `05/MUDL.md` (REFARCH-010). - **WS10** Architecture M0–M4 reconciliation; `STATUS.md` + README banner. - **WS12** `GOVERNANCE.md` (bodies, IPR/patent, naming decision), `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `.github/` templates, `02-architecture/Core-Profile.md` (ARCH-013). - **WS14–18** SMS (ARCH-010), Provenance-Graph (ARCH-011), Internationalization (ARCH-012), Semantic-Coherence-Score (ECO-006), Decentralized-Registry (ECO-007), AI-Integration-Patterns (GUIDE-009). - Repo: 77 documents, 1175 catalogued requirements, 5 reference tools, 3 test+example suites — all links/IDs clean, test kit green. - **2026-06-27 — Phase 4 (Gemini net-new) ✅ delivered.** - **WS19** `04-core-concepts/Virtual-Projection.md` (CORE-012): hot/cold facts + Virtual Stream Views (no write amplification). - **WS20** `02-architecture/Policy-Consistency.md` (ARCH-014): pre-merge consistency check, rule precedence, deadlock + human-in-loop; wired into Change-Process and Validation V3. - **WS21** Validation §9a **Outcome Drift Detection** (purpose vs observed metric). - **WS22** `02-architecture/Simulation-Sandbox.md` (ARCH-015): semantic what-if before applying. - **WS23** `03-federation/Zero-Knowledge-Attestation.md` (FED-014): prove policy conformance without revealing the model. - Repo now: **81 documents, 1218 requirements**; links/IDs clean, kit green. --- ## 7. Definition of "mature" The maturation pass is complete when: - a minimal MUFP endpoint and a validator can be built **from the documents alone**; - every normative requirement has an ID and at least one test; - at least one full reference meta-model validates and round-trips a stable fingerprint; - every federation interaction has a stated threat + mitigation; - the scorecard in §1 reaches **8.5+** overall. ## https://ver.cy/spec/docs/REQUIREMENTS-INDEX.md # 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 `-R`, 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///` 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///...`. 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. | ## https://ver.cy/spec/docs/SECURITY.md # Security Policy ## Scope Meta-Universe is a **specification** with reference tooling. "Security" here means two things: 1. **Specification security** — a flaw in the standard that would let a conforming implementation be attacked (for example a gap in the [Security Model](03-federation/Security-Model.md), the [Trust Model](03-federation/Trust-Model.md), or the [Consent and Disclosure](03-federation/Consent-and-Disclosure.md) rules). 2. **Tooling security** — a flaw in the reference tools under [`tools/`](tools/). ## Reporting a vulnerability Please report privately. Do **not** open a public issue or pull request for a suspected vulnerability. - Email the maintainers at **security@orkestron.ai** (or the address listed on the repository's security advisory page). - Include: the affected document or tool, the threat, and — for specification issues — which [Security Model threat](03-federation/Security-Model.md) (T1–T10) it relates to or extends. We aim to acknowledge reports promptly, agree a disclosure timeline, and credit reporters who wish to be credited. ## Handling Specification security fixes are processed as **Corrective** Change Requests with priority and a clear migration note where behavior changes. Confirmed threats are folded into the [Security Model](03-federation/Security-Model.md) threat table and the [Semantic Test Kit](tests/). ## https://ver.cy/spec/docs/STATUS.md # Status of This Specification **Meta-Universe v2.0 — Working Draft.** This specification is a **Working Draft**. It is published for review, experimentation and implementation feedback. - **Do not cite it as a finalized normative standard yet.** Normative statements (`SHALL` / `SHOULD` / `MAY`) express intent and are stable in spirit, but wording, requirement IDs and document numbers MAY still change before the first stable release. - **Per-document status** is recorded in each document's header (`Status:`) and, machine-readably, in [`spec-index.yaml`](spec-index.yaml). - **Requirement identifiers** (e.g. `MUC-R03`) are generated and catalogued in [`REQUIREMENTS-INDEX.md`](REQUIREMENTS-INDEX.md); during the Working Draft phase they MAY be renumbered, and will be frozen at the first stable release. - **Stability lifecycle:** 🟥 Planned → 🟧 Working Draft → 🟦 Draft → 🟩 Frozen / Stable. Changes follow the [Change Process](01-constitution/Change-Process.md) and the [Freeze Rule](README.md#freeze-rule). What *is* already stable and machine-checked: the MUIF interchange format and the Semantic Fingerprint algorithm, the JSON Schemas, the reference tools (`tools/`), and the worked examples (`examples/`) — all verified by the [Semantic Test Kit](tests/). For the plan that takes this draft to a mature standard, see [MATURATION-ROADMAP.md](MATURATION-ROADMAP.md). ## https://ver.cy/spec/docs/_SNAPSHOT.md # Generated snapshot This tree is a deploy snapshot of orkestron-ai/Meta-Universe, served by the /spec/ browser. Regenerate by copying the repo here. ## https://ver.cy/spec/docs/00-foundation/FAQ.md # Frequently Asked Questions (FAQ) **Meta-Universe Specification** **Document ID:** MU-V2-FOUND-005 **Title:** Frequently Asked Questions **Document Class:** Informative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** None **Informative References:** Vision.md, Principles.md, Terminology.md, Glossary.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document answers common questions about the Meta-Universe and provides practical explanations that complement the normative specifications. The FAQ is intended for newcomers, architects, developers, domain experts and AI practitioners. --- # 1a. The Foundation Ladder of Understanding The documents in section 00-foundation form a **ladder of understanding**. They are deliberately non-technical and are meant to be climbed in order, each rung building the mental model needed for the next: ```text README → Vision → Principles → Terminology → Glossary → FAQ ``` - **README** orients the reader and shows where everything lives. - **Vision** explains why the Meta-Universe exists. - **Principles** state the values that constrain every later decision. - **Terminology** fixes the official meaning of each concept. - **Glossary** makes those meanings intuitive through examples. - **FAQ** (this document) resolves the questions that remain. The ladder builds a complete mental model **before** the reader reaches the Constitution. The intended flow for humans is **idea → specification**: understand the concepts first, then read the normative standards that formalize them. AI agents do not need the ladder. An AI agent MAY consume Terminology and the other normative documents directly, since those documents are self-contained and machine-interpretable. The ladder exists for human comprehension, not as a prerequisite for automated reasoning. --- # 2. General Questions ## What is Meta-Universe? Meta-Universe is an open family of standards for describing, governing and federating semantic knowledge across independent organizations, AI systems and digital ecosystems. --- ## Is Meta-Universe a platform? No. It is an architecture and standards framework that can be implemented by many different platforms and organizations. --- ## Is Meta-Universe a database? No. It defines semantic architecture, not storage technology. --- ## Is Meta-Universe an ontology? Not exactly. Ontologies may be imported or represented inside Meta-Universe, but Meta-Universe also defines governance, identity, federation, lifecycle and architectural principles. --- # 3. Meta-Models ## What is a Meta-Model? A Meta-Model is a structured semantic description of a domain including Objects, Relationships, Events, Contexts and Projections. --- ## Why not use database schemas? Database schemas describe storage. Meta-Models describe meaning. Implementation may change while semantic meaning remains stable. --- ## Why create many Domain Meta-Models? Smaller bounded models are easier to understand, evolve and federate. --- # 4. Federation ## What is federation? Federation allows independent Universes to collaborate while preserving ownership and semantic sovereignty. --- ## Is federation data replication? No. Knowledge is exchanged through governed Projections rather than unrestricted copies. --- ## Why are Semantic Contracts required? Contracts define purpose, permissions, responsibilities and disclosure rules before knowledge is exchanged. --- # 5. Identity ## Why distinguish Canonical Identity and Local Identity? Local identifiers belong to individual systems. Canonical Identity provides a stable semantic identity across the federation. --- ## What is Identity Binding? Identity Binding connects local identifiers to one Canonical Identity without changing ownership. --- # 6. AI ## Why is Meta-Universe important for AI? AI systems reason more reliably when knowledge is explicit, structured, versioned and traceable. --- ## Does Meta-Universe replace LLMs? No. LLMs provide reasoning. Meta-Universe provides structured knowledge, governance and explainability. Together they enable AI-native systems. --- # 7. Governance ## Who owns a Meta-Model? The publishing organization or community retains ownership. Federation never transfers ownership automatically. --- ## Who controls the standard? The Meta-Universe standards evolve through transparent governance defined by the Constitution and Change Process. --- # 8. Adoption ## Can existing standards be reused? Yes. Existing standards such as Schema.org, OData, HL7 FHIR, ESCO and O*NET may be imported through Semantic Mappings. --- ## Can existing systems adopt Meta-Universe gradually? Yes. Migration is incremental and historical artifacts are preserved. --- # 9. Best Practices ## Should every project have its own Meta-Model? Only when necessary. Always search existing Meta-Models before creating new ones. --- ## What is the biggest design mistake? Modeling implementation details instead of semantic reality. --- # 10. Where to Go Next Recommended reading order: 1. Vision 2. Principles 3. Terminology 4. Glossary 5. Constitution 6. Core Concepts 7. MMAS 8. MUFP 9. Guides --- # Final Statement The Meta-Universe FAQ provides practical answers to the most common questions about the ecosystem. By complementing the normative specifications with concise explanations, this document lowers the learning curve and helps architects, developers, organizations and AI practitioners adopt Meta-Universe concepts with confidence while preserving the architectural principles defined by the standards. ## https://ver.cy/spec/docs/00-foundation/Glossary.md # Glossary **Meta-Universe Specification** **Document ID:** MU-V2-FOUND-004 **Title:** Human-readable Glossary **Document Class:** Informative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** None **Informative References:** Terminology.md, Definitions.md, Vision.md, Principles.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This glossary provides plain-language explanations of the concepts used throughout the Meta-Universe standards. Unlike **Terminology.md**, which contains normative definitions, this document explains ideas through intuition, examples and practical guidance. It is intended for architects, developers, domain experts, students and AI practitioners. --- # 1a. Position Among the Vocabulary Documents The Glossary is the **human-oriented encyclopedia** of the Meta-Universe. It is informative: it builds intuition, gives examples and frames concepts for newcomers. It is deliberately distinct from its two siblings: - **Terminology.md** is the **normative dictionary**. It fixes the official, short meaning of each term and is the authority that other specifications cite. When precision matters, Terminology decides. - **Definitions.md** is the **constitutional interpretation**. It states how selected terms are read when applying the Meta-Universe Constitution (MUC), and it governs governance, conformance and dispute resolution. This Glossary explains; it never overrides. Where this document and a normative document appear to differ, the normative document prevails. --- # 2. How to Use This Glossary When reading the specifications: - Use **Terminology.md** to determine the official meaning of a term. - Use this glossary to understand the concept behind that term. - Use **Definitions.md** when the question concerns constitutional interpretation. - Use the Core Concepts documents for the complete architectural model. --- # 3. Core Concepts ## Universe Think of a Universe as an independent semantic ecosystem. An enterprise, a government, a person, an AI platform or even a digital twin may own its own Universe. Every Universe governs its own knowledge. --- ## Dimension A Dimension is a large semantic space inside a Universe. It separates different knowledge domains without creating separate Universes. --- ## Namespace A Namespace groups related concepts. For example: - employee - organization - product - finance In Meta-Universe v2 the Namespace replaces the former Galaxy concept. --- ## Meta-Object A Meta-Object is the digital semantic identity of something that exists (or is meaningful). Examples include: - Employee - Company - Product - Invoice - AI Agent A Meta-Object represents meaning rather than storage. --- ## Projection A Projection is a view of a Meta-Object. Different audiences receive different Projections of the same object. Example: The HR department, Payroll system and an external partner may all see different information about the same employee. --- ## Context Context explains *why* knowledge is being used. The same information may have different meanings depending on: - purpose; - audience; - time; - assumptions. Without Context, semantic interpretation becomes unreliable. --- ## Event An Event records something that happened. Examples: - Employee hired - Product released - Contract approved Events explain how knowledge evolved. --- ## Relationship Relationships connect Meta-Objects. Examples: Employee reportsTo Manager. Product belongsTo Catalog. Relationships express business meaning. --- ## Canonical Identity The permanent identity of a Meta-Object. Even if local systems change identifiers, the Canonical Identity remains stable. --- ## Identity Binding Identity Binding connects local identifiers to one Canonical Identity. This allows independent systems to recognize the same real-world object. --- ## Semantic Contract A Semantic Contract defines the rules for exchanging knowledge. It specifies: - purpose; - permissions; - responsibilities; - disclosure conditions. --- ## Semantic Mapping A Semantic Mapping explains how concepts from different Meta-Models correspond. It allows independently designed models to work together. --- ## Federation Federation allows independent Universes to collaborate while remaining autonomous. Knowledge is shared without surrendering ownership. --- ## Semantic Sovereignty Every Universe owns and governs its own knowledge. Participation in federation never transfers ownership. --- ## Provenance Provenance answers: "Where did this knowledge come from?" Knowing the origin of information increases trust. --- ## Traceability Traceability answers: "How did we get here?" Every important change can be reconstructed through history. --- ## Governance Governance defines who makes decisions and how standards evolve. It ensures predictable long-term development. --- ## Compatibility Compatibility describes whether two semantic artifacts can work together. Compatibility is explicit rather than assumed. --- ## Certification Certification is independent evidence that something conforms to Meta-Universe standards. Certification builds trust without changing ownership. --- ## AI Agent An AI Agent is more than an LLM. Within the Meta-Universe, an AI Agent reasons using: - Meta-Models; - Context; - Contracts; - Projections; - Events. Knowledge exists outside the language model, making decisions more explainable and reusable. --- # 4. Common Misconceptions **A Meta-Model is not a database schema.** It describes meaning, not storage. **A Projection is not a copy of data.** It is a purpose-specific representation. **Federation is not data replication.** It is governed semantic collaboration. **Trust is not authentication.** Trust also includes governance, purpose and contractual obligations. --- # 5. Learning Path For readers new to Meta-Universe: 1. Read Vision. 2. Read Principles. 3. Read Terminology. 4. Read this Glossary. 5. Read the Constitution. 6. Continue with Core Concepts. The recommended progression is therefore **Vision → Principles → Terminology → Glossary → Constitution**: the Vision sets intent, the Principles set values, Terminology fixes the official meanings, this Glossary makes those meanings intuitive, and the Constitution makes them binding. --- # Final Statement The Glossary bridges the gap between formal specifications and practical understanding. By explaining the concepts behind the Meta-Universe in clear, human-readable language, it helps architects, developers, domain experts and AI practitioners build a shared mental model before exploring the normative standards that define the ecosystem. ## https://ver.cy/spec/docs/00-foundation/Overview.md # Overview: The Whole Standard, Connected **Meta-Universe Specification** **Document ID:** MU-V2-FOUND-006 **Title:** Overview: The Complete, Connected Description of the Vercy Meta-Universe **Document Class:** Informative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** None **Informative References:** Vision, Principles, Terminology, MUC, MMAS-Core, MUFP, Model-Traversal-and-Layout, Data-Mastership, AI-Agent-Guide, Agent-Operations **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. What this document is The specification is 90 documents. Each one is self-contained; none of them, alone, shows the whole. This document is the whole: one connected narrative of what the Vercy Meta-Universe is, how its parts fit, in what order to read them, and where the standard currently stands. Nothing here is normative; every section links to the documents that are. If you read only one document, read this one. If you are an AI agent, read [AGENTS.md](../AGENTS.md) first instead: it is this map, compressed for machines. --- # 2. The idea in one paragraph Organizations, products, devices and AI agents each maintain their own world of meaning: their entities, their vocabulary, their truth. Today those worlds interoperate by copying data and hoping the meaning survives. Vercy takes the opposite stance: **meaning stays home, and understanding travels.** Every world is a sovereign **Universe** with its own constitution; knowledge is modelled once, at the source, as meta-models; other worlds receive **Projections** (views, not copies) under explicit **Contracts**; history is an append-only stream of **Events** that lets any past state of knowledge be reconstructed. Federation replaces integration: no central schema for your content and no apex authority over your models, but one mandatory shared form: the constitutional model every Universe adopts, which is the price of federation and the only thing centralized. --- # 3. The four layers of reality Everything in the standard sits on one ladder of abstraction: | Layer | What lives there | Who defines it | |-------|------------------|----------------| | M4 | The constitution of meaning itself: what a Universe, Object, Event *is* | [MUC](../01-constitution/Meta-Universe-Constitution.md) | | M3 | How meta-models are built, packaged, versioned, validated | [MMAS](../02-architecture/MMAS-Core.md) | | M2 | Domain meta-models: "software product", "employee", "polity" | Model authors (e.g. AISMM) | | M1 | Instances: *this* product, *this* person, *this* law | Universes, at runtime | The chain of governed concepts runs: **Universe → Dimension → Namespace → Object → Projection / Event**, with Relationship, Contract, Context, Identity and Lifecycle as first-class citizens beside them. Each concept has one defining document in [04-core-concepts](../04-core-concepts/Universe.md). --- # 4. The standards family: eight rooms, one house The repository is organized so that each folder answers exactly one question. | Room | Question it answers | Documents | |------|---------------------|-----------| | [00-foundation](Vision.md) | Why does this exist, and what do words mean? | 6 | | [01-constitution](../01-constitution/Meta-Universe-Constitution.md) | What laws can never be broken? | 5 | | [02-architecture](../02-architecture/MMAS-Core.md) | How is a meta-model built, laid out, walked, mastered, versioned, validated? | 18 | | [03-federation](../03-federation/MUFP.md) | How do sovereign universes interoperate? | 14 | | [04-core-concepts](../04-core-concepts/Universe.md) | What are the primitives? | 12 | | [05-reference-architecture](../05-reference-architecture/Architecture.md) | How does one apply it (patterns and anti-patterns)? | 10 | | [06-ecosystem](../06-ecosystem/Registered-Meta-Models.md) | How does it live in the world (registries, 1180 external standards, case studies)? | 11 | | [07-guides](../07-guides/Getting-Started.md) | How do I start, as a human or an agent? | 10 | Around the rooms: `schemas/` (10 JSON Schemas: the validatable face), `tools/` (fingerprint, validate, spec-index, requirements), `tests/` (the semantic test kit), `examples/` (minimal-person, the golden federation example, MUFP transcripts), and three machine indexes: [spec-index.yaml](../spec-index.yaml), [REQUIREMENTS-INDEX.md](../REQUIREMENTS-INDEX.md) (1284 addressable requirements), [llms.txt](../llms.txt). --- # 5. The life of a meta-model The documents are many; the lifecycle they describe is one. 1. **Author.** A model is written as a Git-native repository: bundles → layers → records, per [MMAS-Package](../02-architecture/MMAS-Package.md). Instructions live in `BOOTSTRAP.md`, canon texts in `canon/`, harvested evidence in `raw/`, generated output in `artifacts/`. 2. **Declare.** `manifest.yaml` declares the walk: bundle order, file classification, exclusions ([Model-Traversal-and-Layout](../02-architecture/Model-Traversal-and-Layout.md)). `sources.yaml` declares, for every dataset, who is the master: the model or an external system ([Data-Mastership](../02-architecture/Data-Mastership.md)). 3. **Verify.** A walker proves completeness (every file classified, zero orphans); [Validation](../02-architecture/Validation.md) levels V0-V5 verify syntax, structure, semantics, constitutionality, federation readiness and runtime behavior; the [Semantic Fingerprint](../02-architecture/Versioning.md) makes the model's identity reproducible. 4. **Package.** The model ships as a Semantic Distribution Package: signed, fingerprinted, self-verifying ([MMAS-Package §13](../02-architecture/MMAS-Package.md)). 5. **Federate.** Universes discover each other ([Discovery](../03-federation/Discovery.md)), bind identities, negotiate [Federation Contracts](../03-federation/Federation-Contracts.md), exchange Projections over [MUFP](../03-federation/MUFP-Messages.md), weigh each other with [Trust Vectors](../03-federation/Trust-Model.md), and preserve conflicts instead of overwriting them. 6. **Evolve.** Events accumulate on the Semantic Timeline ([Event](../04-core-concepts/Event.md)); versions follow [Versioning](../02-architecture/Versioning.md); migrations follow [Semantic-Migration](../02-architecture/Semantic-Migration.md); the [Provenance Graph](../02-architecture/Provenance-Graph.md) keeps every derivation queryable. --- # 6. Reading paths by persona - **Decision maker (30 min).** [Vision](Vision.md) → this document → [Case Study: an ecosystem in production](../06-ecosystem/Case-Study-Orkestron-Ecosystem.md) and [Case Study: a polity at civilization scale](../06-ecosystem/Case-Study-Axiacracy-MOS.md) (what it looks like in production and at civilization scale). - **Architect.** [Principles](Principles.md) → [MUC](../01-constitution/Meta-Universe-Constitution.md) → [MMAS-Core](../02-architecture/MMAS-Core.md) → [MUFP](../03-federation/MUFP.md) → [Reference Architecture](../05-reference-architecture/Architecture.md) and [Anti-Patterns](../05-reference-architecture/Anti-Patterns.md). - **Model builder.** [Getting-Started](../07-guides/Getting-Started.md) → [Create-a-New-Meta-Model](../07-guides/Create-a-New-Meta-Model.md) → [MMAS-Package](../02-architecture/MMAS-Package.md) → [Model-Traversal-and-Layout](../02-architecture/Model-Traversal-and-Layout.md) → [Data-Mastership](../02-architecture/Data-Mastership.md) → [Extension-Model](../02-architecture/Extension-Model.md) + [External-Models-Registry](../06-ecosystem/External-Models-Registry.md) (reuse before writing). - **AI agent (or its author).** [AGENTS.md](../AGENTS.md) → [Agent-Operations](../07-guides/Agent-Operations.md) (operational rules on a live model) → [AI-Agent-Guide](../07-guides/AI-Agent-Guide.md) and [AI-Integration-Patterns](../07-guides/AI-Integration-Patterns.md) (building agents on the standard). - **Human learner.** The course track at [ver.cy/learn](https://ver.cy/learn/): three structured courses from first principles to running a conformant model. --- # 7. What exists today (honest status) - **The specification**: 90 documents, Working Draft, 1284 indexed requirements, machine hub (spec-index, schemas, llms.txt), reference tools and a green test kit. Canonical home: [ver-cy/meta-universe](https://github.com/ver-cy/meta-universe); human portal: [ver.cy](https://ver.cy) (5 languages), spec browser at [ver.cy/spec](https://ver.cy/spec/). - **Conformant models in production**: two production models, both maintained by the author of the standard, carry the full ARCH-017/018 shape (entry bootstrap, walk manifest, mastership register, coverage walker at zero orphans, vendored canon, live mastership statuses including a retired system of record and an automated model→site drift watch). - **Ecosystem**: AISMM v3 (stable) as the flagship domain meta-model; PLMM (draft) above it; 1180 external standards catalogued with compositional roles; two in-depth case studies. - **Not yet**: a live registry service, certification, SDKs, and the candidate future standards (SVF, MMQS, SMS, MUDL, Semantic Package Registry) tracked in [Roadmap](../06-ecosystem/Roadmap.md). --- # Final Statement Vercy is one idea applied uniformly at every scale: meaning has a home, homes have laws, and understanding between homes is negotiated, versioned and traceable rather than copied and hoped for. The rest of the specification is that idea, made precise. ## https://ver.cy/spec/docs/00-foundation/Principles.md # Principles **Meta-Universe Specification** **Document ID:** MU-V2-FOUND-002 **Title:** Core Design Principles **Document Class:** Informative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** None **Informative References:** [Vision](../00-foundation/Vision.md), [Meta-Universe Constitution](../01-constitution/Meta-Universe-Constitution.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # Purpose This document defines the fundamental design principles that guide every standard within the Meta-Universe family. Unlike the Meta-Universe Constitution (MUC), these principles explain the architectural philosophy rather than define normative requirements. This document is **Informative**. --- # A Declaration of Architectural Values The Meta-Universe rests on seventeen principles. Rather than a flat list, they are organized into **four families of values**, so that the architecture reads as a single, coherent system of beliefs: | Family | Question it answers | Principles | |--------|---------------------|------------| | **Reality Principles** | How do we relate to the world? | R1–R3 | | **Federation Principles** | How do independent universes cooperate? | F1–F8 | | **Architecture Principles** | How is the system built and kept legible? | A1–A4 | | **Longevity Principles** | How does it survive across decades? | L1–L2 | From these families grow the articles of the [Constitution](../01-constitution/Meta-Universe-Constitution.md), the rules of [MMAS](../02-architecture/MMAS-Core.md) and the requirements of [MUFP](../03-federation/MUFP.md). --- # Reality Principles *How the Meta-Universe relates to the world it describes.* ## R1. Reality First Meta-models exist to describe reality, not replace it. A semantic model should remain a faithful representation of the world it describes. Implementation technology must never become the primary design driver. ## R2. Identity Before Representation Every meaningful entity possesses a stable identity. Names, attributes, locations and representations may evolve. Identity should remain constant throughout the object's lifetime. ## R3. Context Is Part of Truth Facts cannot be interpreted independently from their context. The same object may legitimately have different properties, meanings or responsibilities in different semantic universes. Context is not metadata. Context is part of the meaning. --- # Federation Principles *How independent universes cooperate without surrendering autonomy.* ## F1. Projection Instead of Duplication Universes exchange projections rather than complete objects. A projection is a context-specific representation created for a defined purpose. Objects remain sovereign. Projections are disposable. ## F2. Federation Before Centralization Whenever possible, independent universes should cooperate through federation rather than by copying or centralizing data. Federation preserves autonomy while enabling collaboration. ## F3. Sovereignty of Universes Every semantic universe governs its own objects, policies and evolution. Participation in federation never transfers ownership or governance. ## F4. Shared Schema Before Shared Data Semantic interoperability begins with a common understanding of structure. The existence of a public schema does not imply public access to data. Models should be discoverable even when instances remain private. ## F5. Knowledge Is Exchanged Through Contracts Knowledge should never be disclosed implicitly. Every exchange should occur within an explicit purpose, scope and agreement. Contracts govern knowledge sharing, not ownership. ## F6. Least Knowledge Every participant should receive only the minimum knowledge required to accomplish an agreed purpose. The objective is not to maximize access but to minimize unnecessary disclosure. ## F7. Purpose-Driven Access Every request for knowledge should declare its purpose. Authorization depends not only on identity but also on intended use. The same information may be disclosed for one purpose and denied for another. ## F8. Trust Is Established Trust is never assumed. Trust must be built through verifiable identity, provenance, evidence and explicit agreements. --- # Architecture Principles *How the system is built and kept understandable to humans and machines.* ## A1. Traceability by Design Every significant semantic fact should be explainable. Its origin, ownership, evolution and dependencies should remain traceable throughout its lifecycle. ## A2. Open Architecture Meta-Universe is designed to integrate existing semantic standards rather than replace them. External models should be imported, extended and federated whenever possible. ## A3. Human and AI Readable Every specification should be understandable by both humans and intelligent agents. Clarity, explicit semantics and machine-readable structures are first-class design goals. ## A4. Technology Independence The architecture must outlive individual programming languages, databases, protocols and storage technologies. The standards define semantics rather than implementations. --- # Longevity Principles *How the standard survives evolution across decades.* ## L1. Evolution Without Disruption Meta-models are expected to evolve. Versioning, compatibility and migration should enable continuous evolution without unnecessary fragmentation. ## L2. Long-Term Stability Identifiers, semantic meaning and constitutional principles should remain stable across decades. Evolution is expected. Unnecessary breaking changes are not. --- # Closing Statement These principles express the architectural philosophy of Meta-Universe. The Meta-Universe Constitution transforms these principles into normative rules. All subsequent standards are expected to be consistent with both. ## https://ver.cy/spec/docs/00-foundation/Terminology.md # Terminology **Meta-Universe Specification** **Document ID:** MU-V2-FOUND-003 **Title:** Formal Terminology **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC) **Informative References:** Glossary.md, Definitions.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document establishes the normative terminology used throughout the Meta-Universe standards. A shared vocabulary is essential for semantic interoperability. Every normative specification in the Meta-Universe family SHALL use the terminology defined in this document unless an explicit extension defines additional terms. --- # 1a. Role of This Document Terminology is the **normative dictionary** of the Meta-Universe ecosystem. It holds short, strict, technology-independent definitions that other documents cite by reference. When a normative specification uses a defined term, that term carries the meaning fixed here, and nothing more. Three foundation documents address vocabulary, and their roles SHALL NOT be conflated: - **Terminology.md** (this document, Normative) — short, strict definitions that establish the official meaning of each concept. It is the authority cited by other specifications. - **Glossary.md** (Informative) — encyclopedic, human-oriented explanations with intuition and examples. It explains concepts; it does not define them normatively. - **Definitions.md** (Normative, constitutional) — the constitutional interpretation of selected terms when applying the Meta-Universe Constitution (MUC). It governs interpretation in governance, conformance and dispute resolution. Where a term is interpreted differently for constitutional purposes, the entry in Definitions.md applies within the scope of constitutional interpretation, while this document remains the general dictionary for the ecosystem. --- # 2. Terminology Principles The Meta-Universe terminology SHALL be: - unambiguous; - technology independent; - semantically precise; - reusable across domains; - stable across versions whenever practical. Definitions describe semantic meaning rather than implementation. --- # 3. Core Terms ## Universe The highest-level autonomous semantic environment with its own governance, identity authority and semantic sovereignty. --- ## Dimension A logical partition within a Universe representing an independent semantic space. --- ## Namespace A uniquely identified semantic domain inside a Dimension. In Meta-Universe v2, **Namespace replaces the former Galaxy concept** while preserving its original semantic role. --- ## Meta-Object The authoritative semantic representation of a real-world or conceptual entity. A Meta-Object owns its canonical identity and semantic lifecycle. --- ## Canonical Identity The globally stable identifier representing a Meta-Object across all federated Universes. --- ## Local Identity An identifier valid only inside one implementation or Universe. --- ## Identity Binding A governed association between a Canonical Identity and one or more Local Identities. --- ## Relationship A semantically meaningful association between Meta-Objects. --- ## Event An immutable record describing something that has occurred in the semantic world. Events explain semantic evolution. --- ## Projection A context-specific representation of a Meta-Object prepared for a particular audience or purpose. A Projection never becomes the authoritative source. --- ## Context The semantic conditions under which knowledge is interpreted. Context may include purpose, audience, assumptions, visibility and temporal scope. --- ## Semantic Contract An explicit agreement governing semantic interaction, disclosure and responsibilities. --- ## Semantic Mapping A formal correspondence between concepts belonging to different Meta-Models. --- ## Federation A governed collaboration between sovereign Universes that preserves ownership, identity and semantic autonomy. --- ## Federation Profile A reusable set of rules describing how federation is performed for a particular domain or scenario. --- ## Meta-Model A formal semantic description of a domain including its Objects, Relationships, Events, Contexts and Projections. --- ## Domain Meta-Model A Meta-Model describing one bounded semantic domain. --- ## Semantic Package A reusable collection of related semantic artifacts. --- ## Provenance Documented origin and lineage of semantic knowledge. --- ## Traceability The ability to explain how semantic artifacts, decisions and versions are related over time. --- ## Conformance The degree to which an artifact satisfies the requirements of a Meta-Universe specification. --- ## Validation The process of verifying semantic correctness and standards compliance. --- ## Governance The policies, authorities and processes responsible for maintaining semantic integrity. --- ## Trust The justified confidence that another participant may perform a specific semantic interaction for a declared purpose. Trust is broader than authentication. --- ## Sovereignty The right of a Universe to govern its own semantic knowledge independently. --- ## Discovery The process of locating Meta-Models, capabilities, repositories or federation participants. --- ## Registry A catalog of published semantic metadata that enables discovery without transferring ownership. --- ## Compatibility The declared ability of two artifacts to interoperate under specified conditions. --- ## Certification An evidence-based assessment of conformance performed according to a published certification process. --- ## AI Agent An autonomous software participant capable of reasoning over Meta-Models, participating in federation and producing traceable semantic outcomes. --- # 4. Normative Language The keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT and MAY are interpreted according to RFC 2119. --- # 5. Evolution of Terminology New terms SHOULD: - extend rather than redefine; - preserve backward understanding; - avoid unnecessary synonyms. Deprecated terms SHOULD remain documented for historical reference. --- # Final Statement A shared terminology is the foundation of semantic interoperability. By defining stable, precise and implementation-independent concepts, the Meta-Universe enables organizations, AI agents and standards to communicate using a common semantic language that remains understandable and evolvable across domains, technologies and future generations of the ecosystem. ## https://ver.cy/spec/docs/00-foundation/Vision.md # Vision **Meta-Universe Specification** **Document ID:** MU-V2-FOUND-001 **Title:** Vision **Document Class:** Informative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** None **Informative References:** [Principles](../00-foundation/Principles.md), [Meta-Universe Constitution](../01-constitution/Meta-Universe-Constitution.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # Purpose This document explains **why Meta-Universe exists**. It is not a technical specification. It defines the long-term vision and the problem that the Meta-Universe family of standards is intended to solve. This document is **Informative**. Normative requirements are defined by the Meta-Universe Constitution (MUC). --- # The Problem Human civilization has created an enormous number of information systems. Every company, government, university, product and AI platform describes reality using its own models, terminology and assumptions. As a result: - identical real-world objects are represented differently; - semantic interoperability is rare; - knowledge is duplicated instead of shared; - AI systems continuously lose context when crossing organizational boundaries; - integrations exchange data but not meaning. Today's digital ecosystem is connected technically, but fragmented semantically. --- # Why Existing Standards Are Not Enough Many mature standards already exist. OData describes business entities. OpenAPI describes APIs. Schema.org describes public web entities. RDF and OWL describe semantic graphs. BPMN describes business processes. FHIR describes healthcare information. Each standard successfully solves problems within its own domain. None of them provides a constitutional and architectural foundation for independent semantic universes to cooperate while preserving sovereignty, ownership, trust and context. Meta-Universe does not replace these standards. Meta-Universe enables them to coexist. --- # The Vision Imagine a world where every organization, person, AI agent and device owns its own semantic universe. Each universe remains autonomous. Each defines its own models. Each evolves independently. Yet all of them can communicate through shared principles instead of ad-hoc integrations. Knowledge becomes portable without becoming centralized. Meaning becomes interoperable without becoming identical. --- # Core Idea The objective of Meta-Universe is **semantic federation**. Instead of creating one global model of reality, Meta-Universe allows many independent models to cooperate through common constitutional principles, architectural conventions and federation protocols. This approach preserves diversity while enabling interoperability. --- # Long-Term Goals Meta-Universe aims to become: - a common constitutional foundation for semantic systems; - an architectural standard for building interoperable meta-models; - a federation protocol for sovereign semantic universes; - a stable foundation for AI-native systems; - a long-lived standard independent of implementation technologies. --- # Design Philosophy Meta-Universe is based on several enduring ideas: - Reality comes before implementation. - Identity is permanent. - Context is part of truth. - Objects are represented through projections. - Universes remain sovereign. - Knowledge is exchanged through contracts. - Trust is established, never assumed. - Schemas are shared before data. - Federation is preferred over centralization. --- # Scope Meta-Universe specifies principles, architecture and federation. It does not define business domains. Employee, Product, Enterprise, Healthcare, Government and other domain meta-models are expected to be developed independently while conforming to the Meta-Universe standards. --- # Success Criteria Meta-Universe will be successful when independent semantic systems can exchange knowledge without sacrificing: - autonomy; - identity; - ownership; - traceability; - security; - trust; - context. --- # The Meta-Universe Manifesto The vision above can be compressed into a small set of beliefs. These are not requirements — the [Constitution](../01-constitution/Meta-Universe-Constitution.md) turns the ones that must be enforced into law. They are the convictions on which everything else is built, written to be quoted, to outlive any single version of the specification, and to be understood in one reading. > 1. We believe **meaning** matters more than data. > 2. We believe **context** is part of truth. > 3. We believe **identity** comes before representation. > 4. We believe **federation** is better than centralization. > 5. We believe **sovereignty** is the right to leave with your models, to fork the shared form, and to help change it; conforming to the shared form is the named price of interoperability. > 6. We believe **trust** must be earned, not assumed. > 7. We believe knowledge should be exchanged through **contracts**, not extracted. > 8. We believe a system should disclose the **least knowledge** necessary, for an explicit **purpose**. > 9. We believe every significant fact should be **traceable** to its origin. > 10. We believe **schemas** should be shared before data. > 11. We believe **AI should understand models** before it consumes data. > 12. We believe history should be **preserved**, never silently rewritten. > 13. We believe standards must be readable by both **humans and machines**. > 14. We believe semantics should **outlive** the technologies that implement them. > 15. We believe the future is **many universes that understand each other** — not one universe that owns them all. --- # Vision Statement > A world where every semantic universe remains sovereign, yet every semantic universe can understand and collaborate with every other through open standards. ## https://ver.cy/spec/docs/01-constitution/Change-Process.md # Change Process **Meta-Universe Specification** **Document ID:** MU-V2-CONST-003 **Title:** Change Process **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS, MUFP **Informative References:** Governance.md, Conformance.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the normative process for evolving the Meta-Universe family of standards. The objective is to enable continuous improvement while preserving long-term stability, interoperability and traceability. --- # 2. Scope This process applies to all normative specifications within the Meta-Universe standards family, including: - Meta-Universe Constitution (MUC) - Meta-Model Architecture Standard (MMAS) - Meta-Universe Federation Protocol (MUFP) - Future normative extensions --- # 3. Guiding Principles Every change SHALL follow these principles: - Constitution before implementation. - Explicit over implicit. - Traceability by design. - Backward compatibility whenever practical. - Transparency. - Community review. - Versioned evolution. - No silent semantic changes. --- # 4. Change Lifecycle Every change SHALL pass through the following lifecycle: 1. Proposal 2. Discussion 3. Impact Analysis 4. Draft Specification 5. Review 6. Approval 7. Publication 8. Adoption 9. Deprecation (optional) 10. Retirement (optional) No stage SHALL be skipped for normative changes. --- # 5. Change Request (CR) Every proposed modification SHALL be represented as a Change Request (CR). A CR SHOULD contain: - unique identifier; - title; - motivation; - affected documents; - rationale; - expected benefits; - compatibility assessment; - migration considerations; - implementation impact; - author; - date. --- # 6. Change Categories Changes SHOULD be classified as one of the following: ### Editorial Formatting, wording and clarification without changing semantics. ### Corrective Correction of defects or ambiguities. ### Evolutionary New capabilities that preserve compatibility. ### Breaking Semantic changes that intentionally break compatibility. Breaking changes SHALL require explicit justification. --- # 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 describing the **semantic subject** of the change — *what kind of meaning is affected*. This second axis is the **Semantic Change Classification**. A change to the normative rule base SHALL additionally pass the pre-merge [Policy Consistency Check](../02-architecture/Policy-Consistency.md): a change that would make the rule set logically unsatisfiable SHALL NOT be merged. Every Change Request SHOULD declare one or more semantic change types: - **Model-structure change** — alters the structure of the meta-model (Objects, Relationships, Events, the shape of definitions). - **Meaning/semantics change** — alters the meaning of an existing concept without necessarily changing its structure. - **Federation-rules change** — alters how sovereign Universes federate, the rules of federation profiles or protocol guarantees. - **Contract change** — alters Semantic Contracts: purpose, permissions, responsibilities or disclosure conditions. - **Projection-behaviour change** — alters how Objects are projected into a given context. - **Conformance-requirement change** — alters what is required to conform to a standard at any level. The two axes are orthogonal: a single change carries both an impact category and one or more semantic change types (for example, an *Evolutionary* / *model-structure change*, or a *Breaking* / *meaning/semantics change*). 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 change types, assess the resulting compatibility impact against the affected documents, and propose migration steps where compatibility cannot be preserved. Machine-readable classification therefore turns change management into an analyzable, semi-automatable process rather than a purely manual review. --- # 7. Compatibility Assessment Every Change Request SHALL include a compatibility assessment. Possible outcomes include: - Fully compatible - Backward compatible - Forward compatible - Requires migration - Breaking --- # 8. Freeze Rule Approved documents enter the Frozen state. Frozen documents: - become normative references; - SHALL NOT receive silent modifications; - MAY only change through a published Change Request; - SHALL preserve complete revision history. --- # 9. Versioning Every published specification SHALL declare its version. New versions SHALL be published instead of replacing previous normative releases. Historical versions SHOULD remain publicly available. --- # 10. Deprecation Features MAY be deprecated before removal. A deprecation notice SHOULD specify: - affected feature; - replacement; - deprecation version; - planned removal version. Deprecation SHOULD precede any breaking removal. --- # 11. Migration Whenever compatibility cannot be preserved, migration guidance SHALL accompany the new specification. Migration guidance SHOULD include: - affected concepts; - required transformations; - compatibility strategy; - examples. --- # 12. Publication Every published version SHALL include: - version number; - publication date; - status; - change summary; - compatibility statement; - normative references. --- # 13. Auditability The evolution of every normative document SHALL remain auditable. It SHALL be possible to determine: - why a change occurred; - who proposed it; - when it was accepted; - which version introduced it. --- # Future Directions This document fixes the *constitutional* shape of the Semantic Change Classification — the change types and the requirement to declare them. The **detailed model** belongs to the Meta-Model Architecture Standard (MMAS): the formal taxonomy of semantic change types, their precise compatibility rules, and the machine-readable schema that lets AI agents compute compatibility impact and generate migrations. A future Semantic Migration Standard (SMS) would build on that taxonomy to standardize how migrations are expressed and applied. The Constitution establishes the axis; MMAS makes it operational. --- # Final Principle Meta-Universe evolves through transparent, versioned and traceable change. Stability is preserved not by preventing evolution, but by making every evolution explicit, reviewable and reproducible. ## https://ver.cy/spec/docs/01-constitution/Conformance.md # Conformance **Meta-Universe Specification** **Document ID:** MU-V2-CONST-004 **Title:** Conformance to the Meta-Universe Constitution (MUC) **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC) **Informative References:** Governance.md, Change-Process.md, ../02-architecture/MMAS-Conformance.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines what it means for a specification, meta-model, federation protocol or implementation to conform to the Meta-Universe Constitution (MUC). Conformance ensures that independently developed systems preserve the constitutional principles of Meta-Universe while remaining free to evolve within their own domains. --- # 2. Scope This document applies to: - Meta-Models - Meta-Universe implementations - Federation protocols - Domain standards - Certification processes - Reference implementations --- # 3. Definition of Conformance A specification conforms to MUC if it preserves every constitutional principle defined by the Meta-Universe Constitution. Conformance does not require identical implementations. Conformance requires semantic compatibility with the Constitution. --- # 4. Mandatory Requirements A conforming specification SHALL: - preserve the sovereignty of universes; - preserve globally unique identities; - distinguish objects from projections; - preserve context; - preserve ownership; - preserve provenance; - preserve traceability; - support semantic contracts where applicable; - avoid implicit semantic assumptions; - remain technology independent. Failure to satisfy any mandatory constitutional requirement SHALL result in non-conformance. --- # 5. Levels of Conformance The Constitution defines a single constitutional level of conformance. Additional maturity or capability levels MAY be defined by subordinate standards such as MMAS and MUFP. These levels SHALL extend, but never weaken, constitutional requirements. --- # 5a. Conformance Axes Conformance to the Meta-Universe ecosystem is measured along **three independent axes**, each owned by a different standard: - **MUC Conformance** — conformance to the constitutional principles defined here. MUC conformance is **single-level**: an artifact either preserves the constitutional principles or it does not. The Constitution defines no maturity tiers. - **MMAS Conformance** — conformance to the Meta-Model Architecture Standard, expressed as maturity levels (for example, aligned with the validation levels of MMAS). - **MUFP Conformance** — conformance to the Meta-Universe Federation Protocol, expressed as federation levels. The axes are independent: an artifact MAY hold constitutional conformance while declaring different levels on the architectural and federation axes. A combined conformance certificate therefore reports one value per axis. For example: ```text MUC 2.0: Conformant MMAS: Level 4 MUFP: Level 3 ``` ## Conformance Profiles A **Conformance Profile** is a named bundle of conformance expectations that an artifact declares it satisfies. Profiles allow an implementation to state, in one place, which axes and capabilities it targets. The following profile dimensions are recognized: - **MUC** — constitutional conformance. - **MMAS** — architectural maturity level. - **MUFP** — federation level. - **Security** — security guarantees claimed by the artifact. - **Discovery** — discovery and registry capabilities claimed by the artifact. A profile makes a multi-axis claim auditable as a single coherent statement while keeping each axis independently verifiable. --- # 6. Partial Implementations An implementation MAY support only part of the Meta-Universe ecosystem. Partial implementations MAY still conform to MUC provided that every implemented feature respects all applicable constitutional principles. Unsupported features SHALL be explicitly declared. --- # 7. Extensions Specifications MAY introduce additional concepts. Extensions SHALL NOT: - contradict constitutional principles; - redefine constitutional terminology; - weaken constitutional guarantees. Extensions SHALL declare: - namespace; - owner; - version; - compatibility statement. --- # 8. Imported Standards Meta-Universe encourages the reuse of external semantic standards. Imported models (for example OData, RDF, Schema.org, BPMN or FHIR) MAY be incorporated into conforming meta-models. Importing an external standard SHALL NOT exempt the implementation from constitutional obligations. --- # 9. Certification Certification processes MAY evaluate conformance. Certification SHOULD verify: - semantic consistency; - constitutional compliance; - documentation completeness; - traceability; - compatibility declarations. Certification procedures are defined by the corresponding certification authority or ecosystem process. --- # 10. Declaration of Conformance Every conforming specification SHOULD publish a Conformance Statement containing at least: - specification name; - specification version; - MUC version; - conformance status; - supported extensions; - known limitations. Example: MUC Version: 2.0 Conformance: Yes Extensions: - employee/* - organization/* Known Limitations: - Federation Profiles not implemented --- # 11. Conformance Evolution Conformance SHALL always reference a specific version of the Constitution. Future constitutional versions MAY introduce additional requirements. Conformance SHALL therefore always be version-specific. --- # 12. Loss of Conformance A specification SHALL lose constitutional conformance if it: - violates one or more constitutional articles; - intentionally redefines constitutional semantics; - removes mandatory guarantees without constitutional approval. Loss of conformance SHALL be explicitly documented. --- # 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 maturity levels** and the **MUFP federation levels** are specified in their own documents. The architectural maturity levels — and their relationship to the V0–V5 validation levels — are defined in [MMAS-Conformance](../02-architecture/MMAS-Conformance.md). A future revision MAY also formalize the Conformance Profile catalogue (MUC, MMAS, MUFP, Security, Discovery) as a registered, machine-readable artifact so that profiles can be discovered and verified automatically. --- # Final Statement Conformance to the Meta-Universe Constitution demonstrates semantic compatibility with the constitutional foundation of the Meta-Universe ecosystem. It does not prescribe implementation details. It guarantees adherence to a shared set of fundamental semantic laws that enable long-term interoperability between sovereign semantic universes. ## https://ver.cy/spec/docs/01-constitution/Definitions.md # Definitions **Meta-Universe Specification** **Document ID:** MU-V2-CONST-005 **Title:** Normative Definitions **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC) **Informative References:** ../00-foundation/Terminology.md, ../00-foundation/Glossary.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the constitutional meaning of key concepts used by the Meta-Universe standards. Unlike the Foundation Terminology, which establishes a common vocabulary, this specification defines how those concepts SHALL be interpreted when applying the Meta-Universe Constitution (MUC). These definitions are normative for constitutional interpretation. --- # 1a. The Three-Level Definition Model The Meta-Universe distinguishes **three levels of definition**, each with a different authority and purpose. They are analogous to the layers of a legal system: - **Terminology.md** — the **ecosystem dictionary**. It fixes the general meaning of each word, like a dictionary that says what a term means across the whole ecosystem. - **Definitions.md** (this document) — the **constitutional interpretation**. It states how selected terms acquire legal force when the Meta-Universe Constitution (MUC) is applied, like a constitution that gives words binding effect in governance, conformance and dispute resolution. - **Glossary.md** — the **explanation and examples**. It illustrates concepts in plain language, like legal commentary that shows how the rules apply in practice. The legal analogy holds throughout: the dictionary tells you what a word *means*, the constitution tells you what a word *does* when the law is applied, and the commentary tells you how it *works* in real cases. Where these layers appear to differ, this document governs for constitutional purposes (see Section 4), Terminology governs general usage, and the Glossary is never binding. --- # 2. Scope This document applies to: - constitutional interpretation; - governance decisions; - conformance assessment; - federation agreements; - dispute resolution. --- # 3. Constitutional Definitions ## Constitutional Principle A rule that SHALL remain valid across all future versions of the Meta-Universe unless explicitly superseded through the constitutional change process. --- ## Semantic Sovereignty The exclusive authority of a Universe to govern its own semantic knowledge, identities and policies. Sovereignty SHALL NOT be transferred implicitly through federation. --- ## Constitutional Authority The organization or community responsible for maintaining a published Meta-Universe specification. Authority governs the specification, not all implementations. --- ## Conforming Artifact Any repository, Meta-Model, implementation or semantic asset that satisfies the declared requirements of the applicable Meta-Universe standards. --- ## Canonical Truth The authoritative semantic representation maintained by the owning Universe. Projections SHALL NOT replace canonical truth. --- ## Federation Agreement A governed relationship established under MUFP between two or more sovereign Universes. Participation SHALL remain voluntary. --- ## Purpose The explicitly declared reason for requesting, processing or disclosing semantic knowledge. Purpose SHALL precede knowledge disclosure. --- ## Consent Authorization granted by the responsible authority to disclose semantic knowledge under defined conditions. Consent MAY be delegated according to governance policies. --- ## Disclosure The controlled release of semantic knowledge through governed Projections. Disclosure SHALL follow applicable Contracts. --- ## Constitutional Compatibility The ability of an artifact to satisfy the mandatory principles established by MUC. --- ## Traceable Decision A decision whose origin, rationale and governing evidence can be reconstructed. --- ## Historical Integrity The property that historical semantic facts remain preserved and explainable over time. --- # 4. Normative Interpretation When ambiguity exists: 1. The Constitution takes precedence. 2. Constitutional Definitions take precedence over informative guidance. 3. Normative specifications take precedence over examples. 4. Informative documents SHALL NOT redefine constitutional concepts. --- # 5. Evolution Definitions SHOULD evolve conservatively. Existing meanings SHALL NOT be redefined incompatibly without a new major constitutional version. Deprecated definitions SHOULD remain documented for historical interpretation. --- # 6. Relationship to Other Documents This specification complements: - Terminology.md — common vocabulary; - Meta-Universe Constitution.md — constitutional principles; - Conformance.md — conformance requirements; - Governance.md — governance processes. --- # Final Statement Normative Definitions establish the constitutional interpretation of the Meta-Universe standards. By providing stable meanings for foundational constitutional concepts, this document ensures consistent governance, conformance assessment and federation across independently evolving repositories, organizations and AI-native semantic ecosystems. ## https://ver.cy/spec/docs/01-constitution/Governance.md # Governance **Meta-Universe Specification** **Document ID:** MU-V2-CONST-002 **Title:** Governance of the Meta-Universe Standard **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS, MUFP **Informative References:** Change-Process.md, Conformance.md **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines how the Meta-Universe family of standards is governed, evolved and maintained. Its purpose is to preserve long-term stability while allowing continuous improvement. --- # 2. Governance Principles The governance of Meta-Universe SHALL follow these principles: - Openness - Transparency - Traceability - Backward compatibility whenever practical - Long-term stability - Community participation - Constitutional supremacy --- # 3. Standards Hierarchy The Meta-Universe standards SHALL be governed by the following hierarchy: 1. Meta-Universe Constitution (MUC) 2. Meta-Model Architecture Standard (MMAS) 3. Meta-Universe Federation Protocol (MUFP) 4. Domain-specific standards 5. Reference implementations Lower-level standards SHALL NOT contradict higher-level standards. --- # 4. Standard Ownership Each standard SHALL declare: - Owner - Maintainer(s) - Current Version - Status - Change History Ownership implies stewardship of the specification, not ownership of implementations. --- # 5. Decision Principles Changes SHOULD be evaluated according to: - consistency with the Constitution; - impact on interoperability; - backward compatibility; - implementation complexity; - long-term sustainability. --- # 6. Evolution Model Meta-Universe evolves through published versions. Each released version SHALL be immutable. New functionality SHALL be introduced through new versions rather than silent modification. --- # 7. Freeze Rule The specification is developed incrementally. Once a document has been reviewed and approved, it enters the **Frozen** state. Frozen documents: - become normative references for subsequent documents; - SHALL NOT be silently modified; - MAY only change through an approved Change Request. --- # 8. Change Requests Any stakeholder MAY propose improvements. A Change Request SHOULD include: - motivation; - affected documents; - compatibility analysis; - migration considerations; - proposed wording. Accepted changes SHALL appear in a future version of the specification. --- # 9. Compatibility The governance process SHOULD preserve compatibility whenever reasonably possible. Breaking changes SHALL be clearly identified and accompanied by migration guidance. --- # 10. Conformance Conformance levels are defined by the corresponding standards (MUC, MMAS and MUFP). Governance SHALL ensure that certification criteria remain publicly available and versioned. --- # 11. Transparency The following SHOULD remain publicly accessible: - published specifications; - version history; - governance decisions; - change requests; - compatibility statements. --- # 12. Intellectual Independence Meta-Universe is intended to remain technology independent and implementation neutral. No programming language, vendor, platform or storage technology SHALL become a normative dependency of the standards. --- # 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 exist* and *which standard each responsibility owns*. They do not name, mandate or presuppose any particular institution, company or foundation. Any conforming organization or community MAY assume one or more of these roles. The following roles are defined: ## Constitution Council Owns the Meta-Universe Constitution (MUC). It is responsible for the constitutional principles, their interpretation and any constitutional change. It is the final authority on whether a change preserves constitutional supremacy. ## Architecture Board Owns the Meta-Model Architecture Standard (MMAS). It governs the architectural model, validation levels and meta-model conformance, and SHALL ensure MMAS never contradicts the Constitution. ## Federation Working Group Owns the Meta-Universe Federation Protocol (MUFP). It governs federation rules, federation profiles and the protocol-level guarantees that allow sovereign Universes to collaborate. ## Domain Registry Authority Maintains the registry of compatible meta-models. It records published semantic metadata, compatibility declarations and discovery entries, enabling discovery without transferring ownership. ## Certification Authority Owns the conformance and certification framework. It defines and publishes conformance levels and certification procedures across MUC, MMAS and MUFP, and SHALL keep certification criteria publicly available and versioned. These roles are **organization-independent**. The standard SHALL remain valid regardless of which entity holds any role, and assuming a role SHALL NOT grant ownership of implementations or of knowledge published by sovereign Universes. --- # 14. Future Directions The roles above are framed around the governance of *documents*. As the Meta-Universe matures, governance must eventually cover the whole **ecosystem** — registries, certified implementations, federation networks, AI agents acting as participants, and the trust relationships between them — not only the specifications. A future governance standard would describe how these roles operate as a living ecosystem authority while preserving the organization-independence and semantic sovereignty established here. --- # Final Statement Meta-Universe governance exists to protect the long-term consistency, openness and interoperability of the standards family while enabling continuous evolution through transparent, versioned and community-driven processes. ## https://ver.cy/spec/docs/01-constitution/Meta-Universe-Constitution.md # Meta-Universe Constitution (MUC) **Meta-Universe Specification** **Document ID:** MU-V2-CONST-001 **Title:** Meta-Universe Constitution (MUC) **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** None **Informative References:** [Vision](../00-foundation/Vision.md), [Principles](../00-foundation/Principles.md), [Definitions](../01-constitution/Definitions.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose The Meta-Universe Constitution defines the fundamental laws that govern every Meta-Universe, Meta-Model and Federation implementation. All standards within the Meta-Universe family (including MMAS and MUFP) SHALL conform to this Constitution. This document defines invariants rather than implementation details. --- # 2. Scope This Constitution applies to: - Meta-Universes - Meta-Models - Meta-Objects - Projections - Federation - Semantic Contracts It is technology independent. --- # 3. Structure of the Constitution The Constitution is organized into **chapters**, each grouping related articles, so that it reads as a foundational law rather than a flat sequence of clauses. Articles are numbered continuously across the whole document, so that other standards may cite a stable reference such as *"MUC, Chapter III, Article 11"*. | Chapter | Title | Articles | |---------|-------|----------| | **I** | Fundamental Principles | 1–4 | | **II** | Semantic Objects | 5–8 | | **III** | Knowledge Exchange | 9–13 | | **IV** | Federation | 14–17 | | **V** | Evolution | 18–19 | | **VI** | Governance | 20–21 | --- # Chapter I. Fundamental Principles ## Article 1. Reality First Every Meta-Object SHALL represent or intentionally abstract a real or conceptual entity. Meta-models describe reality; they do not replace reality. ## Article 2. Universal Identity Every Meta-Object SHALL possess a globally unique and persistent identity. Identity SHALL remain stable throughout the object's lifetime. Names, labels and representations MAY change. ## Article 3. Sovereignty Every Meta-Universe SHALL remain sovereign. Federation SHALL NOT transfer ownership, governance or identity between universes. ## Article 4. Context Every semantic fact SHALL exist within an explicit context. Different contexts MAY legitimately produce different projections of the same object. Context SHALL be preserved. --- # Chapter II. Semantic Objects ## Article 5. Separation of Object and Projection An object and its projections are distinct concepts. A projection represents an object within a specific context and purpose. No projection SHALL redefine the identity of its source object. ## Article 6. Ownership Every significant semantic fact SHALL have an owner. Ownership determines authority to create, validate, modify and revoke that fact. Ownership and visibility are independent concepts. ## Article 7. Provenance Every significant fact SHALL declare its provenance. Unknown provenance SHALL be explicitly identified. ## Article 8. Traceability Every significant semantic fact SHALL be traceable. Implementations SHALL be able to determine: - origin - ownership - evolution - dependencies --- # Chapter III. Knowledge Exchange ## Article 9. Shared Schemas Semantic interoperability SHALL begin with shared schemas. Public availability of a schema SHALL NOT imply public availability of data. ## Article 10. Semantic Discovery A Meta-Universe SHALL be able to make the existence and structure of its public schemas discoverable to authorized participants. Discoverability of a schema SHALL remain independent of access to the underlying data, and SHALL NOT compromise the sovereignty or confidentiality of the publishing universe. ## Article 11. Knowledge Disclosure Knowledge SHALL be exchanged through explicit contracts. Disclosure SHALL be limited to the agreed purpose and scope. ## Article 12. Least Knowledge Every participant SHALL receive only the minimum knowledge required to achieve an agreed purpose. Implementations SHOULD prefer projections over complete objects. ## Article 13. Purpose Every request for semantic knowledge SHALL declare its intended purpose. Purpose SHALL participate in authorization decisions. --- # Chapter IV. Federation ## Article 14. Trust Trust SHALL never be assumed. Trust SHALL be established through verifiable identity, provenance, evidence or agreement. ## Article 15. Security and Confidentiality Trust SHALL NOT be confused with security. A Meta-Universe SHALL protect the integrity, authenticity and confidentiality of its semantic facts and of the projections it discloses, independently of the trust established with any participant. Establishing trust SHALL NOT remove the obligation to secure disclosed knowledge. ## Article 16. Federation Independent universes SHALL communicate through federation. Federation SHALL exchange projections rather than ownership. Synchronization SHALL NOT redefine authority. ## Article 17. Semantic Compatibility Differences between semantic models SHALL be made explicit through mappings. Implicit semantic assumptions SHALL be avoided. --- # Chapter V. Evolution ## Article 18. Evolution Meta-Universe standards SHALL support long-term evolution. Breaking semantic changes SHOULD be exceptional and accompanied by migration guidance. ## Article 19. Technology Independence Constitutional principles SHALL remain independent of programming languages, storage engines, communication protocols and implementation technologies. --- # Chapter VI. Governance ## Article 20. Constitutional Hierarchy The Constitution is the highest normative authority within the Meta-Universe standards family. The hierarchy is: 1. Meta-Universe Constitution (MUC) 2. Meta-Model Architecture Standard (MMAS) 3. Meta-Universe Federation Protocol (MUFP) 4. Domain Meta-Models 5. Concrete Implementations Lower layers SHALL NOT contradict higher layers. ## Article 21. Conformance A specification conforms to MUC if it preserves every constitutional article defined in this document. Additional rules MAY be introduced by subordinate standards, provided they do not violate the Constitution. Conformance to MUC is a single level: a specification either preserves the constitutional articles or it does not. Maturity levels and federation levels are defined by subordinate standards (see [MMAS-Conformance](../02-architecture/MMAS-Conformance.md) and [MUFP](../03-federation/MUFP.md)), not by the Constitution. --- # Requirement Identifiers Every normative statement in this Constitution carries a stable identifier of the form `MUC-Rnn`, catalogued in the [Requirements Index](../REQUIREMENTS-INDEX.md) (for example, `MUC-R03` for Universal Identity, `MUC-R11` for the Object/Projection separation). Subordinate standards, Conformance Statements and [Validation](../02-architecture/Validation.md) reports SHOULD cite these identifiers when referring to a constitutional requirement. Identifiers are generated from the text by the requirements tool (`mu-requirements`) and are assigned in reading order. During the Working Draft phase they MAY shift as the text evolves; they will be frozen at the first stable release. --- # Final Principle Meta-Universe is a federation of sovereign semantic universes. Interoperability is achieved through shared principles, common architecture and explicit contracts rather than centralized ownership of knowledge. ## https://ver.cy/spec/docs/02-architecture/Core-Profile.md # Core Profile **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-013 **Title:** Meta-Universe Core Profile (MVP Conformance) **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** MUC, [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), [Validation](../02-architecture/Validation.md), [MUFP-Messages](../03-federation/MUFP-Messages.md), [Discovery](../03-federation/Discovery.md), RFC 2119 **Informative References:** [MMAS-Conformance](../02-architecture/MMAS-Conformance.md), [Security-Model](../03-federation/Security-Model.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose The full specification is large. The **Core Profile** defines the **minimal mandatory subset** an implementation SHALL support to call itself "Meta-Universe Core conformant." It exists so that a first interoperable implementation is achievable without reading all documents, and so that "conformance" has a precise floor. Everything outside this profile is **optional** at the Core level and adds capability, not baseline conformance. --- # 2. Scope The Core Profile covers two roles. An implementation MAY claim either or both: - **Core Model** — producing and consuming valid meta-models. - **Core Federation** — federating with another universe over MUFP. --- # 3. Core Model requirements A Core Model implementation SHALL: 1. Read and write **MUIF** documents per [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), including the five primitives (Object, Relationship, Event, Contract, Projection) and the manifest. 2. Compute the **Semantic Fingerprint** reproducibly (the canonicalization of MMAS-Interchange). 3. Validate to at least **V3** ([Validation](../02-architecture/Validation.md)): pass all Error-severity checks of V0, V1, V2 and V3. 4. Preserve the constitutional invariants it can express: unique persistent identity (`MUC-R03`), provenance (`MUC-R13`), and Object/Projection separation (`MUC-R11`). A Core Model implementation MAY omit: external-standard import, Knowledge Quality scoring, MUDL, and runtime (V5) validation. --- # 4. Core Federation requirements A Core Federation implementation SHALL: 1. Publish a valid **Discovery Document** ([Discovery](../03-federation/Discovery.md)). 2. Implement the **minimal MUFP endpoint** ([MUFP-Messages §12](../03-federation/MUFP-Messages.md)): the HTTP/JSON binding, the state machine, version negotiation, and the messages `Hello … ProjectionResponse`. 3. **Verify the Semantic Fingerprint** of every received MUIF payload (`MUIF-R12`). 4. Return no Projection without an accepted Contract and a declared purpose (`MUC-R21`, `MUC-R25`). 5. Run the binding over authenticated transport and honor revocation ([Security-Model](../03-federation/Security-Model.md)). A Core Federation implementation MAY omit: Synchronization, Identity Binding, Conflict handling and signed envelopes — these belong to higher MUFP levels. --- # 5. Conformance statement A Core Profile claim SHALL state which role(s) are supported and the validation level reached, for example: ```text Meta-Universe Core conformant Core Model: yes (Validation V3) Core Federation: yes (MUFP minimal endpoint) ``` Such a claim is verifiable with the reference tool `mu-validate` and the [Semantic Test Kit](../tests/). --- # 6. Architectural Invariants - The Core Profile SHALL be a strict subset of the full specification; it SHALL NOT add requirements that contradict any document. - A Core claim SHALL be independently verifiable. --- # Future Directions Additional named profiles (e.g. *Federation Level 2/3*, *AI-Native*, industry Federation Profiles) will layer on top of the Core Profile, each adding a defined set of optional capabilities. --- # Final Statement > The Core Profile is the smallest honest "yes": the least an implementation must > do to interoperate — and a clear ladder for everything it may do next. ## https://ver.cy/spec/docs/02-architecture/Data-Mastership.md # Data Mastership **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-018 **Title:** Meta-Model Architecture Standard - Data Mastership and Systems of Record **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** MMAS-Core, MMAS-Package, Model-Traversal-and-Layout, Traceability **Informative References:** Synchronization, Extension-Model, Provenance-Graph, AI-Agent-Guide **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose A Meta-Model rarely lives alone. The same knowledge often also exists in a wiki (Confluence), a tracker (Jira, ClickUp), a CRM, a database or a document store, and those copies are edited by people who never open the model. This document answers the one question that decides whether such coexistence is order or chaos: **for every dataset, who is the master - the Meta-Model or the external system?** It defines: - the **System of Record (SoR)**: the single place where a dataset's truth is authored; - the three lawful **mastership patterns** (model-mastered, external-mastered, partitioned); - the **Mastership Register** (`sources.yaml`): the machine-readable declaration of all of the above; - the flow, freshness, conflict and write rules that follow from each pattern. Without this declaration, a reader cannot know whether a fact found in the model is authoritative or a possibly stale mirror, and an agent cannot know where a correction must be written. With it, both questions have a mechanical answer. --- # 2. Scope This specification governs the relationship between a Meta-Model and **operational systems within the same governance domain**: wikis, trackers, databases, file stores, business applications. It does not govern: - **federation between sovereign universes** - that is [Synchronization](../03-federation/Synchronization.md) and MUFP (each peer has its own SoRs; federation never transfers mastership); - **imported external standards** (Schema.org, FHIR, ISO vocabularies) - those are always externally mastered by their standards bodies and are handled by [Extension-Model](Extension-Model.md). --- # 3. Design Principles - **One master per dataset.** Every dataset has exactly one System of Record. "Both places are kind of authoritative" is non-conforming by definition. - **Mastership is declared, not inferred.** No reader should deduce authority from folder names, habits or team lore. - **Flow follows mastership.** Data moves *from* the master *to* its copies; a copy is never written except by that flow. - **Copies are disposable.** Any non-master copy can be deleted and rebuilt from the master without loss. - **Provenance is mandatory.** Every mirrored datum knows where it came from and when. --- # 4. Definitions - **Dataset** - a coherent body of data governed as one unit (a set of Objects, a page tree, a table, a register). The granularity is chosen by the model owner; mastership is declared per dataset. - **System of Record (SoR)** - the system in which a dataset is *authored* and whose state prevails in any conflict. - **Mirror** - a copy of an externally mastered dataset held inside the model, produced by harvesting. - **Harvest** - the pipeline that captures an external dataset into the model (raw capture + semantic transform). - **Write-back projection** - a copy of a model-mastered dataset published into an external system for convenience of reading, storage or processing. --- # 5. The Three Mastership Patterns ## 5.1 Pattern M: Model-Mastered The dataset is **born in the Meta-Model**. Facts are authored directly in the model (edited, reviewed, versioned like code). External systems receive **write-back projections**: rendered pages, exported tables, synchronized records, published for people and tools that prefer to read there. Rules: - The flow is **model → external**, always. - 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 system supports (page banner, record field, file header). - Edits made in the external copy have **no authority**. An implementation SHOULD either lock the external copy, overwrite it on next publication, or capture such edits as *change proposals* routed back to the model's normal change process; it SHALL NOT silently merge them. - In any conflict, **the model wins**. *Example: an architecture decision register authored in the model; Confluence carries a generated, read-only rendering of it because the wider organization lives in Confluence.* ## 5.2 Pattern E: External-Mastered The dataset **lives and changes in an external system** (a Confluence space that teams update daily, a tracker, a production database). The model holds a **mirror**: a harvested, semantically structured copy that lets the model link to, classify and reason over the data. Rules: - The flow is **external → model**, always. - Harvesting SHALL land the unmodified capture under `raw///` with its provenance sidecar, per [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md) §6; the semantic transform then populates the mirror in the model's layers. - Mirrored content is **read-only inside the model**. A correction is made in the external system and re-harvested; the model may additionally record an annotated deviation ("source says X, we assess Y") as its own, model-mastered statement, clearly separated from the mirrored fact. - Every mirrored dataset SHALL carry **freshness metadata**: time of last successful harvest, declared cadence, and a staleness limit after which consumers SHALL be warned. - In any conflict, **the external system wins**; the mirror is corrected by re-harvest, never the other way. *Example: AI agents continuously harvest a living Confluence space into the model; the model adds structure, links and classification, but the pages themselves are authored in Confluence.* ## 5.3 Pattern H: Partitioned The knowledge area is split: some datasets (or fields) are model-mastered, others external-mastered. This is the common real-world case and it is lawful **only when the partition is explicit**: - Each partition SHALL be declared as its own dataset with a single master (Pattern M or E). - 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: external system masters `status`, model masters `assessment`). - Cross-partition references are permitted and encouraged; they are references, not copies. --- # 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 register is treated as model-mastered and fully authored in place; any involvement of an external system without a register entry is non-conforming. Each entry SHALL declare: | Field | Meaning | |-------|---------| | `id` | Stable dataset identifier | | `description` | What this data is, in one line | | `master` | `model` or `external` | | `system` | For external involvement: system name, URL, scope (space, project, table) | | `model_location` | Where the dataset (or its mirror) lives in the repository | | `flow` | `model->external`, `external->model`, or `none` | | `pipeline` | The harvester or publisher (tool, script, agent) that moves the data | | `cadence` | How often the flow runs; for mirrors, also `staleness_limit` | | `conflict_rule` | Restatement of who wins, plus escalation contact (`steward`) | | `status` | Lifecycle of the flow: `active` (default), `declared`, `suspended`, `retired` | **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 not yet built - a mirror location exists but has never been harvested, or a write-back is agreed but no pipeline publishes it. Such entries SHALL carry `status: declared`. A declared entry is lawful, but it is **open debt, not operation**: a declared mirror SHALL NOT be presented as fresh (it has no harvest time at all), and a declared write-back gives no drift protection. Hiding the transitional state by omitting the entry, or by marking it `active`, is non-conforming; the register exists precisely to make this state visible. Illustrative register with both Confluence directions: ```yaml datasets: - id: adr-register description: Architecture decision records master: model system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Architecture } model_location: bundles/architecture/decisions/ flow: model->external pipeline: tools/publish-adr-to-confluence cadence: on-change conflict_rule: model wins; external edits become change proposals steward: architecture-owner - id: ops-runbooks description: Operational runbooks maintained by the ops team in Confluence master: external system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Ops } model_location: bundles/operations/runbooks-mirror/ flow: external->model pipeline: tools/harvest-ops-runbooks cadence: daily staleness_limit: 7d conflict_rule: Confluence wins; fix at source and re-harvest steward: ops-lead ``` This is exactly the artifact that answers "there is a Confluence - what is in it, and who is more authoritative, the meta-model or Confluence?" for every dataset, mechanically. --- # 7. Conflict and Drift - **Detection.** Implementations SHOULD detect drift between master and copy (content comparison, fingerprints, timestamps) at least at each flow run. - **Resolution.** Drift is resolved **only** in the direction declared by `conflict_rule`; resolving "by judgment" per incident is non-conforming. - **Escalation.** Drift that cannot be resolved mechanically (the partition itself is wrong, the master is disputed) goes to the dataset's steward and, if mastership changes, produces a new register entry version - mastership changes are versioned events, never silent edits. --- # 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 is exceeded. Stale mirrors SHALL be flagged, not hidden. A statement sourced from a stale mirror carries that staleness in its provenance; downstream trust decisions (see Trust-Model) MAY weight it accordingly. --- # 9. AI Agent Rules An agent working with a conforming model: - **Before relying on a dataset**: SHALL consult the register; for mirrors, SHALL check freshness and prefer re-harvest over guessing when stale. - **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 access); a correction to a model-mastered fact goes to the model. Writing to a copy is non-conforming regardless of convenience. - **When citing**: SHOULD state the master ("per Confluence Ops space, as harvested 2026-07-30") rather than presenting a mirror as origin. These rules are what allow mixed human-and-agent teams to work on the same knowledge without corrupting it from either side. --- # 10. Relation to Other Standards - **[Model-Traversal-and-Layout](Model-Traversal-and-Layout.md)** gives mirrors and projections their physical places (`raw/`, layer mirrors, `artifacts/`) and origins (harvested / generated); this document gives them authority. - **[Synchronization](../03-federation/Synchronization.md)** governs peers *across* sovereignty boundaries; this document governs tools *inside* one. Federation never moves mastership; a universe exposes only what it masters or clearly labels as mirrored. - **[Extension-Model](Extension-Model.md)**: imported standards are a fixed special case of Pattern E (master: the standards body; flow: versioned releases in). - **[Traceability](Traceability.md) / [Provenance-Graph](Provenance-Graph.md)**: harvest and publication runs are provenance events; the register tells you the policy, the provenance graph tells you what actually happened. --- # 11. Validation Structural validation (V1) SHALL check: the register exists, parses, and every declared `model_location` exists. Semantic validation (V2) SHOULD check: every mirror has provenance and freshness metadata; no file is writable under two entries; flows match masters (`master: external` never has `flow: model->external`); and every `status: declared` entry is reported as open debt. Runtime validation (V5) MAY check staleness limits against actual harvest history, and SHOULD downgrade an entry whose declared cadence has never actually run to `declared`. --- # 12. Architectural Invariants Mastership SHALL preserve: - a single System of Record per dataset at any moment; - declared, versioned mastership transitions; - provenance and freshness of every mirror; - disposability of every non-master copy; - constitutional compliance. Mastership SHALL NEVER be implied by physical location alone: location gives a default reading, the register gives the law. --- # 13. Future Directions Two natural extensions: a **connector profile** format describing harvest/publish pipelines for common systems (Confluence, Jira, Notion, relational stores) so registers can reference typed connectors rather than ad-hoc scripts; and surfacing register entries in the **Semantic Distribution Package**, so a consumer of a packaged model sees immediately which parts are authored knowledge and which are mirrors of someone's wiki. --- # Final Statement Every dataset has exactly one home for its truth. The Mastership Register makes that home explicit, the flow rules keep copies honest, and the freshness rules keep readers honest about copies. A model that declares its masters can safely coexist with wikis, trackers and databases; a model that does not is one edit away from two truths. ## https://ver.cy/spec/docs/02-architecture/Extension-Model.md # Extension Model **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-005 **Title:** Meta-Model Architecture Standard — Importing & Extending External Models **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS-Core, MMAS-Package **Informative References:** Versioning, Naming-Conventions, [Meta-Model-Composition](Meta-Model-Composition.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines how Meta-Universe Meta-Models SHALL import, reference and extend external semantic models while preserving interoperability, semantic integrity and long-term maintainability. The objective is to encourage reuse of existing standards rather than redefining concepts that already exist. --- # 2. Scope This specification applies to: - imported semantic models; - imported namespaces; - imported objects; - imported relationships; - imported vocabularies; - local extensions; - semantic mappings. --- # 3. Architectural Principle Meta-Universe SHALL prefer **extension over duplication**. Existing semantic standards SHOULD be imported whenever they already describe the required concept with sufficient precision. Whereas this document governs *importing and extending* an external model, the structural question of whether a concept should be a literal field, a nested (embedded) Meta-Model, or a reference to a separately governed model is specified in [Meta-Model-Composition](Meta-Model-Composition.md). --- # 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-describing unit that captures the import in full and can be reasoned about as a whole. This is the semantic-knowledge analogue of a software package manager, where a dependency is acquired as a named, versioned artifact rather than copied piecemeal. A Semantic Package SHALL declare at minimum: - **Source declaration** — the originating standard and its authority (for example Schema.org, O\*NET, HL7 FHIR); - **Imported namespaces** — the namespaces brought in from the source; - **Selected objects** — the specific concepts imported, rather than the entire source; - **Local extensions** — extensions added on top of the imported concepts, kept separately identifiable; - **Semantic mappings** — the explicit mappings between imported and local concepts (see Section 10); - **Compatibility constraints** — the conditions under which the package remains valid; - **Compatible version range** — the range of source versions the package is known to work with; - **Semantic Fingerprint** — the package's own [Semantic Fingerprint](Versioning.md), so that consumers can detect whether two imports of the "same" standard actually agree in meaning. Treating an import as a Semantic Package gives every dependency a stable identity, a version range and a fingerprint, exactly as a software package manager does for code, but applied to semantic knowledge. The Semantic Package is the import-time view; its distributable, publishable form is the **Semantic Distribution Package (SDP)** defined in [MMAS-Package](MMAS-Package.md), which carries the same declarations plus packaging, signature and conformance metadata. --- # 5. Import Model An imported model SHALL remain an independent semantic authority. Importing a model SHALL NOT transfer ownership of: - semantics; - identifiers; - versions; - governance. The originating standard remains authoritative. --- # 6. Imported Metadata Every imported model SHALL declare at least: - source standard; - namespace; - imported version; - import date; - local owner; - compatibility statement. --- # 7. Imported Namespaces Imported concepts SHALL preserve their original namespace whenever practical. Examples: schema:Person fhir:Patient odata:Entity bpmn:Process Local aliases MAY exist but SHALL NOT replace canonical references. --- # 8. Extension Model Local models MAY extend imported concepts. Extensions SHALL: - preserve original meaning; - avoid modification of imported semantics; - remain separately identifiable; - declare ownership. Preferred approach: Imported Concept + Local Extension = Extended Concept --- # 9. Prohibited Modifications An implementation SHALL NOT: - redefine imported semantics; - silently rename imported concepts; - change imported identifiers; - claim ownership of imported standards. If incompatible behavior is required, a new local concept SHALL be created. --- # 10. Semantic Mapping Mappings SHALL explicitly describe the relationship between imported and local concepts. Supported mapping types MAY include: - Equivalent - Extension - Specialization - Generalization - Derived From - Partial Mapping - Transformation Required Mappings SHALL be version-aware. --- # 11. Version Management Imported models SHALL preserve references to their original versions. Local extensions SHALL declare compatibility with the imported version. Changes in imported standards SHOULD trigger compatibility assessment rather than automatic migration. --- # 12. Multi-Source Models A Meta-Model MAY import multiple external standards simultaneously. Example: - schema.org - OData - FHIR - O*NET - BPMN Conflicts SHALL be resolved explicitly through semantic mappings. --- # 13. Ownership Ownership of imported concepts remains with the originating standard. Ownership of local extensions belongs to the extending Meta-Model. Ownership boundaries SHALL remain explicit. --- # 14. Traceability Every imported concept SHALL remain traceable to its origin. Traceability SHOULD identify: - originating standard; - namespace; - original identifier; - imported version; - extension history. --- # 15. Federation Federated universes SHOULD exchange canonical semantic references whenever both parties support the same imported standard. When different standards are used, federation SHOULD rely on explicit semantic mappings rather than implicit assumptions. --- # 16. Recommended Import Workflow 1. Discover an existing semantic standard. 2. Evaluate semantic suitability. 3. Import the canonical concept. 4. Preserve namespace and version. 5. Add local extensions only where necessary. 6. Publish semantic mappings. 7. Maintain compatibility during evolution. --- # 17. Typical Examples Examples of standards suitable for import include: - Schema.org - OData CSDL - RDF / OWL vocabularies - OpenAPI schemas - BPMN - DMN - HL7 FHIR - O*NET - ESCO - ArchiMate - IFC - OPC UA The list is informative rather than exhaustive. --- # 18. Architectural Invariants Importing external models SHALL NEVER violate: - Meta-Universe Constitution; - semantic identity; - provenance; - ownership; - traceability; - version integrity. --- # 19. Future Directions The Semantic Package establishes the import-time unit of dependency. A future direction is to standardize the management of these packages across a federation: dependency resolution, transitive imports, version-range solving and conflict arbitration between overlapping standards, in the manner of an established package ecosystem. This converges with the **Semantic Package Registry** anticipated by [MMAS-Package](MMAS-Package.md), in which Semantic Packages are published, discovered and resolved by their [Semantic Fingerprint](Versioning.md) and compatible version range rather than by ad-hoc copying. --- # Final Statement Meta-Universe is designed to become a federation of semantic standards rather than a replacement for them. The preferred architectural approach is to discover, import, reference and extend existing semantic models while preserving their identity, governance and meaning. This enables a global ecosystem of interoperable Meta-Models that evolve collaboratively instead of fragmenting into isolated semantic islands. ## https://ver.cy/spec/docs/02-architecture/Internationalization.md # Internationalization **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-012 **Title:** Internationalization and Localization Model **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** [Naming-Conventions](../02-architecture/Naming-Conventions.md), [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), [MMAS-Core](../02-architecture/MMAS-Core.md), BCP 47, RFC 2119 **Informative References:** [Traceability](../02-architecture/Traceability.md), [Projection](../04-core-concepts/Projection.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the **internationalization (i18n) model** of the Meta-Universe: how a single language-independent meaning carries human-readable labels, descriptions and documentation in many languages without those localizations ever affecting identity or the [Semantic Fingerprint](../02-architecture/MMAS-Interchange.md). The governing principle is already stated by [Naming-Conventions](../02-architecture/Naming-Conventions.md): the [Canonical Semantic Name (CSN)](../02-architecture/Naming-Conventions.md) is language-independent, while Display Names may be localized. This document makes that principle complete and normative across Objects, Properties and Projections. --- # 2. Scope This specification applies to: - the separation of language-independent meaning from localizable presentation; - the attachment of localized labels, descriptions and documentation to Objects, Properties and Projections; - the language-tagging rules for localized content; - the guarantee that localization is non-semantic. It does not define translation workflows or the rendering of localized content in user interfaces. --- # 3. Principles - **Meaning is language-independent.** A concept's identity is its CSN, not any word in any human language. - **Presentation is localizable.** Everything a human reads — labels, descriptions, documentation — MAY be translated. - **Localization is non-semantic.** Adding, changing or removing a translation SHALL NOT change what a concept means or its Semantic Fingerprint. --- # 4. The Canonical Semantic Name Is Not Localized A [Canonical Semantic Name (CSN)](../02-architecture/Naming-Conventions.md) SHALL be language-independent and SHALL NOT be localized. - A concept SHALL have exactly one CSN regardless of how many languages it is presented in. - A CSN SHALL NOT be translated, transliterated per-language, or varied by locale. - All [federation](../03-federation/MUFP.md) interactions SHALL exchange CSNs, never localized Display Names, for identity. The CSN commits to no human language just as it commits to no programming language: it expresses position in a semantic hierarchy and nothing more. --- # 5. What Is Localizable The following are presentation and SHALL be treated as **non-semantic**: - **Display Names** — the human-friendly label for a concept; - **Descriptions** — short human-readable explanations; - **Documentation** — long-form human-readable text; - **labels** and UI captions attached to Properties and Projections. These keys are already enumerated as non-semantic and excluded from canonicalization by [MMAS-Interchange §5](../02-architecture/MMAS-Interchange.md). Localization adds *more values* to these same non-semantic fields; it never introduces semantic content. --- # 6. Language Tags Localized content SHALL be tagged with a language tag conforming to **BCP 47** (for example `en`, `ru`, `zh`, `zh-Hans`, `pt-BR`). - Each localized value SHALL declare its language tag. - A model SHOULD declare a default language tag for content whose tag is absent. - Language tags SHALL be compared case-insensitively per BCP 47 and SHOULD be stored in their canonical BCP 47 form. A localized field is therefore a map from BCP 47 language tag to text, attached to the concept's non-semantic presentation. --- # 7. Attaching Localized Labels Without Affecting the Fingerprint Localized labels SHALL attach to Objects, Properties and Projections as values of the non-semantic presentation keys of Section 5. Because those keys are excluded from canonicalization: - a concept with one CSN and ten translated Display Names SHALL produce the **same Semantic Fingerprint** as the same concept with one translation, or with none; - adding, editing or removing a translation SHALL NOT require a [migration Event](../02-architecture/Semantic-Migration.md), because no meaning changes; - two Universes that present a concept in different languages SHALL still resolve to the same CSN and the same fingerprint, and therefore agree that they mean the same thing. User interfaces SHOULD present the localized Display Name appropriate to the user's locale while resolving it to the underlying CSN; if no translation exists for a requested locale, they SHOULD fall back to the default language. --- # 8. Worked Example A single compensation concept, presented in three languages over one immutable CSN: ```text CSN : employee.compensation.salaryAgreement (language-independent) displayName : en : "Salary Agreement" ru : "Соглашение об оплате труда" zh : "薪资协议" description : en : "The agreed terms of an employee's base compensation." ru : "Согласованные условия базовой оплаты труда сотрудника." zh : "员工基本薪酬的约定条款。" ``` The Semantic Fingerprint is computed over the semantic core, which contains the CSN and structural facts but **none** of the `displayName` or `description` values. Therefore all three presentations — and any subset of them — yield the identical fingerprint. Removing the `zh` translation, or adding a `de` one, changes nothing semantic. --- # 9. Validation A model conforms to this specification when: - every public concept has exactly one language-independent CSN; - no CSN is localized; - every localized value carries a BCP 47 language tag; - localized content occupies only non-semantic presentation keys; - the Semantic Fingerprint is invariant under addition, change or removal of any translation. See [Validation](../02-architecture/Validation.md) for the applicable levels. --- # 10. Architectural Invariants - The CSN SHALL be language-independent and SHALL NOT be localized. - Localized content SHALL be non-semantic and SHALL NOT affect the Semantic Fingerprint. - Localized values SHALL carry BCP 47 language tags. - Federation SHALL exchange CSNs, never localized Display Names, for identity. - Changing a translation SHALL NOT constitute a semantic change. --- # Future Directions A future revision could define a **localization package** format that lets translations be published, versioned and federated independently of the model they decorate — so a community can contribute a language without touching the authoritative semantic model — together with a quality signal for translation coverage that could feed the [Semantic Coherence Score](../06-ecosystem/Semantic-Coherence-Score.md)'s documentation-completeness dimension, and locale-aware [Projection](../04-core-concepts/Projection.md) selection. --- # Final Statement > A concept means one thing; the world reads it in many languages. The > Meta-Universe keeps these apart: one Canonical Semantic Name carries the > meaning, and any number of localized labels carry the words — so that > translating a model never changes what it says. ## https://ver.cy/spec/docs/02-architecture/MMAS-Conformance.md # MMAS Conformance **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-008 **Title:** Meta-Model Architecture Standard — MMAS Conformance Levels **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS-Core, Validation **Informative References:** MMAS-Package, Meta-Universe Federation Protocol (MUFP) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the conformance model for the Meta-Model Architecture Standard (MMAS). While the Meta-Universe Constitution (MUC) establishes constitutional compliance, MMAS defines architectural compliance. Conformance demonstrates that a Meta-Model follows the architectural principles, structure and packaging rules required for interoperability within the Meta-Universe ecosystem. --- # 2. Scope This specification applies to: - Meta-Models - Meta-Model repositories - Semantic packages - Bundles - Layers - Reference implementations - Certification processes --- # 3. Conformance Axes Conformance within Meta-Universe is evaluated along **three independent axes**, one per standard. A Meta-Model is positioned on each axis separately; strength on one axis does not imply strength on another. | Axis | Standard | Evaluates | |------|----------|-----------| | **MUC** | Meta-Universe Constitution | Constitutional compliance | | **MMAS** | Meta-Model Architecture Standard | Architectural compliance | | **MUFP** | Meta-Universe Federation Protocol | Federation capability | 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 support, and a high MMAS level does not by itself grant MUFP federation capability. --- # 4. MMAS Conformance Levels ## Level A1 — Structured The Meta-Model: - defines a repository structure; - exposes a manifest; - uses stable identifiers; - follows naming conventions; - declares version information. This level demonstrates basic architectural organization. --- ## Level A2 — Architectural In addition to A1, the Meta-Model: - organizes concepts into Bundles and Layers; - defines Objects, Relationships and Properties consistently; - preserves traceability; - documents semantic dependencies. --- ## Level A3 — Extensible In addition to A2, the Meta-Model: - supports external model imports; - supports semantic mappings; - supports extension without modification; - preserves imported ownership and provenance. --- ## Level A4 — Validated In addition to A3, the Meta-Model: - successfully passes the validation levels defined in [Validation](Validation.md) (V0 through the applicable upper level, V1–V5); - publishes validation reports; - declares compatibility statements; - documents migration strategy. The validation levels referenced by A4 are normatively defined in [Validation](Validation.md); this level requires demonstrated, reported conformance to them rather than self-assertion. --- ## Level A5 — AI-Native In addition to A4, the Meta-Model: - is fully machine-readable; - supports automated discovery; - exposes semantic metadata for AI agents; - supports deterministic navigation; - is suitable for autonomous reasoning and federation. This represents the highest architectural maturity defined by MMAS. --- # 5. Mandatory Requirements Regardless of level, every MMAS-conforming Meta-Model SHALL: - conform to the applicable MUC version; - declare its MMAS version; - expose a public schema; - preserve semantic identity; - preserve ownership; - preserve provenance; - preserve traceability. --- # 6. Conformance Statement Every Meta-Model SHOULD publish a Conformance Statement. Recommended fields include: - Meta-Model name; - Meta-Model version; - MUC version; - MMAS version; - MMAS Conformance Level; - Validation level achieved; - Imported standards; - Supported federation profiles; - Semantic fingerprint (optional). --- # 7. Evidence Architectural conformance SHOULD be supported by objective evidence such as: - repository inspection; - manifests; - validation reports; - dependency analysis; - semantic mappings; - package metadata. Self-declaration MAY be used but SHOULD be distinguishable from independently verified certification. --- # 8. Certification Certification MAY verify MMAS conformance. Certification SHOULD evaluate: - repository organization; - architectural consistency; - validation results; - documentation quality; - interoperability readiness. Certification procedures are ecosystem-specific and are outside the scope of this specification. --- # 9. Evolution A Meta-Model MAY improve its MMAS level over time. Regression to a lower level SHOULD be explicitly documented. Changes affecting conformance SHALL be reflected in the published Conformance Statement. --- # 10. Loss of Conformance A Meta-Model SHALL lose MMAS conformance if it: - violates mandatory architectural requirements; - no longer satisfies the declared level; - intentionally contradicts MMAS-Core. Loss of conformance SHALL be documented and versioned. --- # 11. Future Directions The three conformance axes — MUC, MMAS and MUFP — evaluate whether a Meta-Model is constitutionally sound, architecturally well-formed and federation-capable. None of them evaluates the **quality of the knowledge the model actually contains**. Two Meta-Models may both reach Level A5 yet differ profoundly in depth, accuracy and trustworthiness. A future direction is therefore a **fourth axis, "Knowledge Quality"**, formalized as a **Meta-Model Quality Standard (MMQS)**. Where MMAS asks "is this model built correctly?", MMQS would ask "is this model good?" — evaluating the *content* rather than the architecture, across dimensions such as: - **completeness** — how fully the domain is covered; - **level of detail** — the granularity of the modelled concepts; - **internal consistency** — absence of contradictions among facts; - **mapping quality** — the fidelity of mappings to imported standards; - **documentation** — the clarity and sufficiency of explanatory material; - **data trust** — the reliability of the sources behind the facts; - **evidence** — the strength of justification, linked through Semantic Lineage; - **freshness** — how current the knowledge is. Under MMQS, two models that are both A5 on the MMAS axis could still receive markedly different Knowledge Quality grades. MMQS would draw on the Semantic Lineage and Trust Vector concepts emerging elsewhere in the specification and would be reported alongside, but separately from, the architectural Conformance Level. --- # Final Statement MMAS Conformance Levels provide a common architectural maturity model for Meta-Models. They enable organizations, AI agents and federation participants to objectively evaluate the architectural quality, interoperability and long-term maintainability of semantic models independently of their implementation technology. ## https://ver.cy/spec/docs/02-architecture/MMAS-Core.md # MMAS-Core **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-001 **Title:** Meta-Model Architecture Standard — Core Architecture **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), Versioning, Naming-Conventions, Validation, MMAS-Package, MMAS-Conformance **Informative References:** Meta-Universe Federation Protocol (MUFP) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the fundamental architectural building blocks that every Meta-Model SHALL follow within the Meta-Universe ecosystem. MMAS-Core establishes a common semantic architecture that enables independent Meta-Models to remain interoperable while evolving autonomously. MMAS-Core is not merely a catalogue of building blocks. It defines a single architectural **composition model**: a canonical hierarchy that determines how every semantic primitive nests within the next, from the Meta-Model as a whole down to individual Properties, Relationships, Events, Contracts and Projections, and back up to the Manifest that describes the composition. In the same way that UML defines the core modelling building blocks from which every model is constructed, MMAS-Core defines the core compositional building blocks from which every Meta-Model in the Meta-Universe is constructed. Versioning, Validation, Packaging and Conformance all reference this single model rather than re-deriving their own. MMAS-Core extends the Meta-Universe Constitution (MUC). --- # 2. Scope This specification applies to every Meta-Model claiming MMAS conformance, regardless of domain, implementation technology or storage mechanism. --- # 3. Architectural Principles Every Meta-Model SHALL: - conform to the Meta-Universe Constitution; - describe semantics rather than implementation; - preserve stable identities; - separate schema from instance data; - support federation; - support evolution; - remain machine-readable and human-readable. --- # 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 conforming tool, validator and federation agent SHALL interpret the hierarchy identically. The hierarchy reads top-down as containment and bottom-up as description: - a **Meta-Model** contains one or more **Bundles**; - a **Bundle** contains one or more **Layers**; - a **Layer** contains one or more **Objects**; - an **Object** is described by **Properties** and connected, qualified, evolved and governed by **Relationships**, **Events**, **Contracts** and **Projections**; - the entire composition is summarized and made discoverable by a **Manifest**. ## 4.0.1 Hierarchy Diagram (Mermaid) ```mermaid flowchart TD MM[Meta-Model] B[Bundles] L[Layers] O[Objects] P[Properties] R[Relationships] E[Events] C[Contracts] PR[Projections] MAN[Manifest] MM --> B B --> L L --> O O --> P O --> R O --> E O --> C O --> PR MM -.described by.-> MAN MAN -.summarizes.-> B ``` ## 4.0.2 Hierarchy Diagram (ASCII) ```text Meta-Model │ ├── Manifest .............. (describes & summarizes the whole composition) │ └── Bundles └── Layers └── Objects ├── Properties ...... what the object is ├── Relationships ... how it connects to other objects ├── Events .......... how it changes over time ├── Contracts ....... under which rules it may be used └── Projections ..... how it appears in a given context ``` This hierarchy is the centerpiece of MMAS. It is the structure that [Versioning](Versioning.md) versions, that [Validation](Validation.md) validates level by level, that [MMAS-Package](MMAS-Package.md) packages, and that [MMAS-Conformance](MMAS-Conformance.md) measures for maturity. A Meta-Model that cannot be expressed as this hierarchy is not MMAS-conforming. --- # 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. ## 5.1 Meta-Model A Meta-Model defines the semantic structure of a domain. A Meta-Model SHALL have: - unique identifier; - namespace; - version; - owner; - manifest; - compatibility declaration. --- ## 5.2 Bundle A Bundle groups semantically related concepts. Bundles SHALL: - have a single responsibility; - minimize dependencies; - publish exported concepts. Examples: - Identity - Knowledge - Governance - Runtime --- ## 5.3 Layer A Layer represents one coherent semantic concern within a Bundle. Layers SHALL: - remain independently understandable; - avoid overlapping responsibilities; - expose stable identifiers. --- ## 5.4 Object Objects represent semantic entities. Objects SHALL possess: - identity; - lifecycle; - ownership; - provenance; - traceability. --- ## 5.5 Property Properties describe objects. Every property SHOULD declare: - type; - cardinality; - optionality; - origin; - confidence (when applicable). --- ## 5.6 Relationship Relationships connect objects. Relationships SHALL explicitly define: - source; - target; - semantic meaning; - cardinality. --- ## 5.7 Event Events describe meaningful changes. Events SHOULD be immutable and traceable. The Event primitive is defined in detail in [Event](../04-core-concepts/Event.md). --- ## 5.8 Projection A Projection is a context-specific representation of an object. A projection SHALL NOT redefine object identity. --- ## 5.9 Contract Contracts define semantic agreements governing interaction, disclosure or federation. --- ## 5.10 Context Context determines how semantics are interpreted. Context SHALL be explicit whenever meaning depends upon it. --- # 6. Public Schema Every Meta-Model SHALL expose a public schema. The schema SHALL describe structure without requiring disclosure of instance data. Schema discovery SHALL be possible independently from data access. --- # 7. Separation of Schema and Instance MMAS distinguishes: - Meta-Model (schema) - Instance (facts) Knowledge exchange SHALL begin with schema discovery before instance disclosure. --- # 8. External Semantic Models A Meta-Model MAY import external standards. Imported concepts SHALL preserve references to: - originating standard; - version; - namespace. Local extensions SHALL NOT modify the imported semantics. Instead, they SHALL extend them. --- # 9. Extensibility Meta-Models SHALL evolve through extension rather than modification whenever practical. Extensions SHALL: - declare ownership; - declare compatibility; - preserve existing semantics. --- # 10. Technology Independence MMAS defines architecture, not storage. Conforming implementations MAY use: - Git repositories; - Graph databases; - Relational databases; - Document stores; - APIs; - Knowledge graphs; - Event streams. No implementation technology is normative. --- # 11. Architectural Invariants Every MMAS-conforming Meta-Model SHALL preserve: - identity; - semantic consistency; - traceability; - ownership; - context; - versioning; - federation readiness. --- # 12. Relationship to Other Standards MMAS-Core builds upon MUC and supplies the composition model that the remaining MMAS documents specialize: - [Versioning](Versioning.md) versions the hierarchy and its elements; - [Naming Conventions](Naming-Conventions.md) names the hierarchy and its elements; - [Validation](Validation.md) validates the hierarchy across levels V0–V5; - [MMAS-Package](MMAS-Package.md) packages the hierarchy for distribution; - [MMAS-Conformance](MMAS-Conformance.md) measures architectural maturity over the hierarchy. MUFP defines federation behavior. --- # 13. Future Directions The Composition Hierarchy is intentionally finite and stable, but its role as the shared reference model invites a dedicated, machine-actionable expression. A future **Meta-Universe Diagram Language (MUDL)** would standardize the visual and textual notation for the hierarchy and its instances, so that the Mermaid and ASCII renderings in this document become two profiles of one normative diagramming standard rather than illustrative examples. MUDL would cover element shapes, containment semantics, projection overlays and federation views, allowing tools to render any Meta-Model deterministically and round-trip diagrams back into MMAS structures. --- # Final Statement MMAS-Core defines the common architectural language from which every Meta-Model in the Meta-Universe ecosystem is constructed. Domain-specific semantics are intentionally left to individual Meta-Models. ## https://ver.cy/spec/docs/02-architecture/MMAS-Interchange.md # MMAS-Interchange — Meta-Universe Interchange Format (MUIF) **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-009 **Title:** Meta-Universe Interchange Format (MUIF) and Semantic Fingerprint **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** [MMAS-Core](../02-architecture/MMAS-Core.md), [Versioning](../02-architecture/Versioning.md), [Naming-Conventions](../02-architecture/Naming-Conventions.md), RFC 8785 (JSON Canonicalization Scheme), RFC 2119 **Informative References:** [Validation](../02-architecture/Validation.md), [MMAS-Package](../02-architecture/MMAS-Package.md), [Extension-Model](../02-architecture/Extension-Model.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the **Meta-Universe Interchange Format (MUIF)** — the canonical, machine-readable serialization of a meta-model — and the exact **canonicalization algorithm** used to compute a reproducible **Semantic Fingerprint**. MUIF is the concrete face of the abstract model defined by [MMAS-Core](../02-architecture/MMAS-Core.md). It is the foundational artifact on which validation, packaging, migration, federation pre-checks and tooling depend: without a single canonical form, the Semantic Fingerprint referenced throughout the specification would not be reproducible across implementations, and "AI-native" / "machine-readable" would remain claims rather than facts. --- # 2. Scope This document specifies: - the MUIF document model and its serialization (JSON, with YAML permitted); - the JSON Schema definitions for each primitive and for the manifest; - the separation of **semantic** from **non-semantic** content; - the canonicalization algorithm and the Semantic Fingerprint. It does not define transport (see [MUFP](../03-federation/MUFP.md)) or packaging and signing (see [MMAS-Package](../02-architecture/MMAS-Package.md)). --- # 3. The MUIF Document Model A MUIF document encodes the MMAS **Composition Hierarchy**: ```text Meta-Model (manifest) ├── Bundles ── Layers ├── Objects ── Properties ├── Relationships ├── Events ├── Contracts └── Projections ``` The entry point is a **manifest**. Each primitive carries a `muifType` discriminator (`Object`, `Relationship`, `Event`, `Contract`, `Projection`). The normative JSON Schemas (Draft 2020-12) live in [`/schemas`](../schemas/): | Schema | Primitive | |--------|-----------| | `manifest.schema.json` | Meta-Model package entry point | | `object.schema.json` | Object | | `relationship.schema.json` | Relationship | | `event.schema.json` | Event | | `contract.schema.json` | Contract | | `projection.schema.json` | Projection | | `common.schema.json` | Shared definitions (CSN, identifier, provenance, …) | A MUIF document SHALL validate against `manifest.schema.json` (which references the others). --- # 4. Serialization - The canonical serialization is **JSON** (RFC 8259), UTF-8. - **YAML** 1.2 MAY be used for authoring; it SHALL be losslessly convertible to the JSON model. The Semantic Fingerprint is defined over the JSON model, so the choice of JSON or YAML SHALL NOT affect the fingerprint. - Identifiers and Canonical Semantic Names follow [Naming-Conventions](../02-architecture/Naming-Conventions.md). --- # 5. Semantic vs Non-Semantic Content The Semantic Fingerprint is computed over the **semantic core** only. The following are **non-semantic** and SHALL be excluded from canonicalization: - object keys: `displayName`, `description`, `documentation`, `comment`, `label`, `labels`, `ui`, `assertedAt`, `assertionTime`, `generatedAt`, `lastModified`, `fingerprint`, `examples`, `$schema`, `$comment`; - any key beginning with `_` or with `x-ui`. Rationale: changing a human label, a description, a recording timestamp, or the self-declared fingerprint MUST NOT change the meaning of a model and therefore MUST NOT change its fingerprint. Each schema marks such fields **NON-SEMANTIC** in its description. --- # 6. Canonicalization Algorithm Given a MUIF document, the canonical form is produced as follows. 1. **Parse** the document into an abstract value (object / array / string / number / boolean / null). 2. **Project to the semantic core.** Recursively remove every non-semantic key (Section 5). Remove keys whose value is `null`, an empty object, or an empty array — *absent* and *empty* are treated as equivalent. 3. **Normalize values.** - Strings SHALL be normalized to Unicode **NFC**. - **Object keys** SHALL be sorted by ascending Unicode code point (ordinal). - **Arrays SHALL be treated as sets**: each element is canonicalized, then the elements are sorted by the ordinal comparison of their canonical string. (Order-significant sequences are not used by the core model in v1.0; a future revision MAY introduce an explicit ordered-array tag — see Future Directions.) - Integers SHALL be emitted in shortest decimal form without leading zeros or a leading `+`. Other numbers follow the number formatting of RFC 8785 (JSON Canonicalization Scheme). 4. **Serialize** the normalized tree to canonical JSON: UTF-8, sorted keys, no insignificant whitespace, JSON string escaping per RFC 8785. 5. **Hash.** Compute `SHA-256` over the UTF-8 bytes of the canonical JSON. The **Semantic Fingerprint** is: ```text sha256: ``` Two MUIF documents with the same semantic core SHALL yield the same fingerprint, regardless of serialization format, key order, set-array order, whitespace, or non-semantic fields. --- # 7. Worked Example The reference example [`/examples/minimal-person`](../examples/minimal-person/) contains the same model in two very different serializations (`person.muif.json` and a deliberately reordered `person.variant.json` with extra non-semantic fields). Both produce the identical fingerprint: ```text sha256:a628b2afb96dc673f7e2f9161569e573fc70892d10a6997fad7aaa14b04a639d ``` This is verified by the reference tool [`mu-fingerprint`](../tools/): ```text mu-fingerprint examples/minimal-person/person.muif.json mu-fingerprint examples/minimal-person/person.variant.json # → identical sha256:a628b2af...b04a639d ``` --- # 8. Conformance A document is **MUIF-conformant** when: - it validates against `manifest.schema.json` and the referenced schemas; - every primitive declares its `muifType`, `id` and required fields; - its Semantic Fingerprint, when self-declared in `metaModel.fingerprint`, equals the value computed by the canonicalization algorithm of Section 6. A meta-model SHALL be exchangeable as MUIF to claim MMAS conformance at level **A4 Validated** or above (see [MMAS-Conformance](../02-architecture/MMAS-Conformance.md)). --- # 9. Architectural Invariants - The Semantic Fingerprint SHALL be computed over the semantic core only. - The fingerprint SHALL be independent of serialization, key order, set order, whitespace and non-semantic fields. - A change in meaning SHALL change the fingerprint; a change in formatting or labels SHALL NOT. - `metaModel.fingerprint` SHALL be excluded from its own computation. --- # Future Directions - **Full RFC 8785 compliance** for all number forms, and a conformance test vector set for canonicalization (feeds the WS Semantic Test Kit). - **Ordered-array tagging** for the rare cases where array order is semantically significant. - **Signed MUIF / SDP**: detached signatures over the canonical bytes, enabling the Semantic Distribution Package (see [MMAS-Package](../02-architecture/MMAS-Package.md)). - A formal **MMAS metamodel** (grammar) from which the schemas are generated. --- # Final Statement > A model means the same thing no matter how it is written down. MUIF makes that > precise: one canonical form, one fingerprint — so that two systems can agree > they are talking about exactly the same meaning before they exchange a single > fact. ## https://ver.cy/spec/docs/02-architecture/MMAS-Package.md # MMAS Package **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-007 **Title:** Meta-Model Architecture Standard — Repository and Package Structure **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS-Core, Versioning **Informative References:** Extension-Model, MMAS-Conformance, Meta-Universe Federation Protocol (MUFP), Model-Traversal-and-Layout, Data-Mastership **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the canonical repository and package structure for Meta-Models conforming to the Meta-Model Architecture Standard (MMAS). The objective is to ensure that every Meta-Model has a predictable organization that is understandable by both humans and AI agents. --- # 2. Scope This specification applies to: - Meta-Model repositories; - distributable Meta-Model packages; - repository manifests; - bundles; - layers; - supporting assets; - examples and documentation. Implementations MAY use additional files provided they do not violate this specification. --- # 3. Design Principles A conforming package SHALL be: - modular; - self-describing; - versioned; - traceable; - machine-readable; - human-readable; - suitable for federation. Repository structure SHALL reflect semantic architecture rather than implementation technology. --- # 4. Canonical Repository Structure Every Meta-Model SHOULD follow the canonical structure below. ```text meta-model/ │ ├── README.md ├── BOOTSTRAP.md # operating instructions: how to read this model (read first) ├── LICENSE ├── CHANGELOG.md ├── manifest.yaml ├── sources.yaml # Data Mastership Register: System of Record per dataset │ ├── bundles/ │ ├── / │ │ ├── bundle.yaml │ │ ├── README.md │ │ ├── / │ │ │ ├── layer.yaml │ │ │ ├── objects/ │ │ │ ├── relationships/ │ │ │ ├── events/ │ │ │ ├── contracts/ │ │ │ └── projections/ │ │ └── ... │ └── ... │ ├── canon/ # canonical source texts the model treats as ground truth ├── raw/ # unprocessed harvested captures from external systems (never hand-edited) ├── artifacts/ # generated, regenerable outputs (never authored) ├── imports/ ├── mappings/ ├── schemas/ ├── examples/ ├── diagrams/ ├── docs/ └── tools/ ``` Equivalent layouts MAY be used if semantic organization is preserved. The traversal contract over this structure (deterministic bundle/layer walk order, total file classification, the completeness check) and the reserved meanings of `BOOTSTRAP.md`, `canon/`, `raw/` and `artifacts/` are defined normatively in [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md). The `sources.yaml` register and the rules for deciding whether the model or an external system (a wiki, a tracker, a database) is the master of a dataset are defined in [Data-Mastership](Data-Mastership.md). --- # 5. Repository Manifest Every repository SHALL contain a manifest. The manifest SHOULD declare: - identifier; - name; - version; - owner; - namespace; - supported MMAS version; - supported MUC version; - supported MUFP version; - imported standards; - compatibility statement. The manifest is the primary entry point for automated discovery. --- # 6. Bundle Structure Every Bundle SHOULD contain: - bundle manifest; - documentation; - layers; - optional examples. Bundles SHALL have a single semantic responsibility. --- # 7. Layer Structure Each Layer SHOULD contain: - layer manifest; - object definitions; - relationships; - events (if applicable); - contracts (if applicable); - projection profiles (if applicable). Layers SHOULD remain independently understandable. --- # 8. Documentation Every public repository SHOULD include: - README; - architecture overview; - change history; - licensing information; - contribution guidance (optional). Documentation SHALL remain synchronized with the published version. --- # 9. Examples Reference examples SHOULD be stored separately from normative specifications. Examples SHALL NOT redefine normative semantics. Example artifacts SHOULD identify the specification version they target. --- # 10. Imported Standards Imported semantic models SHOULD be isolated under the imports/ directory. Mappings between imported and local concepts SHOULD be stored under mappings/. Imported artifacts SHALL preserve references to their original source and version. --- # 11. Repository Metadata A repository SHOULD expose machine-readable metadata sufficient for discovery. Recommended metadata includes: - semantic fingerprint; - supported profiles; - package checksum; - publication date; - repository URL; - digital signature (optional). --- # 12. Packaging A distributable MMAS package SHALL preserve: - directory structure; - manifests; - identifiers; - semantic references; - version metadata. Packaging format is implementation-specific. Examples include Git repositories, archives or registries. --- # 13. Semantic Distribution Package (SDP) While Section 4 defines the canonical *repository* layout, federation requires a portable, publishable *distribution* unit. A **Semantic Distribution Package (SDP)** is that unit: a single, signed, self-contained artifact that carries a Meta-Model (or a bounded part of it) together with everything needed to verify, place and use it in another universe — analogous to a Maven, npm or OCI artifact, but for semantic models rather than code or images. A conforming SDP SHALL contain: - a **manifest** (`manifest.yaml`) — identity, version, owner, namespace and supported standard versions, as in Section 5; - the **bundles and layers** that constitute the packaged Meta-Model; - the package **[Semantic Fingerprint](Versioning.md)** computed over the normalized semantic structure; - a **digital signature** binding the contents to a publisher; - a **conformance declaration** stating MUC, MMAS and MUFP conformance (see [MMAS-Conformance](MMAS-Conformance.md)); - the list of **imported standards** and the corresponding [Semantic Packages](Extension-Model.md); - the **semantic mappings** between imported and local concepts; - optional **projections** and **examples** that aid interpretation without redefining semantics. A representative SDP, expanded, has the following shape: ```text employee-mm-2.3.1.sdp │ ├── manifest.yaml # identity, version, conformance declaration ├── bundles/ # bundles & layers (objects, relationships, events, contracts, projections) ├── mappings/ # semantic mappings to imported standards ├── imports/ # imported Semantic Packages (Schema.org, O*NET, FHIR, …) ├── examples/ # optional reference examples ├── fingerprint.sha256 # Semantic Fingerprint of the normalized structure └── signature.sig # digital signature of the package ``` An SDP SHALL be self-verifying: a consumer SHALL be able to recompute the Semantic Fingerprint from the contained structure, check it against `fingerprint.sha256`, and validate the signature before trusting the package. The SDP is the on-the-wire and on-the-shelf form of the same composition the repository holds; it SHALL NOT redefine semantics, only package them. --- # 14. Repository Evolution Repository structure SHOULD evolve compatibly. Structural changes that affect discovery or interoperability SHALL be versioned and documented. Migration guidance SHOULD accompany structural changes. --- # 15. AI-Native Requirements A conforming repository SHOULD allow AI agents to: - discover the manifest; - enumerate bundles and layers; - resolve imports; - identify dependencies; - locate examples; - determine conformance; - navigate the model without implementation-specific knowledge. Repository layout SHOULD minimize ambiguity for automated reasoning. --- # 16. Architectural Invariants Repository organization SHALL preserve: - semantic identity; - traceability; - ownership; - version integrity; - constitutional compliance. Repository structure SHALL NEVER redefine semantic meaning. --- # 17. Future Directions The Semantic Distribution Package makes Meta-Models portable; the natural next step is to make them **discoverable and resolvable at scale**. A future direction is for the ecosystem layer (`06-ecosystem`) to operate as a **Semantic Package Registry**: a federation-aware service that indexes published SDPs and [Semantic Packages](Extension-Model.md) by identity, [Semantic Fingerprint](Versioning.md), conformance level and compatible version range, and that resolves dependencies and migrations on request — the semantic-knowledge counterpart of Maven Central, npm or an OCI registry. Such a registry would standardize publication, signature trust, search and retrieval so that any universe can locate, verify and adopt a Meta-Model without out-of-band coordination. --- # Final Statement The MMAS package structure is the canonical physical organization of a Meta-Model. Its purpose is to make semantic models discoverable, reusable, extensible and interoperable across repositories, organizations and AI agents while remaining independent of implementation technologies. ## https://ver.cy/spec/docs/02-architecture/Meta-Model-Composition.md # Meta-Model Composition **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-016 **Title:** Meta-Model Architecture Standard — Composition, Nesting and Connectors **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS-Core, [Extension-Model](Extension-Model.md), [Semantic-Mapping](../03-federation/Semantic-Mapping.md) **Informative References:** [Relationship](../04-core-concepts/Relationship.md), [Object](../04-core-concepts/Object.md), [Projection](../04-core-concepts/Projection.md), [Connector-Catalogue](../06-ecosystem/Connector-Catalogue.md), [External-Models-Registry](../06-ecosystem/External-Models-Registry.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose [Extension-Model](Extension-Model.md) defines how a Meta-Model **imports and extends** an external standard. [Semantic-Mapping](../03-federation/Semantic-Mapping.md) defines how two sovereign Meta-Models **align meaning** without merging. This document fills the layer between them: **structural composition** — how the *Properties* of one Meta-Model relate to *other Meta-Models*, and the rule for deciding, for any given concept, whether it should be: - a **literal Property** (a field) held by the Meta-Model itself; or - an **embedded** nested Meta-Model (the Property's type *is* another model); or - a **reference** to a separately governed entity or code list. Without this layer the registered models are semantic islands: the same concept — an address, a country, a money amount, a provenance record — is re-modelled independently in dozens of Meta-Models with diverging shapes, so they duplicate fields and cannot be composed, joined or validated together. This document defines the principles, mechanisms and connectors that turn the catalogue of [External Models](../06-ecosystem/External-Models-Registry.md) into a connected fabric. --- # 2. The Composition Problem A Meta-Model author repeatedly meets a concept that *could* be a simple field but is in fact a thing the wider ecosystem already models. Three failures follow from treating every such concept as a local field: - **Forking** — `street`, `city`, `postcode`, `country` modelled ad-hoc in one Meta-Model and differently in the next: the Address concept is forked and the two cannot interoperate. - **Drift** — a country or currency list copied into a local enumeration silently diverges from the authority that maintains it. - **Staleness** — an employer's attributes inlined into a Person rather than referenced: every Person carries a private, ageing copy of the same Organization. Meta-Universe SHALL prefer **composition over duplication** — the structural counterpart of the **extension over duplication** principle of [Extension-Model](Extension-Model.md) §3. The remainder of this document makes that preference operational. --- # 3. Kinds of Concept Every concept appearing in a Meta-Model SHALL be classified, for the purpose of representation, as exactly one of the following kinds. The kind determines the permitted composition mechanism (§4) via the decision rubric (§5). | Kind | Definition | Test | Default representation | |------|------------|------|------------------------| | **Attribute** | A literal value with no independent identity, no internal structure, and no external authority over its values. | "Is it just a value the host owns?" | Property (field) | | **Value Object** | A structured bundle of sub-values that travel together and are equal when their parts are equal; it has no identity of its own. | "Does it have ≥2 parts that only make sense as a unit?" | EMBED | | **Entity** | A thing with its own identity and lifecycle, referenceable and shareable independently of any host. | "Can other Objects point at it; can it be created, versioned, owned on its own?" | REFERENCE | | **Code / Classifier** | A member of a value set, classification or identifier scheme governed by an external authority. | "Is the set of allowed values maintained by someone else?" | REFERENCE (to the scheme) | | **Facet** | A cross-cutting concern attached to many Objects regardless of domain — provenance, valid-time, policy, security marking, multilingual labels. | "Is this *about* the data rather than *part of* the domain payload?" | MIX-IN | A concept's kind is a modelling decision, not an intrinsic truth: the same word ("address", "organization") may be an Entity in one Meta-Model and a Value Object snapshot in another. The author SHALL record the chosen kind so that validators and consumers can reason about it. --- # 4. Composition Mechanisms Six mechanisms connect Meta-Models. Each has a distinct coupling and sovereignty profile. Two of them — **EXTEND** and **MAP** — are specified elsewhere and are listed here only for completeness; this document specifies **EMBED**, **REFERENCE** and **MIX-IN**. | # | Mechanism | What it does | Coupling | Sovereignty | Specified in | |---|-----------|--------------|----------|-------------|--------------| | 1 | **EMBED** (composition) | A Property's type *is* another Meta-Model; the value travels inside the host as a nested Object with no independent identity. | Tight — host owns the composite | Nested model's *shape* is reused; its authority is preserved | **this document** | | 2 | **REFERENCE** (association) | A Property holds an identifier resolved against an external entity or code scheme; the referent lives and is governed elsewhere. | Loose | Fully preserved — referent stays sovereign | **this document** | | 3 | **MIX-IN** (facet / trait) | A cross-cutting Package's Properties are applied uniformly to many host Objects under their own namespace. | Orthogonal | Facet model stays authoritative | **this document** | | 4 | **EXTEND** (specialization) | The host Meta-Model is-a / refines an imported model, adding constraints or Properties. | Tight (subtype) | Per import rules | [Extension-Model](Extension-Model.md) §8 | | 5 | **MAP** (alignment) | Two sovereign models declare field equivalences without structural change. | None (structural) | Maximum | [Semantic-Mapping](../03-federation/Semantic-Mapping.md) | | 6 | **ANNOTATE** (tagging) | A controlled-vocabulary concept is attached to a Property for meaning, not structure. | None | Maximum | this document (§4.3) | ## 4.1 EMBED EMBED is used for **Value Objects**. The host Property is typed by another Meta-Model (preferably one imported as a [Semantic Package](Extension-Model.md §4)), and the embedded value: - SHALL preserve the embedded model's namespace, version and [Semantic Fingerprint](Versioning.md); - SHALL NOT be flattened into ad-hoc host Properties; - has **no independent identity** in the host — it is a value, equal to any other embedded value with the same parts; - contributes its shape to the host's own Semantic Fingerprint, so that two hosts that "have an address" can be shown to agree on what an address is. EMBED is the correct mechanism precisely when a concept has internal structure that recurs across the ecosystem (Address, Money, Quantity, Geographic Point, Personal Name, Temporal Interval). ## 4.2 REFERENCE REFERENCE is used for **Entities** and **Codes**. The host Property holds an identifier, not a copy of the referent's contents. - **Entity reference** — modelled as a [Relationship](../04-core-concepts/Relationship.md) to a Meta-Object identified by its canonical identifier, or as an identifier Property typed by an identifier scheme. The referent's attributes SHALL NOT be inlined; they are obtained by resolving the reference (subject to [Contract](../04-core-concepts/Contract.md) and [Projection](../04-core-concepts/Projection.md) when the referent is in another Universe). - **Code reference** — modelled as a Property whose value is "a term drawn from scheme *S*", carrying the scheme's URI and version. The members of *S* SHALL NOT be copied into a local enumeration; carrying the scheme + version makes drift detectable. A reference MAY be **snapshotted** — embedded as an immutable value copy — when audit or immutability requires a frozen view (for example a Projection capturing an address as it stood at a point in time). A snapshot SHALL be marked as such and SHALL record the source identifier and the capture Event, so it is never mistaken for the live referent. This is the legitimate face of "duplication" (§6). ## 4.3 MIX-IN and ANNOTATE A **Facet** SHALL be applied as a MIX-IN: a declared facet Package whose Properties merge into the host under their own namespace and are applied uniformly across many Objects (for example `prov:*` provenance on every Object, valid-time on every versioned Object, `odrl:*` policy on a Contract). A Facet SHALL NOT be re-invented as bespoke domain fields, and SHALL NOT be buried in the domain payload — it is *about* the data. ANNOTATE attaches a controlled-vocabulary concept (a SKOS concept, a schema.org type) to a Property to fix its meaning without changing its structure. It is the lightest mechanism and preserves full sovereignty. --- # 5. The Decision Rubric For any concept *C* appearing in Meta-Model *M*, apply the following tests **in order**; the first that matches fixes the representation. 1. **Facet test (orthogonal, applied first).** Is *C* a cross-cutting concern (provenance, valid-time, access policy, security marking, multilingual label) rather than domain payload? → **MIX-IN** the relevant facet model. Stop. 2. **Identity test.** Does *C* denote a thing with its own identity and lifecycle, that can be referred to, created, versioned or owned independently of *M*? → *C* is an **Entity**: **REFERENCE** it by identifier. Embed only as a marked **snapshot** when immutability/audit demands it. Stop. 3. **Authority test.** Is *C*'s set of permitted values, or its internal structure, already governed by an external standard? - A **code list / classification / identifier scheme** → **REFERENCE** that scheme (term + scheme URI + version). Never copy its members. Stop. - A **structured value-object standard** (Address, Money, …) → prefer that canonical model and continue to the Structure test. 4. **Structure test.** Does *C* have internal structure — two or more sub-values that travel together and would be meaningless split across the host? → *C* is a **Value Object**: **EMBED** it as a nested Meta-Model (preferably an imported canonical one). Do not flatten its parts. Stop. 5. **Reuse test.** Even if *C* is currently atomic, do two or more Meta-Models in scope need it in the same shape (now or foreseeably)? → factor *C* out as a shared Value Object and EMBED/REFERENCE it, so the shape is defined once. Stop. 6. **Default.** *C* is an **Attribute**: a literal with no independent identity, no external authority, no internal structure and no cross-model reuse. Represent it as a **Property (field)**. Duplicating such a field across Meta-Models is acceptable (§6). ```text ┌───────────────────────────────────────────────┐ concept C │ 1. cross-cutting concern? ── yes ─▶ MIX-IN │ │ 2. own identity/lifecycle? ── yes ─▶ REFERENCE │ │ 3. governed value set? ── yes ─▶ REFERENCE │ │ 4. internal structure? ── yes ─▶ EMBED │ │ 5. reused across models? ── yes ─▶ EMBED │ │ 6. otherwise ─────────▶ FIELD │ └───────────────────────────────────────────────┘ ``` A conforming Meta-Model SHOULD be able to justify each Property by naming the test that produced its representation. --- # 6. When Duplication Is Acceptable Composition over duplication is a default, not an absolute. Duplicating a value, or holding the "same" concept as a plain field in several Meta-Models, is **correct** in these cases: - **Atomic attributes.** A `title`, a `quantity`, a free-text `note` — a literal with no shared authority. Two Meta-Models each holding such a field are not forking a concept; they hold two independent properties that happen to share a name. - **Immutable snapshots.** A Projection, audit record or [Conflict Preservation](../03-federation/Conflict-Resolution.md) entry that deliberately freezes a value copy for immutability or locality. Here the *copy is the point*; it SHALL be marked as a snapshot with its source identifier and capture Event (§4.2). - **Sovereignty by mapping.** When two models are independently governed and a crosswalk ([Semantic-Mapping](../03-federation/Semantic-Mapping.md)) is preferable to structural coupling, each keeps its own fields and the link is a MAP, not an EMBED. - **Avoiding over-normalization.** When extracting a shared model would add more coupling than the concept is worth (a one-off, genuinely local atomic value), keeping a field is the proportionate choice. Duplication is a **defect** only when it forks a *structured* Value Object, *copies* a governed code list, *inlines* an Entity, or *re-invents* a Facet — the four cases the rubric is designed to catch. --- # 7. Compositional Roles of External Models To make composition predictable at ecosystem scale, every external model in the [Registry](../06-ecosystem/External-Models-Registry.md) can be assigned a **compositional role** that predicts how other models should link to it. The [Connector-Catalogue](../06-ecosystem/Connector-Catalogue.md) applies these roles to the foundational connectors, and all 1180 catalogued standards carry a role and a default link type in [`external-models.csv`](../06-ecosystem/external-models.csv) (distribution in [External-Models-Registry §3a](../06-ecosystem/External-Models-Registry.md)). | Role | Description | Default link | Examples | |------|-------------|--------------|----------| | **R1 Foundational Value-Object** | Structured, identity-free, recurs everywhere | EMBED | Address (CIQ xAL), Money, Quantity (QUDT), GeoPoint, Personal Name, Temporal Interval | | **R2 Reference Data / Code List** | Curated value set or classification | REFERENCE | ISO 3166, ISO 4217, ISO 639, UCUM, GPC, NACE, ESCO, SNOMED CT | | **R3 Identifier Scheme** | Keys for entities | REFERENCE | LEI, ISIN, GTIN, GLN, DOI, ORCID/ISNI, IBAN/BIC, DID | | **R4 Entity Model** | Things with identity and lifecycle | REFERENCE; snapshot-EMBED | schema:Organization, FHIR Patient, W3C ORG, schema:Place | | **R5 Cross-cutting Facet** | Concerns applied across many Objects | MIX-IN | PROV-O, OWL-Time, ODRL, SKOS-XL labels | | **R6 Aggregate / Document** | Composes R1–R5 into a document | composes (rarely embedded) | UBL Invoice, C-CDA, EPCIS Event, Order | | **R7 Upper Ontology / Foundation** | Ontological grounding | ALIGN / ANNOTATE | BFO, DOLCE, ISO 15926 upper, Common Logic | | **R8 Mapping / Lifting Tooling** | Implements MAP / transformation | n/a (tooling) | R2RML, RML, SAWSDL | Roles are guidance, not law: a model MAY be embedded in one context and referenced in another. The role names the *typical* and *recommended* link. --- # 8. Expressing Composition in MMAS Each mechanism has a concrete MMAS expression. Every link, regardless of mechanism, SHALL preserve the linked model's **namespace, version, provenance and Semantic Fingerprint**, and SHALL NOT violate the import invariants of [Extension-Model](Extension-Model.md) §18. - **EMBED** — a Property typed by a Meta-Object type from another Namespace; the embedded model is declared as a Semantic Package dependency; the host fingerprint incorporates the embedded shape. - **REFERENCE (entity)** — a [Relationship](../04-core-concepts/Relationship.md) to a Meta-Object, or an identifier-typed Property; cross-Universe references are governed by Contract and exchanged as Projections. - **REFERENCE (code)** — a Property typed `term ∈ scheme`, carrying scheme URI + version; validators MAY check membership and detect drift. - **MIX-IN** — a facet Package merged under its own namespace; applied uniformly; declared in the Meta-Model's facet list. - **EXTEND** / **MAP** / **ANNOTATE** — as specified in their owning documents. A Meta-Model SHOULD declare, for each Property, its **composition kind** (attribute / embed / reference / mixin) and, for embed and reference, the connector identifier and version. This declaration is what makes a model's composition machine-checkable. --- # 9. Worked Example — `employee.person` A single Person concept exercises every mechanism: | Concept | Kind | Mechanism | Connector | |---------|------|-----------|-----------| | name | Value Object | EMBED | Personal Name (CIQ xNL / schema name parts) | | address | Value Object | EMBED | Postal Address (CIQ xAL / vCard ADR) | | nationality | Code | REFERENCE | ISO 3166-1 | | primaryLanguage | Code | REFERENCE | ISO 639 (+ ISO 15924 script) | | salary | Value Object | EMBED | Monetary Amount (amount + ISO 4217 currency) | | height | Attribute (+unit) | FIELD + REFERENCE | literal value; unit ∈ UCUM | | employer | Entity | REFERENCE | Organization by ISO 17442 LEI | | orcid | Identifier | REFERENCE | ORCID / ISO 27729 ISNI | | provenance | Facet | MIX-IN | PROV-O | | validFrom/validTo | Facet | MIX-IN | OWL-Time / Lifecycle valid-time | | accessPolicy | Facet | MIX-IN | ODRL | For federation, the same `person` then **MAPs** to `fhir:Patient` and `foaf:Person` via [Semantic-Mapping](../03-federation/Semantic-Mapping.md) — no field of the Person is duplicated to achieve interoperability; only correspondences are declared. --- # 10. Anti-Patterns - **Flattened Value Object** — `addr_line1`, `addr_city`, `addr_zip` as host fields instead of an embedded Address. Forks the concept; blocks join and validation. - **Copied code list** — a local `country` enum instead of a reference to ISO 3166. Drifts from the authority. - **Inlined entity** — an employer's name/address/registration copied into every Person instead of a reference. Produces stale duplicates; violates the referent's sovereignty. - **Re-invented facet** — bespoke `created_by` / `created_at` / `source` fields instead of a PROV mix-in. Fragments provenance across the ecosystem. - **Over-embedding** — wrapping a genuinely atomic attribute in a nested model. Needless coupling; the inverse mistake. - **Embedding an entity by value** — copying a thing that has identity, losing its identity, lifecycle and sovereignty. These map one-to-one onto the failures the rubric (§5) is designed to prevent and extend [Common Design Mistakes](../05-reference-architecture/Anti-Patterns.md). --- # 11. Validation and Conformance A conforming implementation SHOULD validate that: - every Property declares a composition kind; - embed and reference Properties name a connector and a version; - code-typed Properties carry a scheme URI and version (drift-detectable); - no Property cluster reproduces the shape of a known Value Object connector as flat fields (a forking check); - snapshots are marked and carry source identifier and capture Event. These checks are recommended additions to the [Validation](Validation.md) levels and the [Semantic Test Kit](../tests/). Composition declarations are themselves part of the Meta-Model and therefore covered by its Semantic Fingerprint. --- # 12. Architectural Invariants Composition SHALL NEVER violate: - the **Meta-Universe Constitution** and semantic sovereignty — referenced and embedded models retain their own authority, identity and governance; - **provenance and traceability** — every link records origin, namespace and version; - **version integrity** — links are version-aware; a change in a connector triggers compatibility assessment, not silent migration; - **the import invariants** of [Extension-Model](Extension-Model.md) §18. --- # Final Statement A field is the right answer more often than not — but not when the "field" is secretly an address, a country, an organization or a provenance record that the rest of the world already models. Meta-Model Composition gives authors a single rule for telling these apart, three mechanisms (embed, reference, mix-in) for wiring them together, and a catalogue of connectors to wire them to. It is the layer that turns a registry of a thousand isolated standards into a composable fabric — where a concept is modelled once and reused everywhere, without any model surrendering its sovereignty. ## https://ver.cy/spec/docs/02-architecture/Model-Traversal-and-Layout.md # Model Traversal and Well-Known Locations **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-017 **Title:** Meta-Model Architecture Standard - Lossless Traversal and Well-Known Locations **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** MMAS-Core, MMAS-Package, Versioning, Validation, Data-Mastership **Informative References:** Traceability, AI-Agent-Guide, Repository-Structure **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose [MMAS-Package](MMAS-Package.md) defines *where things live* in a Meta-Model repository. This document defines the two guarantees that layout alone cannot give: 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 exactly once**, knowing **what each file means**, and **proving that nothing was missed**. 2. **Well-known locations.** Content that is not a semantic definition (raw source data, canonical source texts, generated artifacts, operating instructions) SHALL live in reserved locations with predefined meaning, so a reader never has to guess what a file is. Together with [Data-Mastership](Data-Mastership.md), which declares *who owns the truth* for every dataset, this makes a Meta-Model fully mechanically readable: nothing lost, nothing ambiguous, nothing of unknown authority. --- # 2. Scope This specification applies to: - Meta-Model repositories and Semantic Distribution Packages; - manifests at repository, bundle and layer level; - all files contained in a model repository, without exception; - walkers: any tool or agent that enumerates model content. It does not redefine the semantics of Objects, Relationships, Events, Contracts or Projections; it governs how their carrier files are found, ordered and classified. --- # 3. Design Principles - **One entry point.** Every walk starts at the same place; there is no tribal knowledge about where to begin. - **Declared order.** The reading order is data, not convention: manifests declare it, walkers follow it. - **Total classification.** Every file is classified. A file whose meaning cannot be determined from the manifests and this specification is a defect, not a curiosity. - **Meaning travels with structure.** Each enumerated unit carries a stated meaning; a reader should never need to open a file to discover what kind of thing it is. - **Authored, harvested and generated content never mix.** Their lifecycle rules differ, so their locations differ. --- # 4. The Entry Point A conforming repository SHALL be readable starting from exactly two files at its root: 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 here. A walker SHOULD read it first. `BOOTSTRAP.md` MAY delegate to a `bootstrap/` directory for extended instructions (agent prompts, onboarding, checklists). Bootstrap content SHALL NOT define semantics; it explains, it never declares. 2. **`manifest.yaml`** - the machine entry point defined in [MMAS-Package](MMAS-Package.md) §5, extended by this document with the walk declaration (§5) and the exclusion list (§7). If `BOOTSTRAP.md` is absent, the walker proceeds from the manifest alone; absence of the manifest makes the repository non-conforming. 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 `BOOTSTRAP.md` and `manifest.yaml` rather than a second source of truth. --- # 5. The Walk Declaration Traversal order is declared top-down: - The **repository manifest** SHALL declare the ordered list of bundles (`bundles:` in reading order). - Each **bundle manifest** (`bundle.yaml`) SHALL declare the bundle's single semantic responsibility and the ordered list of its layers. - 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**. 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 declare classification once, as an ordered list of match rules in the repository manifest (`kind_rules`): each rule maps a glob pattern to a kind and an origin (§9); the first matching rule wins. In such rules the placeholder `{prefix}` denotes the file-name segment before the first delimiter, so a single rule like `kind: "object/{prefix}"` classifies a whole naming convention. Centralized rules are equivalent to per-layer enumeration for the coverage check (§7); a file matched by no rule is an orphan either way. Ordering rules: - Bundles SHALL be ordered so that a bundle appears **after** every bundle it depends on (foundation first). Cyclic bundle dependencies are non-conforming. - Layers within a bundle SHALL be ordered the same way. - Forward references (a file mentioning a concept defined later in the walk) are permitted, but the *declaration* order SHALL remain dependency-first, so that a single sequential pass reads definitions before heavy use. A walker that visits bundles, then layers, then enumerated files, each in declared order, performs the **canonical walk**. Two walkers performing the canonical walk over the same repository version SHALL visit the same files in the same order. --- # 6. Well-Known Locations Beyond the structural directories of [MMAS-Package](MMAS-Package.md) §4 (`bundles/`, `imports/`, `mappings/`, `schemas/`, `examples/`, `diagrams/`, `docs/`, `tools/`), this document reserves the following locations. Each has a fixed default meaning; a walker MAY rely on it without further declaration. | Location | Meaning | Lifecycle | |----------|---------|-----------| | `BOOTSTRAP.md`, `bootstrap/` | Operating instructions for readers and agents: how to read, update and validate this model | Authored | | `canon/` | Canonical source texts this model treats as ground truth: doctrine, adopted decisions, normative inputs, source specifications | Authored or adopted; versioned; never generated | | `raw/` | Unprocessed captures from external systems: exports, dumps, transcripts, crawl results | Harvested; NEVER hand-edited | | `artifacts/` | Derived, regenerable outputs: compiled views, rendered documents, computed indexes, reports | Generated; NEVER authored | | `sources.yaml` | The Data Mastership Register: every dataset's System of Record (see [Data-Mastership](Data-Mastership.md)) | Authored | Rules: - **`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 than paraphrase them; if a layer statement and a canon text conflict, the canon text wins within that model. - **`raw/`** SHALL be organized as `raw///...`. Every dataset directory SHALL carry a provenance sidecar (`_provenance.yaml`: source system, scope, extraction time, extracting tool, record count). Raw content is evidence; correcting it by hand destroys its evidentiary value and is non-conforming. Corrections happen in the source system (then re-harvest) or in the semantic layer (as an annotated deviation). - **`artifacts/`** entries SHALL declare their generator and inputs (a sidecar or a header line suffices). A conforming repository can delete `artifacts/` entirely and rebuild it; if it cannot, something is misfiled. - A repository SHOULD NOT invent parallel locations for these purposes (`_raw/`, `generated/`, `sources/` and similar). Where legacy layouts exist, the manifest SHALL map them to the reserved meanings. --- # 7. The Completeness Rule (No File Left Behind) Every file in the repository SHALL fall into exactly one of three classes: 1. **Enumerated** - matched by a layer manifest's content declaration (§5), or a structural directory of MMAS-Package §4 with its defined role; 2. **Well-known** - located under a reserved location of §6, inheriting its default meaning; 3. **Excluded** - matched by the manifest's exclusion list (`exclude:`), which names infrastructure files with no semantic content (VCS internals, CI configuration, editor settings, build caches). 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 no class ("orphans") and files in more than one class ("ambiguous") are validation failures. The coverage check is part of **structural validation (V1)** in [Validation](Validation.md). The exclusion list is a declaration, not a dumping ground: excluding a file asserts it carries **no model meaning**. Excluding semantic content to pass the coverage check is non-conforming. --- # 8. File Kinds Every enumerated file SHALL carry one kind. The base vocabulary: `object` · `relationship` · `event` · `contract` · `projection` · `canon` · `raw` · `artifact` · `mapping` · `import` · `schema` · `example` · `diagram` · `doc` · `tool` · `bootstrap` · `manifest` 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 definition table); the kind, not the extension, decides how a reader treats it. Ecosystems MAY refine the vocabulary with sub-kinds (`object/policy`, `doc/adr`) but SHALL preserve the base kind as prefix. Sub-kinds MAY be derived mechanically from declared naming conventions via the `{prefix}` placeholder of §5. --- # 9. Authored, Harvested, Generated Orthogonal to kind, every file has exactly one **origin**: - **Authored** - written by a human or an agent acting as author; edited in place; reviewed like code. - **Harvested** - captured from an external system by a pipeline; replaced by re-harvesting; never edited in place. - **Generated** - computed from other files in this repository; replaced by re-generation; never edited in place. 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 files in place is non-conforming: the fix belongs in the source system or the generator. This distinction is what makes mastership (see [Data-Mastership](Data-Mastership.md)) enforceable in practice: a file's origin tells a reader immediately whether *this* copy can ever be the truth. --- # 10. The Canonical Walk (Informative) A conforming walker: 1. Reads `BOOTSTRAP.md` (context, constraints, local conventions). 2. Reads `manifest.yaml`: identity, versions, bundle order, exclusion list. 3. Reads `sources.yaml`: which datasets are mastered here and which are mirrors (with freshness). 4. Visits `canon/` as declared or referenced, so ground truth is loaded before interpretation. 5. Walks bundles in declared order; within each, layers in declared order; within each, enumerated files, reading kind and meaning before content. 6. Resolves `imports/` and `mappings/` when a layer references them. 7. Treats `raw/` as evidence (consulted, not recited) and `artifacts/` as disposable views. 8. Runs the coverage check (§7) and reports orphans, ambiguities and stale mirrors. The walk is complete when every file is accounted for and every dataset's authority is known. --- # 11. AI-Native Requirements A conforming repository SHALL allow an AI agent, without out-of-band knowledge, to: - find the entry point and operating instructions; - enumerate all content in a deterministic order; - state, for any file, its kind, origin and one-line meaning; - prove coverage: name every file it did not read and why (excluded, generated, raw evidence); - distinguish what it may edit (authored, in the model's mastery) from what it must not (harvested, generated, externally mastered). An agent that cannot satisfy the last point SHOULD refuse write operations on the model. --- # 12. Architectural Invariants Traversal and layout SHALL preserve: - semantic identity and ownership; - provenance of harvested and generated content; - the single-entry-point property; - determinism of the canonical walk; - constitutional compliance. Layout and traversal SHALL NEVER redefine semantic meaning; they only make it reachable. --- # 13. Future Directions A reference walker (`mu-walk`) is a natural companion to the existing tools: it would perform the canonical walk, emit a machine-readable walk report (files, kinds, origins, coverage result, mirror freshness) and serve as the executable definition of this document. A walk report could become part of the Semantic Distribution Package, letting consumers verify completeness before trusting a package. --- # Final Statement A Meta-Model is only as trustworthy as a reader's ability to know that they have seen all of it and understood what each part is. This standard turns that ability from diligence into a contract: one entry point, a declared order, a total classification of files, reserved places for instructions, canon, raw evidence and derived artifacts, and a coverage check that makes silent loss impossible. ## https://ver.cy/spec/docs/02-architecture/Naming-Conventions.md # Naming Conventions **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-003 **Title:** Meta-Model Architecture Standard — Naming Conventions **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS-Core **Informative References:** Versioning, Meta-Universe Federation Protocol (MUFP) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the naming rules used throughout the Meta-Universe ecosystem. Consistent naming improves discoverability, semantic interoperability, federation, automation and long-term maintainability. --- # 2. Scope These rules apply to: - Meta-Universe standards - Meta-Models - Bundles - Layers - Objects - Properties - Relationships - Events - Contracts - Projection Profiles - Namespaces Implementations MAY define additional local conventions provided they remain compatible with this specification. --- # 3. Naming Principles Names SHALL be: - unambiguous; - stable; - human-readable; - machine-readable; - technology independent; - semantically meaningful. Names SHALL describe concepts rather than implementation details. --- # 4. Canonical Language English SHALL be the canonical language for all normative names. Localized labels MAY be provided as metadata. Canonical identifiers SHALL remain language-independent. --- # 5. Identifier vs Display Name Every significant artifact SHOULD distinguish between: - Identifier (stable) - Display Name (human-friendly) Example: Identifier: employee.performance-review Display Name: Employee Performance Review Display names MAY change. Identifiers SHOULD remain stable. --- # 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 SHALL have both: - a **Human / Display Name** — localized, human-friendly, and free to change (for example "Salary Agreement"); - an immutable **Canonical Semantic Name (CSN)** — a stable, technology-independent identifier of meaning (for example `employee.compensation.salaryAgreement`). Example: ```text Display Name : Salary Agreement CSN : employee.compensation.salaryAgreement ``` The CSN is analogous to a fully-qualified class name or an RDF URI, but it is deliberately **technology-independent**: it commits to no programming language, serialization or transport. It expresses the position of a concept within its semantic hierarchy and nothing more. Rules: - Every public concept SHALL have exactly one CSN. - A CSN SHALL be immutable once published; renaming a concept SHALL be treated as a semantic change under [Versioning](Versioning.md) and SHALL produce a new CSN, never a silent rewrite of the existing one. - All **federation interactions SHALL exchange CSNs**. The Meta-Universe Federation Protocol (MUFP) transmits CSNs; it SHALL NOT rely on Display Names for identity. - User interfaces SHOULD present the localized Display Name while resolving it to the underlying CSN. - Display Names MAY differ across languages, contexts and presentations; the CSN SHALL remain the same. To prevent name collisions across a federation, a CSN SHOULD be paired with the [Semantic Fingerprint](Versioning.md) of the concept's defining version. Together, the CSN identifies *which concept* and the fingerprint identifies *which meaning*, so that two universes using the same CSN can detect whether they actually agree on its semantics before relying on it. --- # 6a. CSN Grammar and Identifier Scheme To make CSNs and identifiers machine-checkable, this section gives their formal grammar. A **Canonical Semantic Name** SHALL conform to the following ABNF (RFC 5234): ```abnf CSN = segment *("." segment) segment = lower *(ALPHA / DIGIT) lower = %x61-7A ; a-z (a segment SHALL start lowercase) ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 ``` The first `segment` is the **namespace**; the remaining segments name the concept within it (for example `employee.compensation.salaryAgreement` — namespace `employee`). This grammar is the normative source for the `csn` pattern in [`schemas/common.schema.json`](../schemas/common.schema.json) and is enforced by check `V2-03` in [Validation](Validation.md). 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 the lifetime of the thing it names. An implementation SHALL adopt one of the following identifier schemes, declared so that consumers can resolve it: | Scheme | Form | Example | |--------|------|---------| | `uuid` | a UUID | `9d3f2c1a-...` | | `uri` | an absolute URI | `https://acme.example/person/12345` | | `urn` | a URN | `urn:mu:person:9d3f2c1a` | | `qname` | `scheme:value` within a Universe | `employee:12345` | Identifiers SHALL be compared as exact byte strings; they SHALL NOT be case-folded or normalized. A [Canonical Identity](../04-core-concepts/Identity.md) pairs a scheme with a value (`{ "scheme": "urn", "value": "urn:mu:person:9d3f2c1a" }`). New schemes MAY be registered without breaking existing identifiers. --- # 7. Namespace Convention Every public concept SHALL belong to a namespace. Recommended format: namespace:Concept Examples: employee:Skill organization:Department product:Capability schema:Person fhir:Patient Namespaces SHALL be globally unique within their semantic scope. --- # 8. Meta-Model Naming Meta-Models SHOULD use descriptive names. Recommended examples: Employee Meta-Model Product Landscape Meta-Model Enterprise Landscape Meta-Model Avoid implementation-specific names. --- # 9. Bundle Naming Bundle names SHOULD be nouns representing semantic domains. Examples: Identity Knowledge Governance Runtime History Security --- # 10. Layer Naming Layers SHALL represent one coherent semantic concern. Layer names SHOULD: - use singular nouns; - avoid abbreviations; - avoid technology names. Examples: Employment History Projects Compensation Competencies --- # 11. Object Naming Object names SHOULD: - use singular nouns; - represent real or conceptual entities; - avoid implementation terminology. Preferred: Employee Project Skill Avoid: EmployeeTable ProjectDTO SkillRecord --- # 12. Property Naming Property names SHOULD: - describe facts; - use lowerCamelCase; - avoid prefixes; - avoid implementation suffixes. Preferred: firstName createdAt currentPosition Avoid: emp_name fld1 col_employee --- # 13. Relationship Naming Relationship names SHOULD describe semantic meaning. Examples: worksFor reportsTo owns dependsOn assignedTo Generic names such as "link" or "relation" SHOULD be avoided. --- # 14. Event Naming Events SHOULD describe completed facts. Recommended pattern: Examples: EmployeeCreated ContractSigned ProjectArchived Avoid imperative names. --- # 15. Contract Naming Contracts SHOULD describe the business or semantic purpose. Examples: Employment Contract Knowledge Disclosure Contract Federation Agreement Avoid implementation-oriented names. --- # 16. File Naming Specification documents SHOULD use: Title-Case-With-Hyphens.md Examples: Meta-Universe-Constitution.md Federation-Contracts.md Identity-Binding.md Example files SHOULD include the suffix: .example.yaml --- # 17. Reserved Terms The following terms are reserved by the Meta-Universe standards family: Universe Dimension Namespace Meta-Model Bundle Layer Object Projection Relationship Event Contract Context Identity These terms SHALL NOT be redefined with incompatible meanings. --- # 18. Imported Standards Imported concepts SHALL preserve their original names whenever practical. Local extensions SHOULD extend imported concepts instead of renaming them. Example: schema:Person ↓ employee:Employee --- # 19. Naming Stability Identifiers SHALL remain stable across compatible versions. Renaming SHOULD be treated as a semantic change. Migration guidance SHALL be provided whenever identifiers change. --- # 20. Future Directions The Canonical Semantic Name establishes a stable, technology-independent identity layer that future work may elaborate into a **Semantic Style Guide**: a companion standard defining the grammar of CSN segments, casing and pluralization rules, recommended hierarchy depth, and the resolution algorithm by which a localized Display Name maps to a CSN across languages. Such a guide would also specify a federation-wide CSN resolution service, so that any universe can dereference a CSN to its defining version and [Semantic Fingerprint](Versioning.md), closing the loop between naming and meaning. --- # Final Statement Consistent naming is a prerequisite for semantic interoperability. The purpose of these conventions is not stylistic consistency alone, but the creation of stable, globally understandable semantic models that can evolve, federate and be interpreted reliably by both humans and AI systems. ## https://ver.cy/spec/docs/02-architecture/Policy-Consistency.md # Policy Consistency **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-014 **Title:** Policy Consistency, Precedence and Deadlock Handling **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** MUC, [Validation](../02-architecture/Validation.md), [Change-Process](../01-constitution/Change-Process.md), [Contract](../04-core-concepts/Contract.md) **Informative References:** [Conflict-Resolution](../03-federation/Conflict-Resolution.md), [AI-Agent-Guide](../07-guides/AI-Agent-Guide.md), [Traceability](../02-architecture/Traceability.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose When a meta-model treats normative rules as binding law, two failures become possible that ordinary tools miss: 1. Two changes each pass a line-level merge yet leave the rule set **logically contradictory** (a `git merge` understands lines, not logic). 2. At decision time, **Rule A requires X while Rule B forbids X** — a policy deadlock that sends a strict agent into an endless loop or a refusal to act. This document defines how to keep a body of normative rules internally consistent: a **pre-merge Policy Consistency Check**, explicit **rule precedence**, and mandatory **deadlock handling with human escalation**. It is distinct from [Conflict-Resolution](../03-federation/Conflict-Resolution.md): that governs *divergent interpretations between sovereign universes*; this governs *logical contradiction within one model's normative rules*. --- # 2. Normative Rules as First-Class A **Normative Rule** is a binding statement (`SHALL` / `SHALL NOT`) with a stable identity. Each rule SHALL declare: - a stable rule identifier; - its **scope** (the objects/contexts it constrains); - its **precedence** (an explicit weight or rank — see Section 4); - its provenance and lifecycle. Rules are versioned and traceable like any other semantic artifact. --- # 3. Policy Consistency Check Before a change to the normative base enters the [Model Canon](../05-reference-architecture/Reference-Repository.md), a **Policy Consistency Check** SHALL be run. It evaluates whether the resulting rule set is **satisfiable** — whether any state can satisfy all rules at once. - A change that makes the rule set unsatisfiable SHALL be rejected as a **Constitutional (V3) failure** in [Validation](../02-architecture/Validation.md); the contradicting rules SHALL be reported by identifier. - The check SHALL operate at the level of rule semantics (predicates over the model), not text. An implementation MAY use a logic solver or a validating reasoning agent; the requirement is that the verdict be **reproducible and explainable**. - The check is a gate in the [Change Process](../01-constitution/Change-Process.md): no normative change merges until it passes. This is the concrete, near-term form of the "AI Reasoning Validation" arm of the future Semantic Validation Framework (see [Validation](../02-architecture/Validation.md)). --- # 4. Rule Precedence Where two rules *could* conflict in some states but a clear authority order exists, **precedence** resolves it deterministically: - Higher-precedence rules override lower ones; the resolution SHALL be recorded as a [traceable](../02-architecture/Traceability.md) decision, not applied silently. - Constitutional rules ([MUC](../01-constitution/Meta-Universe-Constitution.md)) SHALL have the highest precedence; no subordinate rule may override a constitutional article. - Precedence resolves *prioritizable* conflicts. It SHALL NOT be used to paper over a genuine logical contradiction that no ordering can satisfy — that is a Section 3 failure. --- # 5. Deadlock Detection and Exception Handling A **policy deadlock** is a runtime state in which applicable rules cannot all be satisfied and precedence does not resolve them (Rule A requires X, Rule B of equal standing forbids X). An implementation SHALL: 1. **Detect** the deadlock rather than loop — a reasoning agent SHALL bound its attempts and recognize mutual blockage. 2. **Record** the deadlock as an immutable [Event](../04-core-concepts/Event.md) (a `Conflict` event) naming the blocking rules. 3. **Escalate** immediately to a human (Human-in-the-Loop). The agent SHALL NOT silently pick a side, fabricate a resolution, or stall indefinitely. 4. **Halt** the affected action until the escalation is resolved; other, unaffected work MAY continue. The resolution (a precedence change, a rule amendment, or a one-off exception) SHALL itself pass the Policy Consistency Check before it takes effect. --- # 6. Validation Hooks - `V3` (Constitutional) is extended with a **Policy Consistency** check: the normative rule set SHALL be satisfiable. - A model that cannot demonstrate satisfiability of its declared rules SHALL NOT claim V3 conformance. See [Validation](../02-architecture/Validation.md) for the level definitions. --- # 7. Architectural Invariants - The normative rule set SHALL be satisfiable; contradictions SHALL be rejected before merge. - Constitutional rules SHALL have the highest precedence. - Precedence resolutions SHALL be recorded, never silent. - A policy deadlock SHALL trigger detection, an Event, and human escalation — never an infinite loop or a silent choice. --- # Future Directions - A standard **predicate vocabulary** for expressing rule semantics so solvers interoperate. - **Proof artifacts** attached to a passing consistency check, so a consumer can re-verify satisfiability without re-running the solver. - Integration with [Simulated Sandbox Projections](../02-architecture/Simulation-Sandbox.md) to test a rule change for deadlocks before proposing it. --- # Final Statement > Rules that contradict each other are worse than no rules: they freeze the very > agents meant to act on them. Policy Consistency keeps the law satisfiable — and > when it cannot, hands the hard case to a human instead of looping forever. ## https://ver.cy/spec/docs/02-architecture/Provenance-Graph.md # Provenance Graph **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-011 **Title:** The Queryable Provenance Graph **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** [Traceability](../02-architecture/Traceability.md), [Event](../04-core-concepts/Event.md), [MMAS-Core](../02-architecture/MMAS-Core.md), RFC 2119 **Informative References:** [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), [Contract](../04-core-concepts/Contract.md), [Projection](../04-core-concepts/Projection.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose [Traceability](../02-architecture/Traceability.md) introduces **Semantic Lineage** as the history of the origin of meaning and notes that it may be promoted to a first-class, queryable artifact. This document realizes that: it makes Semantic Lineage a **Provenance Graph** — a navigable, queryable structure in which every conclusion is connected to the evidence that grounds it, and the consequences of any change can be traced forward and backward. The Provenance Graph turns *"why is this fact true?"* and *"what breaks if this changes?"* from manual investigations into deterministic graph queries. --- # 2. Scope This specification applies to: - the node and edge types that compose the Provenance Graph; - its relationship to [Event](../04-core-concepts/Event.md) causality; - the standard query patterns a conforming implementation SHALL support; - the cross-Universe behavior of provenance under federation. It does not mandate a graph-storage technology; any implementation that answers the queries of Section 6 over the model of Sections 4–5 conforms. --- # 3. Principles - **Lineage is a graph, not a log.** A conclusion may derive from many facts, and a fact may influence many conclusions. - **Edges are explicit.** Provenance relationships SHALL be declared, not inferred after the fact. - **The graph is append-only.** It grows through immutable [Event](../04-core-concepts/Event.md)s; it is never silently rewritten. - **The graph is queryable.** Impact, dependency and justification SHALL be answerable by traversal. --- # 4. Node Types The Provenance Graph SHALL recognize the following node types: | Node | Meaning | |------|---------| | **Object** | A Semantic Point of Truth — *what exists*. | | **Event** | An immutable record of *what happened* (see [Event](../04-core-concepts/Event.md)). | | **Projection** | A context-specific view derived from one or more Objects. | | **Contract** | The rule under which knowledge was used or disclosed. | | **Source** | An external origin (an upstream system, document, observation or another Universe) that is not itself a Meta-Universe Object. | Every node SHALL carry a stable identity and the [minimum traceability metadata](../02-architecture/Traceability.md) appropriate to its kind. --- # 5. Edge Types The Provenance Graph SHALL recognize the following directed edge types: | Edge | From → To | Meaning | |------|-----------|---------| | `derivedFrom` | Object/Projection/Event → Object/Event/Source | The target is an input from which the source was produced. | | `influences` | Object/Event → Object/Projection | The source contributed to, but did not solely determine, the target. | | `assertedBy` | Object/Event/Projection → Source (actor) | The target was asserted by the named actor or authority. | | `governedBy` | Projection/Event/Object → Contract | The use or disclosure was governed by the referenced Contract. | `derivedFrom` and `influences` capture *semantic* dependency (origin of meaning); `assertedBy` captures *authorship* (provenance); `governedBy` captures *authority* (the rules in force). An edge SHALL be created as part of, or referenced by, an immutable Event, so that the graph itself remains traceable and unrewritable. --- # 6. Relationship to Event Causality The Provenance Graph and Event **causality** are two views of the same history: - **Causality** links Events across *time* — *this Event happened because that Event happened* (see [Event §9](../04-core-concepts/Event.md)). - **Provenance** links facts across *meaning* — *this conclusion is true because those facts are true*. A `derivedFrom` edge between two conclusions SHALL be consistent with the causality between the Events that produced them: if conclusion B derives from conclusion A, the Event that asserted B SHALL causally follow the Event that asserted A. Lineage explains the origin of meaning across entities; causality explains the origin of change across time. Together they make the graph both a *semantic* and a *temporal* explanation of any fact. --- # 7. Standard Query Patterns A conforming implementation SHALL be able to answer the following over the Provenance Graph: ## 7.1 Impact — "what breaks if X changes?" A **forward** traversal from node X along `derivedFrom` and `influences` edges (reversed) yields every Object, Projection and conclusion whose meaning depends on X, transitively. This identifies the downstream facts that become stale if X changes and SHALL be re-evaluated. ## 7.2 Dependency — "show all conclusions depending on Event Y." A traversal from Event Y following the Events and facts it `influences` / that are `derivedFrom` it yields the dependency cone of Y — every conclusion that rests, directly or transitively, on Y. ## 7.3 Justification — "why is this fact true?" A **backward** traversal from a fact along `derivedFrom`, `influences`, `assertedBy` and `governedBy` edges yields its justification: the inputs it was derived from, the actor that asserted it, and the Contract that governed its use — back to the originating Sources. This is the machine-readable answer to *"why is this true?"* --- # 8. Worked Example Consider an *Employee Competency Score* derived through several steps, each recorded as an Event and connected by provenance edges: ```text (Source: Sprint Retrospectives) ▲ derivedFrom (Object: Project Feedback) ──assertedBy──▶ (Source: Team Lead) ▲ derivedFrom (Object: Performance Review) ──governedBy──▶ (Contract: HR Disclosure) ▲ derivedFrom (Object: Employee Competency Score) │ influences ▼ (Projection: Promotion Recommendation) ``` - **Justification** — *why is the Promotion Recommendation what it is?* Backward traversal returns: it `derivedFrom` the Competency Score, which `derivedFrom` the Performance Review (`governedBy` the HR Disclosure Contract), which `derivedFrom` Project Feedback (`assertedBy` the Team Lead), grounded in Sprint Retrospectives. - **Impact** — *what breaks if a Sprint Retrospective is corrected?* Forward traversal returns: Project Feedback, the Performance Review, the Competency Score and the Promotion Recommendation — all flagged for re-evaluation. - **Dependency** — *which conclusions depend on the Event that recorded the Performance Review?* The Competency Score and the Promotion Recommendation. Each answer is produced by traversal, not by reading prose — which is what makes provenance *operational* rather than merely documented. --- # 9. Federation Behavior Across a federation, the Provenance Graph SHALL preserve traceability without surrendering sovereignty. A `derivedFrom` edge MAY point to a Source in another Universe; that edge SHALL be disclosed only through a [Projection](../04-core-concepts/Projection.md) governed by a [Contract](../04-core-concepts/Contract.md), as recorded by `governedBy`. A Universe therefore exposes *that* a conclusion depends on an external Source — and under which Contract — without necessarily exposing the Source's full internal lineage. --- # 10. Validation A Provenance Graph conforms to this specification when: - every edge is one of the defined types and is backed by an immutable Event; - `derivedFrom` consistency with Event causality holds (Section 6); - impact, dependency and justification queries (Section 7) return correct, transitive results; - cross-Universe edges are disclosed only under explicit Contracts. See [Validation](../02-architecture/Validation.md) for the applicable levels. --- # 11. Architectural Invariants - The Provenance Graph SHALL be append-only and backed by immutable Events. - Provenance edges SHALL be explicit, never inferred silently. - `derivedFrom` SHALL be consistent with Event causality. - Impact, dependency and justification SHALL be answerable by traversal. - Cross-Universe provenance SHALL NOT bypass Contracts and Projections. --- # Future Directions A future revision could define a standard **provenance query language** and an interchange format for graph fragments so that impact and justification queries can run across federated Universes; integrate the graph with the [Semantic Fingerprint](../02-architecture/MMAS-Interchange.md) so that a source change is *detected* automatically and its downstream cone *invalidated*; and attach confidence and Trust Vectors to edges so that justification can be weighed, not merely listed. These extensions would make automated invalidation of stale conclusions a first-class, federation-wide capability. --- # Final Statement > Provenance stops being a story we tell after the fact and becomes a structure we > can ask. The Provenance Graph lets any participant trace a conclusion back to > the evidence that grounds it and forward to everything that would break if that > evidence changed — across time, across meaning, and across federated Universes. ## https://ver.cy/spec/docs/02-architecture/Semantic-Migration.md # Semantic Migration **Meta-Universe Specification** **Document ID:** MU-V2-ARCH-010 **Title:** Semantic Migration Standard (SMS) **Document Class:** Normative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** [MMAS-Core](../02-architecture/MMAS-Core.md), [Versioning](../02-architecture/Versioning.md), [MMAS-Interchange](../02-architecture/MMAS-Interchange.md), [Event](../04-core-concepts/Event.md), [Traceability](../02-architecture/Traceability.md), RFC 2119 **Informative References:** [Migration from v1](../07-guides/Migration-from-v1.md), [Naming-Conventions](../02-architecture/Naming-Conventions.md) **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document defines the **Semantic Migration Standard (SMS)** — the normative rules under which a Meta-Model moves from one version, structure or vocabulary to another *without losing or silently changing meaning*. The [Migration from v1](../07-guides/Migration-from-v1.md) guide introduces migration as an evolutionary, three-level activity and names SMS as its future formalization. This document realizes the concept: it specifies migration levels, records every migration as a traceable [Event](../04-core-concepts/Event.md), defines a **Migration Manifest**, and fixes the invariant that *meaning SHALL NOT change without an explicit migration event*. --- # 2. Scope This specification applies to: - migration of Meta-Models, Bundles, Layers, Objects, Properties, Relationships, Events, Contracts and Projections across versions; - the renaming, splitting, merging and reclassification of concepts; - the structural reorganization of repositories and documents; - the federation re-binding of a migrated model. It does not define the storage technology used to persist migration records, nor the human review process (see [Migration from v1](../07-guides/Migration-from-v1.md)). The Semantic Fingerprint and canonicalization it relies upon are defined in [MMAS-Interchange](../02-architecture/MMAS-Interchange.md). --- # 3. The Three Migration Levels A migration SHALL be reasoned about at three distinct levels, which MAY progress independently and at different speeds: - **Structural Migration** — the *repository and document structure*: folder layout, file organization, document identifiers and headers. Structural change MAY be quiet: it does not, by itself, change meaning. - **Semantic Migration** — the *terminology, concepts, relationships and rules*: how a concept is renamed, split, merged, reclassified or re-defined. Semantic change SHALL NOT be quiet (see Section 5). - **Federation Migration** — *how the migrated model interacts with other Universes*: re-binding Trust, Identity, Semantic Mappings, Contracts and Projection Synchronization so the model can rejoin the wider ecosystem. A complete migration SHALL address all three levels. Structural migration moves the files; Semantic Migration preserves the meaning inside them; Federation Migration restores how the model relates to others. --- # 4. Migration as a Traceable, Reversible-Explainable Operation A Migration SHALL be recorded as one or more immutable [Event](../04-core-concepts/Event.md)s of category *Semantic Event* (and, where applicable, *Lifecycle Event*). Each migration Event SHALL declare: - its subject — the artifact being migrated; - the **from-version** and **to-version**; - a reference to the governing **Migration Manifest** (Section 6); - its [provenance](../02-architecture/Traceability.md) — who performed the migration and under what authority. A Migration SHALL be: - **traceable** — every change SHALL be followable from its source to its result through the migration Event and its Manifest; - **reversibly explainable** — the prior state, the rationale and the mapping SHALL be recorded so the change can be understood and, where the mapping is invertible, reversed. SMS does not require that every migration be *executable* in reverse; it requires that every migration be *explainable* in reverse. Corrections to a migration SHALL themselves be expressed as new migration Events that reference the Event being corrected. A migration Event SHALL NOT be edited or deleted once recorded. --- # 5. The No-Silent-Meaning-Change Rule Meaning SHALL NOT change without an explicit migration event. Specifically: - A change that alters the [Semantic Fingerprint](../02-architecture/MMAS-Interchange.md) of any concept SHALL be accompanied by a migration Event and a Migration Manifest entry that classifies it. - Renaming a concept SHALL produce a new [Canonical Semantic Name (CSN)](../02-architecture/Naming-Conventions.md); the old CSN SHALL NOT be silently rewritten, and the mapping old → new SHALL be recorded in the Manifest. - A change that affects only non-semantic content (Display Names, descriptions, documentation, file location) SHALL NOT change the fingerprint and MAY be performed as Structural Migration without a semantic migration Event. The asymmetry is deliberate: **structural change is allowed to be quiet, but semantic change is not.** --- # 6. The Migration Manifest Every Semantic Migration SHALL be governed by a machine-readable **Migration Manifest** that describes, declaratively, how meaning is carried from one version to the next. A Manifest SHALL contain: | Field | Meaning | |-------|---------| | `fromVersion` | The source version of the Meta-Model. | | `toVersion` | The target version of the Meta-Model. | | `fromFingerprint` | The [Semantic Fingerprint](../02-architecture/MMAS-Interchange.md) of the source model. | | `toFingerprint` | The Semantic Fingerprint of the target model. | | `conceptMappings` | The ordered set of changed concepts, each mapping a source CSN to its target CSN(s) and a change kind. | | `compatibility` | The overall compatibility classification (Section 7). | | `events` | References to the migration Event(s) that enact this Manifest. | | `provenance` | Author, authority and creation time of the Manifest. | Each entry in `conceptMappings` SHALL declare a **change kind**: `renamed`, `split`, `merged`, `reclassified`, `redefined`, `added`, `deprecated` or `removed`, together with the source and target CSNs it relates. A concept that is unchanged need not appear; absence from `conceptMappings` SHALL mean *meaning preserved unchanged*. A Migration Manifest SHALL itself be expressible as [MUIF](../02-architecture/MMAS-Interchange.md) so that it can be exchanged, fingerprinted and validated like any other artifact. --- # 7. Compatibility Classification Every Migration SHALL declare a compatibility classification, aligned with the Semantic Change Classification of [Versioning](../02-architecture/Versioning.md): - **Compatible** — no concept changes meaning; consumers of the source model can consume the target model without adaptation. The model fingerprint MAY change only through additive, non-breaking concepts. - **Conditionally Compatible** — meaning is preserved but representation changes (for example a rename with a recorded CSN mapping); consumers MAY continue using the source through the Manifest's mappings. - **Breaking** — at least one concept changes meaning, is removed, or is merged in a way that loses distinctions; consumers SHALL adapt, guided by the Manifest's `conceptMappings`. The classification SHALL be derivable from the `conceptMappings` and SHALL be consistent with the change in Semantic Fingerprints. --- # 8. Preservation of Canonical Identity Migration SHALL NOT break **Canonical Identity**. - The stable identity of an Object, Relationship, Event or Contract SHALL survive a migration unchanged, even when its CSN or Display Name changes. - Where a concept is split, each resulting concept SHALL declare its derivation from the original identity; where concepts are merged, the resulting concept SHALL reference each source identity it absorbs. - Historical [Event](../04-core-concepts/Event.md)s and prior versions SHALL remain available and SHALL NOT be rewritten by migration. Identity continuity is what allows [Semantic Lineage](../02-architecture/Traceability.md) to be traced across a version boundary. --- # 9. Worked Example: v1 Galaxy → v2 Namespace The canonical v1→v2 evolution renames the v1 organizing concept *Galaxy* to the v2 [Namespace](../02-architecture/Naming-Conventions.md). The meaning — *how concepts are organized and published* — is preserved; only the name and its governance status change. This is a **Conditionally Compatible** Semantic Migration. Outline of the Migration Manifest: ```text fromVersion : 1.4 toVersion : 2.0 fromFingerprint : sha256: toFingerprint : sha256: compatibility : Conditionally Compatible conceptMappings : - source: galaxy. target: namespace. kind: renamed - source: object. target: metaObject. kind: renamed - source: identity. target: canonicalIdentity. kind: renamed - source: projection. (unchanged — omitted) events : [ evt:migration/1.4→2.0/namespace ] provenance : { author: , authority: , at: