Release note · August 3, 2026

A stored Word field-update request is a review boundary

By SybilGambleyyu · DocFence 0.30.0

A Word document can store a request that its field results be recalculated when it is opened by an application that supports the setting. That request can change with visible document text and package topology otherwise unchanged. It deserves a precise package-review signal, but it does not make a static reviewer a field evaluator or a predictor of what a particular document client will do.

DocFence 0.30 adds a private-by-default inventory for direct w:updateFields settings. It lets a team gate a stored automatic-field-update request in CI without publishing a Settings path, raw XML, or private fingerprint.

The setting is stored state, not a field run

Microsoft documents UpdateFieldsOnOpen as the WordprocessingML setting for automatically recalculating fields from field codes when a supporting application opens a document. The setting is a direct child of Settings. That makes the stored request meaningful to review; it does not establish that any particular application will honor it, identify a field source, resolve a link, retrieve data, or change a field result.

word/settings.xml
  w:updateFields w:val="true"    stored enabled request

No relationship target is required for this direct setting.

DocFence accepts the strict CT_OnOff leaf form in Transitional and Strict Word namespaces: no child markup or nonblank text, at most one Word-namespace w:val attribute, and one of true, false, on, off, 1, or 0. An omitted value is treated as the enabled form. Malformed and duplicate direct leaves are rejected rather than guessed about.

The feature reads the stored setting only. It never opens Word, evaluates a field, recalculates a result, resolves a field instruction, follows a link, accesses a source, runs a macro, or makes a runtime-behavior claim.

Aggregate evidence without a settings leak

Public JSON, Markdown, and SARIF expose two counts: field_update_on_open_enabled_setting_count and field_update_on_open_disabled_setting_count. Settings-part paths, raw values, and semantic fingerprints remain private. Equivalent enabled spellings stay quiet at the inventory layer; an enabled-to-disabled change is still visible as a private semantic transition.

Two small policies make the boundary reviewable:

rules:
  require_no_field_updates_on_open: true

The candidate-state gate emits DFP073 only when an enabled setting is present. A team that intentionally retains a known setting can instead protect its approved baseline:

rules:
  no_field_update_on_open_changes: true

DFP074 flags a material inventory transition. Neither policy calls a field safe or unsafe; they make a stored configuration boundary visible and reviewable.

Evidence, not client execution

The 56-test release suite covers absent, implicit, enabled, disabled, and Strict forms; malformed leaf rejection; equivalent-spelling stability; privacy redaction; policy behavior; and JSON, Markdown, and SARIF output. Hosted CI passed for the release commit and tag, while fresh wheel and source-distribution installs completed the package smoke checks.

Document Change Assurance Benchmark 0.20.0 supplies a matching deterministic fixture that moves the stored setting from explicitly disabled to enabled. Its optional DocFence adapter consumes only public aggregate evidence.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.30.0/docfence-0.30.0-py3-none-any.whl

docfence profile candidate.docx --format markdown
docfence check approved.docx candidate.docx --policy docfence.yml --format sarif --output docfence.sarif

The public release includes the wheel and source archive. The tagged policy reference, threat model, and validation notes define the exact evidence contract and its limits.