From change signal to review finding: an operating model for legal content updates

In short

Between “something changed” and “a new version is published” sit several stages, and they earn their keep because each one carries a decision of its own:

signal → relevance check → review finding → review → optional proposed change → draft → approval → publication

The important property of this chain is not its length but that it is allowed to end at every stage. Not every change should result in a text edit. A recorded decision to change nothing is a full result.

Why a chain rather than just “edit the text”

In many organisations legal texts have no process, only a habit: someone notices something, someone else changes something, and at some point a new version is online. That works for one website with four documents in one language — and collapses as soon as several brands, markets, languages and delivery channels are involved.

The chain addresses four concrete weaknesses of that habit:

• Triggers get lost, because they accumulate in inboxes and conversations rather than in one place.
• Assessments are not recorded, so the same question gets assessed repeatedly.
• Editing and approval blur — whoever made the change often also released it.
• Publication is treated as an afterthought, and that is exactly where the state arises in which something other than the approved version is live.

The stages in detail

1. Signal. An observed change: a legal change, a change on your own website, or a divergence between the delivered and the approved version. A signal is an observation, not a statement about consequences.
2. Relevance check. Does the signal concern your brands, markets and published documents? This stage is a pre-sort. It is allowed to be wrong as long as it stays traceable and correctable.
3. Review finding. A signal classified as possibly relevant becomes an item with evidence, a link to concrete documents, a status, ownership and history. Only here does an observation become something workable.
4. Review. People assess. The outcome is either “action needed” or “assessed, no action needed” — both with reasoning. This is the stage where the chain most often legitimately ends.
5. Proposed change (optional). A confirmed finding can produce a concrete proposal: which passage in which document could change, and how. A proposal is a working aid, not a decision.
6. Draft. The proposal is carried into an unpublished draft and edited there. Nothing changes for the public until approval.
7. Approval. A review step with clear ownership. Sensible rules include: no self-approval of your own change, four-eyes review from certain document types upward. Approval creates an immutable version.
8. Publication. The approved version is delivered precisely — to concrete websites, languages, markets and channels. Only then is the decision in effect.

Three points where automation should stop

Automation is useful along this chain — but not equally everywhere. Three transitions should deliberately stay with people:

• Finding → “actually relevant”. A pre-sort may propose; confirming is an assessment.
• Proposal → draft. A text proposal is an offer. Adopting it unchecked moves responsibility to a place that cannot carry it.
• Draft → publication. The moment an internal decision becomes public is the most expensive one to automate.

Everything before and between — observing, pre-sorting, evidencing, mapping, drafting proposals, translating, delivering after approval — benefits from automation, because it is reproducible work.

Roles — in small teams too

The chain does not presuppose a large organisation. It presupposes that three perspectives are distinguishable, even when they sit in the same person:

• Operations: keeps signals, evidence and delivery in order.
• Editorial: writes, maintains variants, keeps language versions together.
• Professional assessment: decides whether and what to change — internal or external.

The practical minimum standard: the person who wrote a change is not the person who approves it. How that translates into approval rules is covered in review workflows for legally relevant website content.

What should remain at the end

A chain is only as useful as what it leaves behind. After an item is closed, four things should be findable:

• the trigger with evidence and timestamp,
• the assessment with its reasoning — including when it says “no action needed”,
• the resulting version as an immutable snapshot,
• the point in time from which that version was delivered.

The last point is the one needed most often later — for instance when asking which version applied at a given moment. In detail: which terms version applied at contract conclusion? How immutable versions arise without copy chains is shown in legal text versioning without copy-paste chaos.

How TermShelf models the chain

In TermShelf the stages are not a convention but states with their own surfaces. Document Intelligence turns the three signals into review findings with evidence, status and history. A confirmed finding can lead to a proposed change; from that an unpublished draft is created in the regular editor.

Neither the proposal nor the draft affects the publicly delivered texts. Only approval creates an immutable version, and only publication delivers it precisely to websites, apps and transactional systems. Nothing is adopted or published automatically.

The approval and versioning side of the chain is described on the feature page legal text versioning, the delivery side on the Public Delivery API page.

Limits

TermShelf does not produce legally binding content and is not a substitute for legal advice. A process does not produce substantive correctness. It makes sure triggers are not lost, that assessments are attributable, and that a deliberate step sits between a draft and the public version. The professional assessment itself remains the task of qualified people.

Where the signals come from is covered in the hub keeping legal content current; narrowing down legal changes in a law changed — which documents need reviewing?