Models, Workspaces and Release Artifacts📋

Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.

The framework needs to answer two questions about every visible result: what defines it, and which inputs produced it?

The proposed answer separates authored definitions, operational data and derived artifacts. This avoids treating a compiled DLL, a branch name and an editable document as interchangeable sources of authority.

Authority by material📋

The model designer edits the declarative model. C# generators consume it; handwritten C# provides behavior, defaults and constraints. Generated C# is not an independent second copy to edit and reconcile later.

Exporting operational content creates a named snapshot. A snapshot used for static generation is an input to the build; publishing newer content does not silently change an already built static artifact.

Three input routes📋

Git. Resolve a repository and reference into a base revision, prepare a workspace and record its changes. The build must identify the committed revision or a captured working-tree snapshot, rather than claim that uncommitted output came from a clean commit.

Filesystem. An editable workspace can exist without Git. The Lab records its storage identity and captures the source snapshot used for a candidate. Durability must come from a defined volume or storage provider, rather than an accidental container lifetime.

Artifacts. Import package identities, DLLs, dependency metadata and assets. This provides executable contributions where compatible, but not a source workspace unless source material is also supplied.

A mixed application can combine all three. Its release description must retain provenance for each input.

Configuration from code and UI📋

Code establishes defaults, locked constraints and an editable settings schema. Saved instance values override defaults only within those constraints. Permitted operation choices apply to the operation and do not silently become permanent configuration.

The UI must expose the effective value and its origin. The CLI and automation resolve configuration through the same service so that a deployment screen and an automated build cannot apply different hidden rules.

Secrets are resolved through the configured provider as references. They are not made part of public model exports or package descriptions.

Release identity📋

A release description records source/model identity, resolved packages, generator and renderer versions, SDK and provider versions, configuration identity, required migrations and any content snapshots used to build static output. It also identifies the resulting artifacts.

Compatibility-sensitive inputs are pinned. Build evidence identifies the actual toolchain; a label such as “latest preview” is insufficient to reconstruct a failing candidate.

For live development, the workspace can evolve while a previous release remains active elsewhere. Hot reload changes the preview process and does not rewrite the provenance of an existing production release.

Promotion preserves these boundaries📋

Definitions and code can move through a Git merge. Package selection follows the track's locked dependencies. Schema changes are planned against the target data scope. Optional editorial or business-data promotion follows module-specific merge policies.

The generation specification governs derived files. Content, Data and Promotion governs the material that does not become a source-code merge merely because both instances use Git.

Previous: Environments, Instances and Diem Domains · Next: Bounded Contexts, Shared Kernels and ACLs · Series index · Section index