From validated semantics to declarative models
Documentation status: guide — see Maturity and evidence.
Validated H-Logic describes executable meaning, but it does not by itself decide persistence, publication, view design, package activation or lifecycle. The transition to a running application is therefore an operationalization step, not textual translation.
Mapping discipline
| Validated semantic construct | Candidate application artifact | Additional decision |
|---|---|---|
| Identified type | Entity concept | namespace, class identifier, facets |
| Pure polyadic relation | Relation concept | graph-only or reified/persistent |
| Attribute | Model field | type, nullability, storage, role path |
| Complete vocabulary | Enumeration-like concept set | extension and migration policy |
| Derived relation | Rule or generated relation | materialization and lifecycle |
| Indexed projection | Query relation or runtime index | storage, refresh and exposure |
| Diagnostic fact | Validation relation, event or view data | whether it blocks persistence |
Use a reviewed generation policy for concerns outside the ontology: namespace, target format, persistence, derived caches, generated views, service publication, diagnostic behavior, index generation and traceability.
Verification after generation
Generated artifacts should pass grammar validation, manifest/package resolution, class identifier and role-path checks, model compilation, runtime loading, semantic propagation tests and behavioral comparison with the deductions accepted during analysis.
Retain end-to-end traceability from requirement -> H-Logic construct -> generated artifact -> validation result. This makes regeneration, impact analysis and AI-assisted evolution reviewable.