Summary
reconciliation.enabled=True with use_workforce=True deletes grounded mentions.
The resolver worker uses keep_indices to deduplicate coreferent mentions. The runtime
honours that literally and drops those extractions from DocumentResult.extractions.
Coreference belongs in canonical_claims. keep_indices should not be doing it.
Reproduction
Text with repeat and short-form mentions:
Dr. Elena Marku presented the audit findings on Tuesday. Marku argued that the reserve
was understated. Later, Elena Marku met the board chair, Petar Nikolic. Nikolic
disagreed with Dr. Marku on the timeline.
Same request and model (deepseek/deepseek-chat, temperature=0.0), reconciliation off vs on:
reconciliation=off -> 4 extractions
[0] 'Elena Marku' 4-15
[1] 'Elena Marku' 111-122
[2] 'Petar Nikolic' 144-157
[3] 'Dr. Marku' 182-191
reconciliation=on -> 2 extractions
[0] 'Dr. Elena Marku' 0-15
[1] 'Petar Nikolic' 144-157
Two grounded spans are gone. Each surviving claim carries a single extraction_indices
entry, so nothing recovers them.
Impact
- Span grounding is what separates Sourcery from plain structured-output libraries.
This feature removes it without warning.
ReconciliationConfig.min_mentions_for_claim (contracts/models.py:262) is unusable.
_worker_claims counts only mentions that survived keep_indices
(blackgeorge_runtime.py:227). The resolver has already collapsed the duplicates, so
claims hold one mention each. min_mentions_for_claim=2 returns zero claims.
DocumentResult has two layers by design: extractions are mentions,
canonical_claims aggregate them. Pruning mentions collapses both into one.
Root cause
The resolver instruction never defines what keep_indices is for
(blackgeorge_runtime.py:651-652):
"Read blackboard key 'coreference_clusters' and produce canonical resolved entities
and claims. Return mode='resolver', keep_indices, and canonical_claims."
Handed a coreference cluster, "canonical resolved entities" reads as deduplicate, so the
model returns one index per entity. The runtime applies it at blackgeorge_runtime.py:730.
Fix
- Keep every aligned mention in
reconciled_extractions. Prune false positives only,
never duplicates.
- Rewrite the resolver instruction: keep every mention index, express coreference only
through canonical_claims[].mention_indices.
- If false-positive pruning stays, move it to its own field (
drop_indices) so the two
intents cannot be confused.
Environment
sourceryforge 0.3.0, blackgeorge 1.3.1, Python 3.12.14, model deepseek/deepseek-chat.
Summary
reconciliation.enabled=Truewithuse_workforce=Truedeletes grounded mentions.The resolver worker uses
keep_indicesto deduplicate coreferent mentions. The runtimehonours that literally and drops those extractions from
DocumentResult.extractions.Coreference belongs in
canonical_claims.keep_indicesshould not be doing it.Reproduction
Text with repeat and short-form mentions:
Same request and model (
deepseek/deepseek-chat,temperature=0.0), reconciliation off vs on:Two grounded spans are gone. Each surviving claim carries a single
extraction_indicesentry, so nothing recovers them.
Impact
This feature removes it without warning.
ReconciliationConfig.min_mentions_for_claim(contracts/models.py:262) is unusable._worker_claimscounts only mentions that survivedkeep_indices(blackgeorge_runtime.py:227). The resolver has already collapsed the duplicates, so
claims hold one mention each.
min_mentions_for_claim=2returns zero claims.DocumentResulthas two layers by design:extractionsare mentions,canonical_claimsaggregate them. Pruning mentions collapses both into one.Root cause
The resolver instruction never defines what
keep_indicesis for(blackgeorge_runtime.py:651-652):
Handed a coreference cluster, "canonical resolved entities" reads as deduplicate, so the
model returns one index per entity. The runtime applies it at blackgeorge_runtime.py:730.
Fix
reconciled_extractions. Prune false positives only,never duplicates.
through
canonical_claims[].mention_indices.drop_indices) so the twointents cannot be confused.
Environment
sourceryforge 0.3.0, blackgeorge 1.3.1, Python 3.12.14, model
deepseek/deepseek-chat.