Release note · August 4, 2026

A compatibility branch is a review boundary—not a rendering claim

By SybilGambleyyu · DocFence 0.35.0 · DCAB 0.25.0

A Word package can retain an OOXML Markup Compatibility and Extensibility (MCE) alternative even when its ordinary visible text is unchanged. That stored choice is meaningful review evidence: a different requirement can change which alternative a consumer is eligible to process. It is not, by itself, evidence of what any particular client will select or render.

DocFence 0.35 records that narrow stored boundary without copying a branch into CI output. Document Change Assurance Benchmark (DCAB) 0.25 supplies a deterministic, target-free pair that changes only a Choice requirement. The two releases make the condition testable while holding the semantic limits in plain view.

Selection belongs to the consumer

Microsoft's Markup Compatibility introduction describes AlternateContent as alternatives chosen by a consumer according to its supported features and processing settings. The documented preprocessing model can select and remove branches before a package is saved. A static review tool should therefore preserve the fact that stored markup changed without claiming to resolve a feature prefix, select a branch, target a particular Office version, preprocess a document, save it, or predict a client result.

word/document.xml
  mc:AlternateContent
    mc:Choice Requires="private feature prefix"
      stable stored branch
    mc:Fallback
      stable stored fallback

The requirement value is a prefix, not a rendering instruction. Microsoft's WordprocessingML Drawing documentation makes the distinction explicit: a Choice requirement must evaluate to a prefix that resolves to the expected URI, rather than to the URI text itself. That is exactly why this release keeps prefix values out of public reports.

Review evidence without a branch side channel

DocFence scans stored non-relationship Word XML members using the standard MCE namespace. It reports only aggregate part, AlternateContent, Choice, Fallback, and compatibility-rule token counts. The recognized branch and attribute structure remains inside a private digest, so an equal-count rewrite remains visible as markup_compatibility_inventory_changed without printing branch text, prefix values, qualified names, XML paths, or fingerprints.

markup_compatibility:
  markup_compatibility_part_count: 1
  alternate_content_count: 1
  choice_count: 1
  fallback_count: 1
  choice_requires_prefix_count: 1

There are two readable policy choices for different handoff boundaries:

rules:
  require_no_markup_compatibility: true
  no_markup_compatibility_changes: true

The first is a candidate-state gate for a handoff that must retain no recognized MCE markup. The second protects an approved baseline that intentionally retains it. Their findings are DFP082 and DFP083. Neither rule validates MCE conformance or makes a branch-selection or rendering decision.

A deterministic, target-free benchmark pair

DCAB 0.25 adds its thirty-sixth pair: review.markup_compatibility_choice_requirement_changed. Baseline and candidate retain one AlternateContent, one Choice, one Fallback, the same package-member set, and the same stored Word text. Only the private Choice requirement changes, and word/document.xml is the sole changed package member.

[Content_Types].xml         byte-identical
word/_rels/document.xml.rels byte-identical
word/document.xml           sole changed member
stored w:t values           stable

The public truth names only markup_compatibility_choice_requirement_changed. It does not disclose feature-prefix values, branch bodies, qualified names, compatibility-rule values, paths, or fingerprints. The structural verifier regenerates both package copies from source and checks the member and text invariants; it never invokes Word or preprocesses either package.

Evidence from an independent package

The DocFence release also profiles the public Open XML SDK Strict Word chart 2D Column-O12-Word-Charts.docx. It finds nine MCE-bearing Word XML parts, three AlternateContent nodes, three Choice nodes, three Fallback nodes, three requirement prefixes, and eight Ignorable prefixes. This is a stored-package smoke test, not a compatibility verdict for any Office client.

Both hosted CI runs passed. Fresh wheel and source-distribution installs validate the bundled 36-case corpus, and independently installed DocFence 0.35 plus DCAB 0.25 strictly score all 36 cases. The public Hugging Face dataset mirror was atomically synchronized with the new target-free fixture, manifest, and release documentation.

Use the releases

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.35.0/docfence-0.35.0-py3-none-any.whl
python -m pip install https://github.com/SybilGambleyyu/document-change-benchmark/releases/download/v0.25.0/document_change_benchmark-0.25.0-py3-none-any.whl

docfence check approved.docx candidate.docx --policy docfence.yml --format sarif --output docfence.sarif
dcab validate
dcab docfence-observations --executable docfence --output observations.json
dcab score --observations observations.json --strict

The tagged policy reference, threat model, validation notes, and DCAB research notes define the full contract. A compatibility branch is stored evidence worth reviewing when policy says it is—not a client decision and not a rendering claim.