# Anti-Patterns **Meta-Universe Specification** **Document ID:** MU-V2-REFARCH-007 **Title:** Common Design Mistakes **Document Class:** Informative **Version:** 2.0 (Draft) **Status:** Working Draft **Normative References:** Meta-Universe Constitution (MUC), MMAS, MUFP **Informative References:** Architecture, Interaction Patterns, Federation Patterns **Copyright:** © Orkestron.AI **License:** Apache-2.0 --- # 1. Purpose This document identifies common architectural and semantic anti-patterns encountered when designing Meta-Universe compliant repositories, Meta-Models and federated ecosystems. Its purpose is to help architects avoid design decisions that reduce interoperability, traceability, explainability or long-term evolution. --- # 2. Design Philosophy An anti-pattern is a commonly recurring solution that appears reasonable but produces undesirable long-term consequences. The anti-patterns described here are informative guidance derived from the principles of MUC, MMAS and MUFP. --- # 2a. Anti-Patterns as a Negative Specification A mature standard says not only what to do, but what *not* to do. This document is the **negative specification** of the Meta-Universe architecture: the boundary that defines the architecture by its complement. This is a familiar device in well-established disciplines. Object-oriented practice has *Code Smells* and *Anti-Patterns*. Microservice architecture warns against the *Distributed Monolith* and the *Shared Database*. Domain-Driven Design catalogues its own traps. In each case the negative catalogue is as load-bearing as the positive one, because it captures the mistakes that look reasonable until their long-term cost appears. Some Meta-Universe anti-patterns are especially worth highlighting because they feel *natural and correct to developers trained on classical systems* — and are therefore the ones most likely to be reintroduced by habit: - **Copy Instead of Projection** (Section 4). Classical systems replicate data freely; in the Meta-Universe, copying breaks provenance and causes semantic drift. Knowledge is shared by Projection, not by duplication. - **Treating Local Identity as global** (the Hidden Identity anti-pattern, Section 7). A primary key that is unique inside one database is *not* a canonical identity. Reusing a local identifier as if it were global breaks federation and identity resolution. - **Trust by Authentication** (Section 15). "The caller authenticated, therefore they may have the data" is a reflex from classical access control. In the Meta-Universe, authentication is necessary but never sufficient: Trust, Purpose, Context and Contracts are evaluated independently. - **One Big Universal Meta-Model** (Section 13). The instinct to design a single enterprise-wide schema produces an unmaintainable monolith. The Meta-Universe favours small, federated Domain Meta-Models instead. Recognizing these four as anti-patterns — rather than as sensible defaults — is one of the largest conceptual shifts for engineers arriving from classical architectures. --- # 3. Anti-Pattern: Multiple Sources of Truth Problem Several independent objects claim to be authoritative for the same semantic concept. Consequences - identity ambiguity; - synchronization conflicts; - inconsistent federation. Recommended Practice Maintain a single authoritative Meta-Object and distribute Projections. --- # 4. Anti-Pattern: Copy Instead of Projection Problem Knowledge is duplicated rather than projected. Consequences - semantic drift; - conflicting updates; - loss of provenance. Recommended Practice Exchange context-aware Projections governed by Semantic Contracts. --- # 5. Anti-Pattern: Implicit Semantics Problem Meaning exists only in documentation or developer knowledge. Consequences - poor interoperability; - AI cannot reason reliably; - inconsistent implementations. Recommended Practice Make semantics explicit through Meta-Models, Relationships and Context. --- # 6. Anti-Pattern: Technology-Driven Models Problem The semantic model mirrors database tables, APIs or implementation details. Consequences - vendor lock-in; - poor reuse; - unstable architecture. Recommended Practice Model semantic reality first, implementation second. --- # 7. Anti-Pattern: Hidden Identity Problem Canonical identity is absent or replaced by local identifiers. Consequences - broken federation; - impossible identity resolution; - duplicate entities. Recommended Practice Separate canonical Identity from local operational identifiers. --- # 8. Anti-Pattern: Missing Provenance Problem Objects cannot explain where they originated. Consequences - reduced trust; - impossible auditing; - unreliable AI reasoning. Recommended Practice Capture provenance as a first-class property. --- # 9. Anti-Pattern: Missing Context Problem Knowledge is exchanged without explicit Context. Consequences - semantic ambiguity; - incorrect interpretation; - invalid decisions. Recommended Practice Declare Context explicitly for every Projection and interaction. --- # 10. Anti-Pattern: Contract-Free Federation Problem Knowledge is exchanged without Semantic Contracts. Consequences - uncontrolled disclosure; - governance failures; - legal uncertainty. Recommended Practice Govern all federation through explicit Contracts. --- # 11. Anti-Pattern: Silent Conflict Resolution Problem Conflicts are automatically overwritten without historical evidence. Consequences - loss of explainability; - destroyed audit trail; - hidden semantic errors. Recommended Practice Record conflicts, resolve explicitly and preserve history. --- # 12. Anti-Pattern: Breaking History Problem Historical Events, versions or relationships are deleted. Consequences - loss of traceability; - impossible reconstruction; - governance failures. Recommended Practice Append new Events instead of rewriting history. --- # 13. Anti-Pattern: Big Universal Meta-Model Problem One enormous Meta-Model attempts to describe every domain. Consequences - excessive complexity; - poor maintainability; - weak modularity. Recommended Practice Build small reusable Domain Meta-Models connected through federation. --- # 14. Anti-Pattern: Hard-Coded Mappings Problem Semantic mappings are embedded in application code. Consequences - expensive evolution; - hidden semantics; - low reuse. Recommended Practice Treat Semantic Mappings as governed semantic artifacts. --- # 15. Anti-Pattern: Trust by Authentication Problem Authentication alone is treated as authorization and semantic trust. Consequences - excessive disclosure; - weak governance; - unjustified assumptions. Recommended Practice Evaluate Trust, Purpose, Context and Contracts independently. --- # 16. Architectural Checklist Before publishing a Meta-Model, verify: - Is there one authoritative source? - Is Identity canonical? - Is Context explicit? - Are Projections used instead of copies? - Are Contracts governing disclosure? - Is provenance preserved? - Are Events immutable? - Can history be reconstructed? - Is federation explainable? - Can AI reason without hidden assumptions? --- # Final Statement Meta-Universe anti-patterns capture recurring architectural mistakes that reduce semantic quality and interoperability. By recognizing and avoiding these patterns, architects can design Meta-Models and federated ecosystems that remain explainable, trustworthy and evolution-friendly while preserving the constitutional principles of the Meta-Universe.