Chunking and the durability of constraints

[antejavor]

Part of #344

Question

Given that relations cannot cross a window boundary and constraints do not survive the merge, how do we chunk — and what do we do about the guarantees we lose?

Surfaced by #345, which established two facts that together undercut "valid by construction" at the document level:

1. Cross-window relations are never produced. joint_ie/long_text.py decodes each chunk independently and drops any relation whose endpoints did not both come from the same chunk. Its own comment: "Both IDs must originate in this same chunk result. This explicit lookup is what prevents accidental cross-window edge creation."
2. Constraints are not re-applied at the merge. long_text.py never touches schema.constraints; it set-unions rows. Verified empirically: the same span came back simultaneously as three different types, violating the EntityOverlapPolicy every compiled schema carries, and a max_per_head=1 relation ended up with 2 edges on one head after merging.

So enforcement is real (#345 confirmed it happens during beam expansion) but per window only. The document-level result can violate the constraints we declared.

This matters here specifically because extract_long() is not optional for us — #336/#338 made it mandatory precisely because session texts blow the context window. A reconciled session is one document; real session Chunk.text values run to several thousand characters, against a default chunk_size of 384 tokens. So most sessions will be many windows, and a relation between a person named early and an organisation named late is exactly the case that silently vanishes.

Open:

1. Chunking regime. Keep a session as one document and accept per-window relations? Chunk on conversational turn boundaries so related mentions co-occur more often? Larger windows with more overlap, trading compute? Something structural — e.g. extract per turn and relate across turns in a separate pass?
2. What "document-level valid" should even mean. Do we want the merged graph to satisfy the declared constraints, or is per-window validity enough? If we want the former, something has to re-check after the merge — and What JointSchema actually enforces #345 flagged that Constraint.apply has zero call sites in the package, so that path is untested library surface.
3. Interaction with entity identity. If the same entity appears in several windows it becomes several nodes, which is Entity identity across chunks #346's problem — but note it also causes relation loss here, since endpoints in different windows can never be joined. These two may share a solution.
4. Whether this changes the relation vocabulary. If cross-window relations are structurally unavailable, relation types that typically span a long conversation may be unextractable in practice regardless of how well they are specified (The starter relation vocabulary #347).

Interacts with #348 but deliberately not blocking it: #348 can be decided knowing the fact that enforcement is per-window, without first settling the chunking regime. Whoever picks up either should read the other.

[antejavor]

#348 added a second, independent reason to drive windows ourselves rather than calling extract_long_text.

#345 already gave the first: long_text.py drops any relation whose endpoints came from different chunks, and never re-checks constraints at the merge.

The new one: JointResult.feasible (result.py:75) is the only suppression signal gliner2 exposes — "False when the decoder could not satisfy the declared hard constraints and fell back to an empty assignment (distinct from 'nothing to extract')". But long_text.py:77 builds its merged result as JointResult(text, entities, relations, include_confidence, include_spans) — feasible is omitted, so it defaults to True. Per-window infeasibility is silently swallowed.

#348 chose to retry infeasible windows with permissive endpoints and write the result flagged, which is only possible if we see feasible per window. So this ticket now has a decided requirement to design around, not just an open option: whatever windowing we land on, per-window feasible must survive to the caller.

That likely also means owning the merge, which is where this ticket meets #346 — cross-window entity identity is the thing that makes a merge more than concatenation.

[antejavor]

Data from #350, which drove the windows itself rather than calling extract_long_text.

1. Owning the windowing works, and per-window feasible does survive. The prototype called split_text_into_chunks(text, 384, 64, word_splitter=word_splitter_from(engine)) and then engine.extract(window.text, schema, config=...) per window, remapping spans into document coordinates the way long_text.py does. No wrapper needed, nothing private touched. So the requirement this ticket picked up from Extraction-time constraints vs post-hoc validation #348 ("per-window feasible must survive to the caller") is cheap to satisfy — the cost is owning the merge, not reaching the signal.

2. Scale of the problem, measured. Real evidence sessions at chunk_size=384/overlap=64 came out at 6 to 17 windows each (median 11) over 10 sessions of 10.6K–25.7K chars. So the cross-window question is not an edge case: every session is many windows, and any relation between mentions more than one window apart is structurally unavailable.

3. The two constraint families behave differently at the merge, which narrows what "document-level valid" has to mean. Measured: 0/1004 merged constrained edges violate the declared domain/range, against 194/672 in the permissive arm. That is structural rather than lucky — typing is a per-edge predicate, so a set-union of per-window-valid edges stays type-valid; cardinality is a global predicate, so it breaks (What JointSchema actually enforces #345 demonstrated max_per_head=1 ending up with 2 edges on one head after merging, and What JointSchema actually enforces #345 saw the same for EntityOverlapPolicy). So open question 2 splits: for domain/range there is nothing to re-check after the merge; for cardinality and overlap policies there is, and Constraint.apply's zero call sites are only a problem for that second group.

4. feasible=False is unreachable without completeness constraints, so whatever windowing regime is chosen, the per-window infeasibility signal will read zero in practice: domain/range → 0/12 windows, + cardinality → 0/12 (but 68% of relations silently dropped), + symmetric/inverse → 6/12. Full table in Wire a constrained ontology and read the edges #350.

5. Identity is doing the damage this ticket suspected. User:'user' (degree 364) and User:'i' (132) are the same entity fragmented by surface form; Person:'frida' (103) and Person:'frida kahlo' (82) likewise. 2253 mentions collapse to 903 nodes under Entity identity across chunks #346's rule. Cross-window relation loss and identity fragmentation are visibly the same problem from two sides, as open question 3 guessed.

[antejavor]

A second kind of cross-window damage, from #362: a document-scoped extraction competes with itself window by window.

#362 established that GLiNER2's only value-extraction mechanism (structure().field()) produces one instance per document, not per entity and not per window. Driven per window — which is what this map settled on — every window therefore tries to fill every field, and nothing reconciles the answers:

• purchase_date came back as both March 14, 2025 and last Saturday
• pair_count as both 3 pairs and Three pairs
• personal_best flipped from 26:34 to 25:50 purely by changing window size 220 -> 400

Same text, same schema. Nothing in the output says which is right, and there is no feasible-style signal on the legacy path at all (the result is a plain dict), so unlike relations there is not even a per-window flag to carry forward.

Two consequences for this ticket:

1. It widens open question 2. "What document-level valid means" was framed around constraint satisfaction. For document-scoped extractions the question is not satisfaction but arbitration: N windows return N candidate values for one field, and the merge has to pick. That is a different kind of merge than the set-union long_text.py does for entities and relations.
2. It makes window size a correctness parameter, not a throughput one. A relation either falls inside a window or is lost — bad, but monotone. A document-scoped field can come back differently right at different sizes, which means the chunking regime chosen here would silently pick which value the graph ends up believing.

This only binds if #361 chooses a value mechanism that is document-scoped. Record mode (mode="natural", anchor=...) is per-anchor instead, and its anchors match joint entity ids by (start, end) — so the arbitration problem may be avoidable rather than solvable. #361 owns that choice; flagging it here because the chunking decision would otherwise be made without knowing it is also deciding this.

[antejavor]

Resolution

The ticket asked how to chunk, given that relations can't cross a window boundary and constraints don't survive the merge. Most of its sub-questions were settled while it waited. What was left was the windowing regime itself, and measuring it turned up something none of the tickets had anticipated: mixed-speaker windows let assistant content through #358's gate.

Evidence: section I of the prototype README (64eaaa3), plus windowing.py / .log and tables.py / .log. The sweep uses #361's value vocabulary over #350's 10 sessions with one schema held (#365). The 384/64 regime is asserted to reproduce value_types.py's values arm (1121 raw edges).

Already settled before this session

• Per-window feasible must survive (Extraction-time constraints vs post-hoc validation #348's requirement). That's met: we drive the windows ourselves (Wire a constrained ontology and read the edges #350), and feasible is unreachable under this spec shape anyway.
• What "document-level valid" means (item 2). Domain/range is a per-edge predicate, so a set-union of per-window-valid edges stays valid (Wire a constrained ontology and read the edges #350: 0/1004 violations after the merge). Only global predicates break at the merge (cardinality, EntityOverlapPolicy, What JointSchema actually enforces #345). Near-synonymous relation labels all fire on the same pair #360 rejected cardinality caps, and under decision 1 below windows overlap only inside a split long turn. So there's nothing to re-apply after the merge; Extraction-time constraints vs post-hoc validation #348's post-hoc Cypher remains the integrity backstop, and Constraint.apply's zero call sites stop mattering.
• Identity across windows (item 3). This was settled by Entity identity across chunks #346 (exact text within type, merged at write time) and Which User mentions are the user #358 (User:'user'/'i' resolve to one user_id).
• What gliner2 2.0.0 actually offers for entity attributes #362's cross-window value arbitration (third comment). It dissolved with Values, not links: do entity attributes belong in the model #361: values ride as entity types on the joint path, per window, with no document-scoped structure competing with itself.

The sweep

regime	windows	raw	distinct claims	cross-turn	user→assistant (ungrounded)
words 192/32	215	1258	465	32%	321 (61)
words 384/64 (today)	109	1121	342	45%	388 (96)
words 768/128	56	784	172	66%	349 (82)
turns packed ≤384	143	947	369	15%	106 (11)
one turn each	164	895	393	0%	0 (0)

Wall clock is roughly the same across regimes (113–189s).

Bigger windows are ruled out by the encoder. It has 512 positions (max_position_embeddings), and at 768 words mentions and distinct claims halve and the temporal answer disappears.

Today's windows mix speakers, and that defeats #358. 45% of edges join mentions in different turns, and 388 of those (35% of all edges) put a head from a user turn onto a tail from the assistant's reply. #358's gate collapses a User mention if it's first person in a user turn, and it checks only the head. So these pass, and are written onto (:User). Split by a grounding proxy (does the tail appear anywhere in the user's own words?):

• 96 never written by the user: essentially all false. The assistant's closet-organising list becomes purchased(user -> tops/bottoms/shoes/accessories); also paid(I -> Money:'TLC') and practices(user -> 'finishing drills').
• 292 also written by the user somewhere: about half true (attended -> tournament, visited -> gym), half junk (lives_in -> closet, owns -> sarcophagi).

Per-turn windows lose no answer:

answer	384-word windows	one turn each
Business Administration	studied(user →)	studied(user →)
25:50	personal_best(user →)	personal_best(user →), plus an i variant
MoMA	attended(user -> 'moma tour')	the same, plus visited(user -> 'museum of modern art'), #359's edge, which word windows never produced

The drop in answer-bearing counts is duplicates (me/i/assistant heads). Per-turn also re-finds 55% of the grounded user→assistant claims inside the user's own turn.

Decisions

1. One turn per window (item 1). Only a turn longer than 384 words is split, with a 64-word overlap within that turn. The session stays one Chunk (provenance and unstructured2graph: sessions are split into ~500-char documents, inflating extraction cost ~11x #327's batching are unchanged); only the extraction windows follow turns, using the turn spans Which User mentions are the user #358's mention resolver already brings into GLiNER2Backend. So there's no new channel. This closes Which User mentions are the user #358's gap structurally: a user-turn head and an assistant-turn tail can never share a window. Rejected:

   • packed turns: narrows the gap to 106 edges but doesn't close it;
   • word windows with a write-time gate on the tail's turn: it also discards the grounded-and-true half, and keeps today's lower yield;
   • the status quo.

2. Windows never grow past about 384 words, because of the encoder's 512-position limit.

3. Cross-turn relations are a known limit (item 4). A relation stated across turns (the user's "it" pointing at what the assistant named) can't be extracted: 45% of grounded cross-turn claims aren't re-found within a turn. The episodic summary and retrieval over Chunk.text carry the cross-turn narrative. No relation type is excluded from the vocabulary on this basis; the limit applies to how a fact is phrased, not to its type.

4. Tables are a known limit, and n-ary facts are raised on the map. Admon's miss wasn't a window boundary: the 8 am - 4 pm header (char 5923) and the Admon cells (6085 onwards) share a window. A markdown table spreads one fact across a column header, a row label and a cell.

   • Linearized generically (Sunday, 8 am - 4 pm (Day Shift): Admon.): nothing binds, because there's no predicate.
   • With a verb template (Admon is assigned to the 8 am - 4 pm (Day Shift) on Sunday.): 18 works_shift edges appear, but Admon binds to 12 am - 8 am, and the day is lost.

   The fact is three-way: (Admon, Sunday, 8 am – 4 pm). Chunk.text stays untouched, so the raw table remains retrievable. N-ary facts go to the map's "Not yet specified" as the first measured case for an event node or reification (noted on Values, not links: do entity attributes belong in the model #361).

Consequences

• GLiNER2Backend: windowing moves from split_text_into_chunks over the whole document to per-turn windows, and the caller supplies the turn spans through Which User mentions are the user #358's resolver channel. LightRAGBackend is untouched: it has its own chunker, and per Does LightRAG consume domain/range too #349 it's a non-interchangeable alternative.
• Which User mentions are the user #358: its gate stays head-based. Per-turn windowing is what makes a head-based gate sufficient.
• Values, not links: do entity attributes belong in the model #361: "reified assertions are subsumed" holds for statements about statements, but not for n-ary facts (comment there).
• Run the derivation contract once and read the vocabulary #366: the derivation prototype should observe with per-turn windows, since that's what production will run.