Skip to content
EN FR

Manifest — Model-Class Manifest

Documentation status: reference — see Maturity and evidence.

Role of the manifest

A class manifest declares which model classes belong to a loading boundary and records their stable identities and public names.

Current file names are:

ClassItems.manifest.yaml
ClassItems.manifest.xml

Why make the manifest explicit?

An explicit manifest makes loading deterministic, allows identity and duplicate checks, and gives tooling a stable place to validate cross-folder references.

Typical information includes:

  • classId — stable conceptual identifier;
  • name — runtime/public class name;
  • type — supported class category;
  • optional loading or interpretation metadata required by the current Runtime contract.

Project-owned concepts should use a project-owned identifier prefix. Platform identifiers and application identifiers must not be mixed casually.

What the manifest does not do

The manifest does not replace the business model. Fields, relations, actions, views, and other domain declarations belong in *.model.yaml or *.model.xml files.

Lifecycle

Treat manifest identifiers as public identities. Validate uniqueness before release and change identifiers only as explicit migrations when data, relations, services, or integrations may already depend on them.