Applied MASD

ORE Studio's logical entities are authored as literate org-mode model files under each component's modeling/ directory. Most reference-data entities are value types — immutable records identified by a code rather than an object identity (see the entity types in Logical Space).

ORE Studio does not expose a formal M3 meta-meta-model. Instead:

• The implicit meta-model is the entity model file schema (.org authored files under modeling/).
• MASD's meta-layer and meta-component concepts are physically instantiated as ORE Studio's four architectural layers and ores.* CMake targets.
• Skills and recipes encode the meta-rules an LLM applies when authoring a new model — the equivalent of a formal meta-language in classical MDE.

The four layers (foundation / infrastructure / domain / application) and the components within them are therefore physical-space instances of the meta-layer and meta-component concepts. This is documented from the architecture perspective in System Model.

This section explains the core MASD vocabulary as it applies in ORE Studio, working from first principles with a concrete example at each step.

ORE Studio's physical space is the concrete TS→Part→Facet→Archetype instantiation, indexed in ORE Studio Technical Spaces (with per-TS detail in C++ Technical Space, SQL Technical Space, and Other Technical Spaces). In the C++ TS the canonical parts are include/ and src/; the SQL TS has a single implicit part because its artefacts are not split by compile-time role.

ORE Studio has no compiled Physical Metamodel. The PMM's role is played by two artefacts:

• facet_catalogue.org (projects/ores.codegen/library/facet_catalogue.org) — the profile catalogue that names every facet and its activation conditions; read directly by generator.py.
• The Mustache template directory under projects/ores.codegen/library/templates/ — the archetype catalogue, where each .mustache file is one archetype, wrapped in a literate org document that tangles it and documents it.

ores.codegen is a Model-to-Text projector: it takes a model, applies Mustache archetypes parameterised by a profile, and produces physical artefacts. It runs in two routes that share the same machinery but take their input from different sources:

The authored route is the common case: domain entities, lookup tables, junctions, and components are maintained by hand in literate org-mode, because the model carries intent other readers need (descriptions, custom-method prose, generator expressions). The org-mode migration story tracks moving the entire authored set off legacy JSON.

The automated route applies when the model is merely derived. The canonical example is the PlantUML ER diagram: a parse stage reads the generated SQL DDL and produces an intermediate JSON model; a render stage feeds it to a Mustache archetype and emits ores_schema.puml. That intermediate model is regenerated every run, carries nothing a human edits, and lives under build/output/ so it stays out of the input tree. projects/ores.codegen/models/ holds authored input only.

ORE Studio does not maintain a formal VMM. Instead facet_catalogue.org serves as its profile catalogue, mapping every profile name (domain, repository, sql, =qt=…) to the templates it activates and the model types they apply to. Three activation scopes are supported:

• Product scope — composite alias profiles (all, all-cpp, non-temporal) group multiple facets into a named shortcut for invocation time.
• Component scope — the component manifest (manifest.py) controls discovery roots; an optional --address filter may be supplied at invocation time to restrict generation.

• Element scope — entity model files declare ores.* properties in their :PROPERTIES: drawer. This is the supported/target set model: the entity's ores.* binding is its supported set (what it can generate); the CLI --address is the target set (what to generate this run; default = full supported set). What generates = target ∩ supported. Target ∩ supported = ∅ for an entity → warning. --profile is removed from the CLI; the entity's binding IS the profile.

  Address syntax follows Dogen's :masd.cpp.enabled: convention, with specificity-ordered resolution (more-specific overrides less-specific):

:PROPERTIES:
:ID: ...
:ores.cpp.enabled: true
:ores.cpp.qt.enabled: false
:END:

The above → supported set = all C++ except Qt. Entities with no ores.* properties: supported set = model-types filter (backward-compatible). The TS→facet map lives in a * Technical spaces section of facet_catalogue.org. All resolution logic is isolated in codegen/physical_space.py with its own unit tests.

For the full treatment — model types, profile catalogue, activation semantics, and the MASD→ORE Studio mapping — see ORE Studio Variability Model.

Each facet is generated by one or more ores.codegen profiles and documented by a literate template org file.

ORE Studio applies MASD's reference-implementation backout strategy directly: rather than designing an abstract generator first, it extracts the generator from a proven hand-written entity.

1. Commission currency by hand — every layer written without generator involvement. currency is the reference implementation.
2. Identify the SRPPs — the entity evaluation checklist formalises what "fully commissioned" means at each layer; patterns identical across all checklist items are extraction candidates.
3. Encode each SRPP as a Mustache archetype parameterised by the entity model.
4. Register the archetypes in facet_catalogue.org.
5. Verify zero drift — run the generator against the currency model and diff against the hand-written files; a zero diff confirms faithful extraction.
6. Extend to new entities — commissioning a new entity reduces to authoring its model and running the generator.

Commissioning currency produced the canonical SRPP catalogue for reference-data entities: the C++ domain struct with rfl-based JSON I/O, the repository entity/mapper/CRUD trilogy, the NATS service and protocol types, the SQL DDL and trigger scripts, and the full Qt UI (10 C++ archetypes plus 2 .ui archetypes in the Assets TS).

ORE Studio's position on the MASD methodology's automation spectrum:

The immediate goal is Level 3 for the complete entity stack, using currency as the fitness function.

1. Focus Narrowly — the generator produces mechanical layers (C++ plumbing, SQL DDL, Qt boilerplate) but never domain logic inside a service class.
2. Integrate Pervasively — ores.codegen is invoked via compass, emits files that slot into CMake targets and the existing layout, and carries the standard licence header and editor modeline.
3. Evolve Gradually — each new profile is added when a second real entity needs it; commissioning surfaces SRPPs, which become archetypes, which become profiles.
4. Govern Openly — all templates, models, and profiles sit in the open repo under the same review as production code.
5. Standardise Judiciously — Mustache, JSON, and Python at the core; artefacts conform to project conventions.
6. Assist and Guide — the automation spectrum above; ORE Studio currently operates between Level 2 and Level 3.

• MASD — the methodology and conceptual model this document applies.
• Logical Space, Physical Space, Technical Space, Facet, Variability — the individual concept docs.

• ORE Studio Technical Spaces — the concrete TS→Part→Facet→Archetype model.
• ORE Studio Variability Model — facet_catalogue.org, model types, activation.
• System Model — the four-layer architecture as physical-space instances.
• Component architecture — API/core/service split across components.
• Entity lifecycle — layer ordering and conventions for a full-stack entity.

• ores.codegen — the generator; inputs, templates, profiles, recipes.
• ores.codegen architecture — directory layout and template system.
• ores.refdata entity evaluation checklist — the "fully commissioned" fitness function.
• Domain Type Creator — the skill that generates all facets of an entity.