Problem
In tools/semantic_extraction.py, when a NEW (discovered, is_new) entity's
detail extraction returns schema-invalid JSON that cannot be repaired,
_validate_entity_detail records a validation_failures entry and the detail
merge is skipped. As a result the NEW entity does not reach the entity
catalog — it stays only in discovery_proposals — causing a grounding loss for
that entity.
(For an existing entity this is acceptable: the base catalog record is kept
and only the enrichment is lost.)
Severity
LOW / latent. Measured incidence in the real 189-turn Aurexara run =
0 entity-detail validation failures (the #503/#504 instrumentation was live
during that run). So it does not currently affect the game, but the code path
is real and could trigger with a different model, prompt, or campaign.
Proposed fix
When a NEW entity's detail validation fails, promote a minimal schema-valid
stub built from the discovery data (name / type / brief) into the catalog
(marked detail-pending / enrichment-failed), so the entity is grounded and never
silently lost — while still recording the validation failure in
validation_failures.
Constraints:
- Must not cause re-extraction stalls (the deterministic extractor would
otherwise reproduce the same invalid detail forever).
- Must be A/B-validated for entity-count / noise impact per the
Source-Quality-First rule (Rule 10) before shipping.
Context
This was surfaced by an adversarial review of the advisor incremental-extraction
work. The companion --extract-only honest-exit-code change handles extraction
errors (LLM unavailable, extract_and_merge raising, any non-PC phase
failure incl. the temporal exception); this issue is the separate
best-effort-drop case (exit 0, recorded in validation_failures).
Problem
In
tools/semantic_extraction.py, when a NEW (discovered,is_new) entity'sdetail extraction returns schema-invalid JSON that cannot be repaired,
_validate_entity_detailrecords avalidation_failuresentry and the detailmerge is skipped. As a result the NEW entity does not reach the entity
catalog — it stays only in
discovery_proposals— causing a grounding loss forthat entity.
(For an existing entity this is acceptable: the base catalog record is kept
and only the enrichment is lost.)
Severity
LOW / latent. Measured incidence in the real 189-turn Aurexara run =
0 entity-detail validation failures (the #503/#504 instrumentation was live
during that run). So it does not currently affect the game, but the code path
is real and could trigger with a different model, prompt, or campaign.
Proposed fix
When a NEW entity's detail validation fails, promote a minimal schema-valid
stub built from the discovery data (name / type / brief) into the catalog
(marked detail-pending / enrichment-failed), so the entity is grounded and never
silently lost — while still recording the validation failure in
validation_failures.Constraints:
otherwise reproduce the same invalid detail forever).
Source-Quality-First rule (Rule 10) before shipping.
Context
This was surfaced by an adversarial review of the advisor incremental-extraction
work. The companion
--extract-onlyhonest-exit-code change handles extractionerrors (LLM unavailable,
extract_and_mergeraising, any non-PC phasefailure incl. the temporal exception); this issue is the separate
best-effort-drop case (exit 0, recorded in
validation_failures).