Stamp Changelog Claims as Extract, Draft, or Sign Before Publishing Notes

Description and use

In this workflow, every changelog entry is stamped with an authority (EXTRACT, DRAFT, SIGN) to ensure only humans assert promises, while models rephrase extracted data.

Problem

Generated release notes often mix extracted symbol lists, model‑drafted summaries, and human‑written compatibility claims, leading to unverified authority and potential miscommunication of breakage or migration steps.

Outcome

The workflow enforces provenance for every changelog entry, preventing models from inserting unverified compatibility claims and ensuring human ownership of promises.

Workflow

• 1. Run a script to extract public symbols from two git tags and output a JSON diff.
• 2. Store the diff as evidence (e.g., build/symbol_diff.json).
• 3. Create a stamped changelog map (docs/changelog/vX.Y.Z.yaml) listing rows with authority, evidence, and empty bodies for SIGN rows.
• 4. Allow a model to draft narrative summaries (DRAFT rows) based on extracted data.
• 5. Human reviewers fill SIGN rows with compatibility class, migration steps, rollback policy, and deprecation timeline.
• 6. Run a checker that blocks publishing if any SIGN row is non‑empty or contains model‑generated content.
• 7. Once all SIGN rows are approved, publish the tag and the final CHANGELOG.md derived from the stamped map.

Evidence

Generated release notes fail when a model is allowed to classify breakage or promise an upgrade path.

Source

A model that fills a SIGN row is not accelerating documentation but forging a signature the repository cannot prove.

Source