H-Logic developer checklist

Documentation status: guide — see Maturity and evidence.

Use this checklist before treating an H-Logic feature as production-ready documentation.

Modeling

• The structural types used by the expression are defined.
• Roles and attributes are intentionally separated.
• Context is an explicit role when it affects meaning.
• Interface attachment uses :: only when support identity must be preserved.
• Named terms use & only for environment value references.
• Reified relations are used when the fact needs identity or lifecycle.

Queries

• The query uses ask or ?, not ?x-style variables.
• The reasoning mode is chosen deliberately.
• Scope options are no broader than required.
• Wildcards are treated as unconstrained positions.
• The caller handles zero, one and many-result shapes.
• Inherited results use Runtime mappings rather than raw slot assumptions.

Rules and projections

• Every public role of a composite definition is constrained by its body.
• Semantic validity is visible in rules/constraints rather than hidden only in scripts.
• Confidence, provenance or context attached to a logical relation remains attached to that relation.

Validation

• The expression parses with the target H-Logic grammar.
• Semantic resolution succeeds in the target Runtime.
• A parser or evaluation test covers the feature where possible.
• Generated or AI-proposed H-Logic is parsed and validated before it can change conceptual memory.

A documentation example that has not passed this gate should not be labeled Status: reference.