# LLM semantic review contract

Read the sanitized `work/review/semantic-batch.json`, not raw STEP geometry.
Maintain stable proposal identifiers when an existing candidate expresses the
same method.

Write `work/review/experience-draft.json` with this shape:

```json
{
  "schema_version": "1.0",
  "draft_kind": "llm_generalized_experience_proposals",
  "proposals": [
    {
      "id": "constraint.part_family.shared_axis",
      "kind": "constraint",
      "scope": ["part_family"],
      "evidence_query": {
        "required_features": ["rotational_body", "central_passage"],
        "required_relations": ["dominant_axis_alignment"]
      },
      "guidance": "Preserve a shared axis across the participating feature roles.",
      "semantic_rationale": "The relationship remains meaningful when individual dimensions change.",
      "check": "Confirm that participating features retain their intended common axis."
    }
  ]
}
```

Allowed kinds are `feature_motif`, `constraint`, `design_rule`,
`validation_rule`, and `failure_repair`.

Follow these rules:

- Require an evidence query composed only of semantic feature and relation
  tokens present in the sanitized batch.
- Use scopes to prevent unrelated part families from supporting a proposal.
- Explain why a proposal transfers across dimensions and variants.
- Avoid dimensions, coordinates, source identifiers, face references, and
  numeric literals in prose.
- Do not infer build order or causal failure mechanisms from final geometry.
- Prefer a small set of meaningful methods over every possible feature pair.
- Preserve earlier proposal IDs when evidence still supports the same meaning.
- Let the publisher calculate support and confidence; never claim them in the
  draft.