Architecture: freeze the minimal normative semantic model and conformance contract #2

Migrated from FlossWare/loom-ai#1001 following Grok review.

The architectural direction is established. The remaining work is to make the protocol precise enough for independent implementations.

Required definitions

• Contract: exact identity, operations, compatibility, and required semantics
• Implementation: what it means to claim satisfaction of a Contract
• Capability and Requirement: matching rules, cardinality, versioning, and compatibility
• lifecycle states and transitions
• Plan definition versus Execution state
• Discovery as a normative protocol surface
• Provider/Builder acquisition semantics
• language-neutral Results and Evidence
• protocol-level failures

Representation

Keep the normative model independent of serialization. Evaluate OpenAPI, JSON Schema, Protobuf, messaging standards, and related mechanisms as realization layers rather than defining Loom with one markup language.

Conformance

Make machine-checkable conformance a first-class acceptance criterion covering contract satisfaction, discovery, builder acquisition, dependency resolution, plan execution, lifecycle, results, and evidence.

Architectural tests

• loom-ai and a future loom-java can implement the same semantics.
• HTTP/REST and JMS can expose the same contract semantics.
• A BPEL-oriented workflow engine can use Loom for service discovery/invocation while retaining BPEL semantics above Loom.
• A concrete platform can consume Loom and domain-specific Loom implementations without defining Loom itself.

Concrete platforms are examples of Loom consumers, not part of the Loom protocol or its architecture.