MDE Monday #8: For the Boston/Richmond crowd — why your four-layer tower might want a glass atrium on top

0 Who this is for

If you work on Boston or one of its sister tools — anything that stores conceptual models in a MOF-style 4-layer stack (M3-M0) — this note is aimed straight at you. We’ll keep every concept framed in Boston vocabulary, then show how an extra “mirror layer” (M4) can remove most of the scaffolding you fight with today.

1 Boston in one slide-worth of words

• Boston’s Richmond Architecture encodes the MOF pyramid:
• M3 ORM meta-metamodel (FactType, Role, Uniqueness…).
• M2 Metamodels: ER, Property-Graph Schema, BPMN, …
• M1 Concrete models: the diagrams your analysts draw.
• M0 Instances in production tables or message streams.

Everything Boston does — diagram morphing, XMI export, model validation — walks that hierarchy, top-down or bottom-up.

You already know the pain points: every time an M2 evolves or a stray .xmi file resurfaces, you need more adapters, more migration scripts, more test fixtures. That’s the scaffolding tax.

2 M4 — the “mirror layer” that flips the build order

Recent work around the Conceptual-Model Completeness Conjecture (CMCC) introduces a reflexive store — call it M4 — that lives above the Boston roof:

M4  ← live, self-describing graph  (the “glass atrium”)
  M3  ← generated ORM meta-metamodel
  M2  ← generated ER / PG-Schema / …
  M1  ← generated models
  M0  ← runtime facts

M4 is not another spec; it is the running graph itself, expressed with just five declarative shelves:

S  – Schema rows
D  – Data rows
L  – Look-ups (enumerations)
A  – Aggregations (materialised metrics)
F  – Formulas (constraints & derivations)

All other layers become projections you regenerate on demand.

3 Walk-through: “Customers place Orders” inside M4

Below is the exact micro-payload the earlier article hinted at. Copy-paste it into a JSON store or a relational table set — nothing else is required.

<details><summary>Click to view the raw rows</summary>

// ---------- S  (Schema rows)
[
  { "kind": "Entity",      "name": "Customer" },
  { "kind": "Entity",      "name": "Order" },
  { "kind": "Attribute",   "of": "Customer", "name": "CustomerID", "type": "Integer", "pk": true },
  { "kind": "Attribute",   "of": "Customer", "name": "Name",       "type": "String"  },
  { "kind": "Attribute",   "of": "Order",    "name": "OrderID",    "type": "Integer", "pk": true },
  { "kind": "Attribute",   "of": "Order",    "name": "CustomerID", "type": "Integer" },
  { "kind": "Attribute",   "of": "Order",    "name": "OrderDate",  "type": "Date" },
  { "kind": "Relationship","name": "CustomerHasOrders",
    "from": "Customer", "to": "Order", "cardinality": "1:N",
    "fk": "Order.CustomerID -> Customer.CustomerID" }
]

// ---------- D  (Data rows)
{
  "Customer": [
    { "CustomerID": 1, "Name": "Alice" },
    { "CustomerID": 2, "Name": "Bob"   }
  ],
  "Order": [
    { "OrderID": 100, "CustomerID": 1, "OrderDate": "2025-05-01" },
    { "OrderID": 101, "CustomerID": 1, "OrderDate": "2025-05-03" },
    { "OrderID": 102, "CustomerID": 2, "OrderDate": "2025-05-04" }
  ]
}

// ---------- L
[]

// ---------- A  (Aggregation)
[
  { "name": "CustomerOrderCount",
    "definition": "SELECT CustomerID, COUNT(*) AS n FROM Order GROUP BY CustomerID" }
]

// ---------- F  (Formulas / constraints)
[
  { "name": "PK_Customer",       "rule": "UNIQUE(Customer.CustomerID)" },
  { "name": "PK_Order",          "rule": "UNIQUE(Order.OrderID)" },
  { "name": "FK_Order_Customer", "rule": "Order.CustomerID IN Customer.CustomerID" }
]

</details>

A four-line script can now:

• emit M3 rows for FactType, Role, etc.
• carve the metamodel of ER into M2.
• rebuild the familiar M1 ER diagram.
• dump Customer/Order tuples into M0.

Run that script twice on the same lattice and you get identical .xmi bundles — deterministic, no hidden state.

4 Why the flip pays for itself

1. One migration story Upgrades become normal DDL against S/D/L/F; regenerate projections, done.
2. Zero drift Every client can DESCRIBE S or DESCRIBE F to learn the rules it must satisfy.
3. Tool freedom UML, GraphQL, DDL, documentation — all are just alternate projections.

5 What a Boston shop can do today

• Pilot an M4 sidecar Point a nightly job at your existing M3-M0 store, materialise the lattice, and diff the output. You’ll see exactly how much metadata is duplicated or out of sync.
• Wire Boston’s UI to M4 Keep the diagramming front end unchanged; load/save through an M4 API that regenerates M3-M0 on the fly.
• Open-source the projection script Let the community beat on it; every edge-case they surface is one less manual migration later.

(If you want starter code, ping me — I have the 40-line Python demo ready to share.)

6 Take-away

The MOF tower still works, but the scaffolding around it is consuming more and more of our sprint capacity. By formalising an M4 mirror layer — a self-describing, live graph — you move the complexity into a single place and let projections do the repetitive work.

Think of it as giving Boston a glass atrium: the old floors stay exactly where they are, yet maintenance crews finally get a clear, central vantage point — and fewer ladders to climb.

References & Further Reading

• M4: The Missing Layer in Model-Driven Engineering
• Escaping “The MDE Hump”
• Syntax Is the Devil: CMCC, Flatland, and the Semantic Liberation of Models
• When MDE Meets the Power of a Strongly-Typed “Spreadsheet”
• From Tables to Topos: How Codd, Lambda-Calculus, and Turing Add Up to Model-Completeness

Join the ssotme://Protocol

The rulebook is not the code. It’s the source of truth. Versioned. Declarative. Collaborative. Like Git — but for business logic.

• Install the CLI: npm install ssotme/cli
• Website: EffortlessAPI.com
• Contact: start@anabstractlevel.com

CMCC #ModelDrivenEngineering #DeclarativeArchitecture #LiveModels #SemanticReflexivity #M4Layer #FourLayerModel #StructureOverSyntax #GlassAtriumThinking