Example from HELIX’s own docs. This generated page comes from docs/helix/. Use it to see the method in practice; start with the artifact-type catalog for reusable templates. Historical plans and reports may describe retired architecture.

Source identity (from 05-deploy/release-notes.md):

ddx:
  id: release-notes
  authoring:
    home: repo
  depends_on:
    - deployment-checklist
  review:
    self_hash: 99574883788300395089b39ca0b1918d4a23f359269390fa4717bc0fc0c41f51
    deps:
      deployment-checklist: 78c9688645de24f33182dca537e13d0fb180abb4773ab85b48468e495a92bad1
    reviewed_at: "2026-09-17T19:23:17Z"

Release Notes — HELIX v0.14.0

Release Scope

• Release identifier or version: v0.14.0
• Release date: 2026-09-22 (operator-driven; tagged at the merge commit)
• Rollout window or environment: HELIX plugin (Claude Code marketplace, Codex plugin, Databricks Genie bundle, Grok Build) and the public website at https://documentdrivendx.github.io/helix/
• Release owner: HELIX maintainer cutting the tag
• Source commit or build: the tag’s merge commit (tag v0.14.0); previous release notes covered v0.13.1 at cfcab345 (2026-09-17)

Audience and Channels

Highlights

• component-profile, a Discover artifact type for candidate research. Discover had no type for reading the public record on a candidate technology, product, or managed provider before anyone spikes it. competitive-analysis positions the product against rivals, current-state-inventory records what already exists, and tech-spike runs one experiment. A profile consolidates the published record on one candidate and says how well it fits this project. One instance per candidate, so six candidates are six profiles that an ADR compares, and each can be researched in parallel and revised on its own.
• The profile starts from the need, not the candidate. The record opens with Need and Required Capabilities drawn from the project’s own artifacts before any candidate documentation is read, then aligns capability by capability with a Settled-by line and a status word, scores the named alternatives on those same capabilities, and closes with a verdict drawn from disjoint definitions. Confidence caps at Medium while a design-defining capability is unknown. Every factual claim cites a numbered source or is marked as unpublished or as a third-party estimate; sources carry a class, an author or organisation, dates, and a Searched record, and documentation URLs are pinned to the version in scope. The catalog example profiles PostgreSQL against DepositMatch from 33 dated sources.
• present gains brief and one-pager kinds. Present mode could produce a deck. It now also produces a brief and a one-pager, rendered to HTML and PDF, with a candidate-briefing reference flow that uses label headings and a need-first introduction, and per-flow files under deliverables/flows/.
• A human-facing voice profile, and a gate that reads the flow. The voice profile names mannered prose, negative parallelism, slogan closers, shadowboxing, narration, copula avoidance, borrowed authority, and terms of art stretched into metaphor, with a sample paragraph to match. check-deliverable.py reads the Story’s flow to choose between claim and label title rules, checks that visual cells carry numbers, and blocks bare-noun reversals, em dashes, copula avoidance, borrowed authority, bold-label bullets, counts and Title Case in headings, document narration, and any owner, date, or grade that no Sources row or Assumptions entry states. The renderers add no text the author did not write.
• External standards are defined where they are first named. A project artifact named “SALI LMSS” across a dozen documents without saying what it was, and 24 of its 86 attributed labels turned out to be absent from the standard. The artifact-signal voice profile now requires that every external standard, vendor term, or acronym be defined on first use and linked to its resource summary, and a vocabulary attributed to a standard is generated by tooling from the standard’s published file rather than transcribed from memory.
• Release tags are created by CI. v0.13.2 was tagged through the GitHub Releases UI against a commit whose three plugin manifests still declared 0.13.1. On merge of a chore(release): vX.Y.Z pull request, CI now reads the version from the title, cross-checks it against all three manifests at the merge commit, and pushes the tag itself, so a tag can no longer precede a manifest bump. release-version-guard.yml stays as a backstop for tags pushed by hand.

Required Actions Summary

• Users: none.
• Operators: none. The tag for this release is created by CI when the release pull request merges; do not create it through the Releases UI.
• Support: none.

Changes and Fixes

New or Improved

Fixes

Breaking Changes and Required Actions

• None. Existing artifacts, modes, and installs are unaffected; this release adds a type, two output kinds, and gate coverage.

Migration or Rollback Guidance

• Migration: pull the tag. Nothing to regenerate for plugin consumers.
• Rollback: install the v0.13.1 tag, the last tag whose manifests match their version. The website rebuilds from main and is not pinned to a tag.

Known Issues and Support

Support: open an issue at https://github.com/DocumentDrivenDX/helix.

References

• Deployment checklist: deployment-checklist.md
• Auto-tag workflow: .github/workflows/release-tag.yml
• Tag guard: .github/workflows/release-version-guard.yml
• Commit range: git log v0.13.1..v0.14.0