Contract Identity + Semantic Stability

redknightlois

Parent Epic: #9 ## Why Consumers need predictable meaning from benchmark artifacts. Without explicit contract identity and durable semantic representation, meaning can drift silently over time. ## What we want to achieve - Every exported artifact clearly identifies its contract/version. - Semantic fields are represented in a stable, unambiguous form. - Canonical semantic vocabulary is explicit and consumable. ## Definition of done - Artifact contract identity is present and machine-readable. - Semantic fields no longer depend on internal ordering for interpretation. - Canonical vocabulary is part of the deliverable. - Change impact is clear to existing consumers. ## Validation included in this issue - Contract snapshot test(s) proving required identity fields are present. - Serialization contract test(s) proving semantic representation is stable. - Fixture-based acceptance checks for representative artifact variants. ## Acceptance checks 1. Consumer can determine artifact contract/version from artifact content alone. 2. Consumer can interpret key semantics deterministically from artifact content alone. 3. Validation fails if contract identity is missing or semantic representation regresses.

redknightlois

Scope alignment from downstream integration: - Keep semantic fields string-first and interpretation-safe (no enum-order dependence). - Keep contract identity strict and machine-readable with required fields: artifactType, contractVersion, semanticVersion, vocabularyVersion. - Publish and maintain explicit contract vocabulary and JSON schema as source of truth for consumers. This keeps #10 focused on deterministic meaning and contract identity.