Jerry
46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# 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.
|