Release note · August 3, 2026
A Word field can change across three XML runs
Some Word fields are not one XML attribute. A complete complex field can put its instruction code in several w:instrText runs, with field markers distinguishing the instruction from the stored result. A review tool that scans each run independently can miss an instruction even though every run is present and structurally valid.
Document Change Assurance Benchmark (DCAB) 0.13.0 adds its twenty-fourth deterministic pair: external.complex_include_text_field_target_retargeted. Both packages retain the same members, the same stored w:t values, the same complete field shape, and the same stored result. Only a private external source fragment changes in word/document.xml.
Instruction text is a sequence, not a substring search
Microsoft's w:fldChar documentation describes the begin and end markers of a complex field and its optional separator. Its w:instrText documentation draws the crucial boundary: instruction text is field code only in the instruction portion of a complex field. Outside that portion, it is ordinary text.
The new pair fixes one compact field whose keyword crosses a run boundary:
begin marker
instrText: " INCLUDE"
instrText: "TEXT "…"
instrText: "…" "
separate marker
stored result: "DCAB include-text field result"
end markerEvery instruction run preserves whitespace explicitly. The field has exactly one begin marker, three instruction runs, one separator, one fixed result run, and one end marker. The keyword is never present in any individual instruction node; a scanner has to join the code runs in order and respect the marker context. That makes the case useful for validating a parser boundary, not just testing an attribute comparison.
A narrow static claim
This fixture is deliberately not a test of Word behavior. It does not resolve or import a source, open Word, update or evaluate a field, render a result, follow a target, or assert that any client processes the instruction. The synthetic package tests one stored structural fact: a complete complex external-field source changed while its result and ordinary Word text did not.
The generator and verifier reject incomplete or loose field-code markup. They require the exact marker sequence, preserved-whitespace fragments, stable result text, stable package-member set, one declared changed member, and a target-free public truth assertion. The standard python-docx reader opens all 46 .docx fixtures, while its lower-level OPC reader opens all 48 packages.
Aggregate evidence, without publishing the source
The optional DocFence 0.27.0 adapter reconstructs the complete complex instruction through its field parser and maps the change to aggregate external_field_inventory_changed evidence. Both sides retain one INCLUDETEXT field and one field-code record. The adapter does not place the source, instruction fragments, or document text into DCAB observations.
Hosted CI passed on Python 3.11, 3.12, and 3.13, including a separate clean DocFence adapter job. Rebuilt fixtures, fresh wheel and source-distribution installs, the published GitHub release downloads, and a fresh Hugging Face dataset snapshot each validate the bundled 24-case corpus.
Use the release
python -m pip install https://github.com/SybilGambleyyu/document-change-benchmark/releases/download/v0.13.0/document_change_benchmark-0.13.0-py3-none-any.whl
dcab validate
dcab docfence-observations --executable docfence --output observations.json
dcab score --observations observations.json --strictDCAB 0.13.0 retains fixture schema version 1 because its public truth and observation envelopes are unchanged. It adds a precise reconstruction case rather than broadening the benchmark into a renderer, field evaluator, or runtime security claim.
The MIT-licensed source, generated fixtures, structural verifier, release artifacts, and research notes are available on GitHub. The fixture corpus is also mirrored as a public Hugging Face dataset.