Versioning the topic map
Change the map without losing the history.
A topical map version records the planned answers, their owners and their relationships at a point in time. A change log explains additions, omissions, merges and moves so that an editor can account for every affected task and destination.
Give a node an identity that survives a title change.
A stable node ID identifies a planned topic or task independently of its label, spreadsheet row and URL. A title can become clearer, a row can move and a destination can change without creating a new task. Keep these fields separate so a later comparison can distinguish a rename from an addition.
Record the node’s task, parent, proposed or accepted owner, source references, dependencies and state. The map can include a proposal that has no published page yet, but the state must say so. A row with a destination is not proof that the destination exists or has passed content review.
Define how IDs are assigned and retired. Do not reuse the ID of an omitted task for an unrelated subject. Retain a tombstone or historical record with the decision and any successor ID. That preserves the meaning of references from briefs, research notes and earlier review records.
Compare meaningful fields rather than row positions.
Keep an unchanged snapshot of the accepted version before editing. Compare stable IDs across the old and proposed versions, then inspect task wording, ownership, parent links, required answers, sources and dependencies. Row sorting and formatting changes should not appear as new content decisions.
Classify each change explicitly: add, rename, revise scope, reparent, merge, split, omit or change destination. One edit can involve more than one operation. Moving a task under another parent while changing its reader promise deserves both records; calling it a simple rename can hide a coverage change.
Separate a proposed diff from an applied map version. A reviewer needs to see what will change and why before those changes become the accepted planning baseline. Keep the accepted snapshot available even after a proposal is rejected or revised.
Record additions, omissions, merges and splits.
An addition needs a clear task, evidence rationale, owner decision and relationship to existing coverage. Check for a near duplicate before assigning a new page. An omission needs a reason such as outside scope, unsupported evidence or an answer already covered adequately elsewhere; it should not disappear silently from the comparison.
For a merge, record every source ID, the surviving or successor ID, the required answers being preserved and the proposed destination. Check incoming links and any public URLs separately. Merging planning rows does not apply redirects or update live links.
For a split, list the new tasks and explain how each differs. Map the old requirements into the new records so that no necessary answer is stranded. A split based only on different phrases may recreate competing pages rather than clarifying the work.
Hypothetical example: add an AI retrieval explanation.
Imagine an accepted map with node R10 for document retrieval basics and R11 for passage retrieval evaluation. A review proposes a new question: how should a reader interpret a citation returned with a generated answer? This example is an invented planning scenario and makes no claim about a particular product’s behavior.
First compare the question with R11. The new task concerns checking what a cited source supports, while R11 concerns the stated retrieval evaluation. If the new explanation requires enough distinct treatment, propose R12 with a scoped promise about checking a citation against its source. Keep the boundary clear: it will not promise how every external answer system selects or displays citations.
Record R10’s definitions and the availability of a readable source document as prerequisites. Add a worked example using invented answer wording and a clearly identified fictional source excerpt. A reviewer should check the difference between support for a claim and the mere presence of a citation. If suitable evidence cannot be supplied, hold R12 rather than writing broad assertions about all AI systems.
Make the snapshot comparison explicit. In fictional version v1 dated 1 September 2026, R10 and R11 exist, R13 is a vague proposal called “Future AI trends,” and R14 repeats the evaluation task already assigned to R11. In proposed v2 dated 8 September 2026, retain R10 and R11, add R12, omit R13 for lack of a bounded supported task, and merge R14 into R11. Keep R13 and R14 in the history; do not reuse their IDs. The editor is the decision owner, the specialist reviews the source boundary, and the next review is 8 October 2026 or earlier if the sources change. These dates and roles are invented teaching records.
| Change | Recorded decision | Dependent work |
|---|---|---|
| Add R12 | Proposed task: check a citation against its source; distinct from R11 evaluation | Brief, hypothetical example and evidence review |
| Link R10 to R12 | Definitions provide prerequisite context | Contextual link plan after R12 is published |
| Revise R11 relationship | Link to R12 only where citation interpretation is relevant | Review anchor and task boundary |
| Set review trigger | Recheck scope when the example or relevant official documentation changes | Named owner and next review date |
| Omit R13 | v1 vague proposal; v2 omitted, ID retained historically | Reason: no bounded supported task; reconsider only with evidence |
| Merge R14 into R11 | v1 duplicate evaluation proposal; v2 successor R11 | Carry any distinct required answers into R11; inspect public URLs separately |
| Record review | Proposed v2 on 8September 2026; next review 8October 2026 | Editor owns decision; specialist checks claims; dates fictional |
Attach a reason, evidence and an accountable review date.
For each change, identify the proposer, decision owner, date, reason, supporting evidence and affected IDs. A change date tells you when the record was edited; a review date tells you when someone assessed it or intends to assess it. Keep those meanings distinct.
Record what would trigger an earlier review: a service change, an obsolete source, a task merge, a broken destination or observed reader confusion. A future date does not make a current unsupported claim acceptable. A completed review also needs a result and the version examined, not just a green cell.
Use reason codes if they help sorting, but keep a short explanation that a new editor can understand. “Scope revised” is weaker than “remove product instructions because the source describes a different edition.” The record should preserve the decision, not only the fact that someone clicked a status.
Review the downstream effects before accepting a version.
List the briefs, drafts, public pages, menus, internal links, media descriptions and structured data plans affected by each change. The map is one planning layer; changing it does not automatically repair those assets. Assign each follow-up a named owner and state.
Check that every earlier node is accounted for as unchanged, revised, merged, split or omitted. Check that each new node has a parent and an owner decision. Look for broken dependencies and circular prerequisites. Recounting rows alone cannot establish that coverage was preserved.
If a change is reversed, create a new revision that explains the reversal. Do not erase the intervening history or overwrite a later human decision with an old snapshot. The latest accepted map and the historical record should tell the same story about what was changed and what remains open.
Use a plain change record when a tool is unnecessary.
A spreadsheet or document can hold the required fields: change ID, old and new version, operation, affected node IDs, previous and proposed task or destination, reason, evidence, owner, decision date, review result and follow-up. Keep the accepted snapshots separate from the working proposal.
Before sharing a version, check links, permissions and the meaning of each state. State which pages are proposed, drafted, published or still awaiting checks. A complete planning record is useful because it makes the work inspectable; it is not evidence that every mapped answer is already published or that an external search outcome has occurred.
Sources and related learning
The worked examples are fictional. They explain planning decisions and do not represent measured search or client outcomes.
Continue with semantic SEO learning and topical map planning. content prerequisites and build order.