Scenario and domain model

Documentation status: tutorial — see Maturity and evidence.

Scenario

A customer submits a request that must be assessed before approval. The application needs to represent the customer, request, indicators, review process and final decision. External verification and AI explanation may be asynchronous, while simple validation and lookup can remain synchronous.

Core concepts

Use project-owned identifiers for the application domain, for example:

risk#customer
risk#request
risk#indicator
risk#review_process
risk#decision

The exact namespace is a project decision. The important rule is one stable conceptual identity per meaning.

Minimum roles

Customer carries identity and descriptive data. RiskRequest references one customer, has a creation time and a lifecycle status. RiskIndicator belongs to one request and records a typed observation. RiskDecision records the result and explanation. RiskReviewProcess coordinates work across those objects.

Facets

Model conceptual structure first in the hypergraph facet. Add persistence as a projection of that structure, preserving identity and relation meaning with explicit role paths. Do not derive the ontology from table layout.

Assembly

The module still follows the normal loading chain:

application configuration
  -> package
  -> class manifest
  -> models
  -> runtime metadata
  -> executable ClassItems/ObjectItems

Start with the memory runtime until all five concepts resolve by class identifier. Add persistence only after the model loads cleanly.