Release note · August 1, 2026

A hidden Word variable is only half the story

Last release, DocFence made Word’s hidden document-variable store review-visible. That answers whether a package retains automation state. It does not answer the next, equally practical question: is the document carrying a stored field that can turn one of those hidden values into visible text?

Word’s Variable object documentation describes document variables as persisted document or template state, normally invisible until an appropriate DOCVARIABLE field is inserted. The field is the bridge between a hidden key/value store and a document result. A meaningful CI or handoff review needs evidence of that bridge, too—but not a leaked field argument or variable name in its build log.

DocFence 0.16 adds that evidence as a separate, privacy-safe inventory.

Field presence is not field evaluation

A DOCVARIABLE field can be stored as a compact w:fldSimple instruction or as a complex begin/instruction/separate/end sequence. Complex field instructions may be split across runs, retained in tracked-deletion markup, or nested inside another field expression. A result visible in Word is also not a reliable source of truth: it can be stale, and a field can consult an attached template that is not inside the package.

DocFence therefore reads only complete stored field-code instructions. It never opens Word, updates a field, runs a macro, resolves an attached template, or uses a result to infer a variable value. It records complete simple and complex instructions across the body, headers, footers, notes, comments, and glossary; current and deleted field-code variants remain separate stored evidence.

The default formatting switch matters

A naïve parser would look for one bare word after DOCVARIABLE. Real files are less tidy. Microsoft’s field-formatting guidance says Word adds \* MERGEFORMAT by default when a field is inserted through its dialog. That switch controls presentation; it does not replace the leading variable argument.

DocFence conservatively recognizes a leading plain token or complete quoted argument even when it has trailing Word switch material. Nested or compound expressions remain nonliteral instead of being interpreted. This small distinction is what lets a normal Word-authored field be counted correctly without turning DocFence into a Word field evaluator.

What the report can say safely

Profile JSON, Markdown, comparison reports, and SARIF now expose only aggregate counts: references, stories containing references, conservative literal/nonliteral references, and literal references that exactly match a validated w:docVar in the same main or glossary package document scope.

That exact association is deliberately narrower than a claim about runtime behavior. A same-scope match does not prove Word will display a value. No match does not make a field broken: the value may live in an attached template. Field instructions, literal arguments, variable names, values, Settings-part paths, story paths, and fingerprints never enter the report.

Two policy choices for the field boundary

For a handoff that should contain no stored document-variable field references:

rules:
  require_no_word_document_variable_fields: true

This produces DFP045 for every complete stored DOCVARIABLE reference. For a governed template that intentionally includes the field codes:

rules:
  no_word_document_variable_field_changes: true

DFP046 protects the private field-reference inventory against a later mutation. These rules complement—not replace—the storage rules from 0.15: use require_no_word_document_variables or no_word_document_variable_changes when the stored w:docVars state itself is the boundary.

Release evidence

The 0.16 suite has 41 tests. It covers simple and complete complex encodings, quoted arguments, Word’s default formatting switch, nested and compound expressions, current/deleted revision variants, headers, Strict Word XML, main-versus-glossary scope, same-count changes, policy/SARIF output, and redaction.

For an independent smoke test, the released wheel profiled LibreOffice’s public tdf150542.docx regression fixture. It reports one stored DOCVARIABLE reference with one literal same-scope association alongside a three-variable Settings store, while preserving the names and values as private material. The artifact uses the common \* MERGEFORMAT pattern.

Hosted CI passed on Python 3.11 and 3.13, including distribution validation. The wheel and source archive were independently rebuilt from the release commit and matched byte-for-byte; fresh GitHub release downloads then passed the published SHA-256 manifest and package checks.

python -m pip install https://github.com/SybilGambleyyu/docfence/releases/download/v0.16.0/docfence-0.16.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, source archive, and SHA-256 manifest. Read the exact behavior and limits in the policy reference and threat model.