ORE Studio Variability Model

MASD reserves variability for non-structural variability: configuration that does not change the object graph, only how a fixed graph is projected into physical artefacts. Structural differences — different entities, attributes, keys, types — are the job of the logical model, not the variability model. Keeping the two apart is the single most important discipline in this document; conflating them is what makes a variability model rot into a second, shadow copy of the entity model.

The VMM has two responsibilities, and this document is organised around them:

1. Physical-space activation — enabling and disabling regions of the physical space: which facets (and therefore which templates) are generated for a given model. ORE Studio realises this with facet_catalogue.org.
2. Projection configuration — tuning how an enabled projection renders a fixed entity: naming, extensions, and feature toggles. ORE Studio realises this with a catalogue of authored knobs on the model — the sql.*, qt.* and licence features below.

An earlier version of this document covered only responsibility (1) and concluded that ORE Studio "does not represent features." That was wrong: the features are responsibility (2) — the authored knobs — and they had simply not been catalogued. The bulk of this document is that catalogue.

ORE Studio does not maintain a formal VMM data structure for activation. Instead, projects/ores.codegen/library/facet_catalogue.org serves as the Profile Metamodel (PMM): a flat catalogue mapping every profile name to the Mustache templates it activates and the model types those templates apply to. generator.py reads it directly via _load_profiles_from_org().

The org source format for a leaf profile is:

** <profile-name> :facet:
:PROPERTIES:
:description: ...
:model_types: domain_entity schema
:END:

| Template | Output |
|----------+--------|
| <name>.mustache | projects/ores.{component}/include/... |

Composite aliases (all, all-cpp, non-temporal) use :includes: instead of a templates table and are stereotyped :facet_group: or :component_archetype:.

There is no feature graph and no inheritance chain in the activation layer. The simplicity is deliberate: ORE Studio's physical space is small enough that a flat catalogue is maintainable and legible for both humans and LLMs.

This is the part the previous document omitted. Once a facet is activated, its projection is tuned by features — authored knobs the model file sets and the generator reads through. They are grouped into feature bundles, one per facet (plus a cross-facet licence bundle). Each bundle is a cohesive "variability entity": a named set of features that configure one projection.

The features below are exactly those that pass the authored-knob test — every one is read (never computed) in src/generator.py, and none of them adds or removes a logical attribute. Where a knob has a structural consequence (e.g. tenant-scoping changes a column's nullability) it is flagged; those are candidates to migrate into the logical model proper.

Each model file is ORE Studio's equivalent of a MASD logical element — the entity that projects into physical artefacts via the generator. Two authoring routes exist:

• JSON route (legacy): *_table.json, *_domain_entity.json, etc. in projects/ores.codegen/models/<component>/. The model file is a data bag consumed directly by the Mustache renderer.
• Org-mode route (current, preferred): *.org files in projects/<component>/modeling/ declaring #+type: ores.codegen.* in their frontmatter. The generator discovers these via the component manifest. This route keeps the entity definition, its prose documentation, and its org-roam cross-references in a single file — aligned with the MASD literate approach.

The feature bundles of Part 2 are authored on the model file — in the sql / qt sections (JSON route) or the corresponding org headings (org-mode route). They travel with the element, which is why their natural scope is the element.

The key difference from full MASD variability remains: ORE Studio has no intermediate feature graph with inheritance and resolution. Activation selects templates directly (Part 1); features are flat knobs read at render time (Part 2). This keeps the system simple to maintain and to hand to an LLM, at the cost of the fine-grained, scoped per-feature resolution that a full VMM enables.

• Variability — the MASD variability concept: features, profiles, VMM.
• Facet — the MASD facet concept the profiles activate.
• Applied MASD — the applied overview, including the full ORE Studio facet catalogue.
• ORE Studio Technical Spaces — TS/Part/Facet/Archetype index.
• C++ Technical Space — C++ profile-to-facet mapping.
• SQL Technical Space — SQL profile-to-facet mapping.
• ores.codegen — the code generator implementing this model.