Concept Implementation

Focus: how should confirmed concept behavior become verifiable, composable modules? Run only on explicit $concept-implementation invocation. Deliver a plan or code as requested. Continue confirmed portions and route model gaps that affect implementation back to concept-design.

A concept module encapsulates state, invariants, actions, and queries. Modules do not reference one another. Ports declare interfaces and adapters implement them; domain code depends on neither protocols nor other concepts. The synchronization layer coordinates public actions and owns cross-concept policy; the composition root wires implementations, while interface adapters translate DTOs and protocols into composition entry points.

Synchronization may restrict behavior, never extend the contract: composition invokes allowed behavior; concept actions enforce preconditions, invariants, effects, and result cases. Queries cannot replace atomic checks. OPs test concept purposes, end-to-end scenarios application purpose; conformance alone does not establish fitness. Route evidenced purpose failures back to the model.

Constraints