Hypergraph construction and H-Logic

Documentation status: guide. H-Logic syntax and public contracts remain governed by their versioned reference; this page describes choice of workflow.

Two first-class construction surfaces

The source guides describe two approaches to constructing a semantic Hypergraph. Public use of either depends on the operations exposed by the versioned ABI:

Starting point	Prefer	Why
Native algorithms already holding typed values, roles and exact relations	Published Hypergraph ABI	Construct nodes and relations directly, when the operations are present in the release manifest
A semantic program intended to remain inspectable or portable	H-Logic parser + controlled commit	Reuse language composition and validation rules

Neither surface is merely a fallback for the other. Both must preserve the same semantic identity, role structure and constraint meaning.

Decide how parsing commits

The source book distinguishes parse only, parser-managed commit and manual inspection/commit. Before invoking the parser, determine the target Hypergraph and context, what is validated, who authorizes a commit, and which intermediate values remain valid after a parser event. Do not retain event-local native values beyond their documented lifetime.

Constraints and polyadic composition

FunctionalP constraint compilation is a particular case where the implementation intentionally emits canonical H-Logic and calls the parser. This avoids implementing a competing constructor for AND/OR/XOR, literals, local roles and nested composites. For example, A and (B or C) must not be flattened into a three-term conjunction. Existing registered concept types remain structural authority; locally assigned role names do not redefine their arity.

Hypergraph construction and H-Logic

Two first-class construction surfaces

Decide how parsing commits

Constraints and polyadic composition

Further reading