# Knowledge handover gap case, step by step | SourceX

Canonical: https://refer.sourcex.si/guides/knowledge-handover-gaps-exception-examples
Last updated: 2026-10-20

The records that explain a handover exception are the ones that show the documented process, the exception it left out, the question that exposed it, the answer from the person who knew, the corrected page and the deliverable accepted afterward. The worked case below, Illustrative and built for this page, follows one missed exception through eight steps at a fictional consultancy, names who decided each step and which record it left, and ends with the signals that tell a knowledge management advisor a client holds the same kind of trail.

This worked case is part of the [knowledge handover gaps guide](/guides/workflow-knowledge-handover-gaps), which covers what to inventory before a practice acquisition. Here the job is narrower: show one gap from first miss to accepted fix, so you know what a complete exception trail looks like when you hear one described.

## The setup: a filing calendar that only worked for December

Illustrative. A 230-person regulatory compliance consultancy is being acquired by a larger advisory group. One senior manager has run annual filings for eleven years and is leaving after a three-month transition agreed in the deal. The firm's knowledge base holds an "Annual filing preparation" page at version 14: twelve steps on a calendar that assumes every client closes its books in December.

Most clients do. A handful close in June or March, and for them the senior manager always shifted the calendar and added a senior review before filing. That rule was written down exactly once, in a 2021 ticket comment, and never moved to the page. Nobody hid it. It simply never seemed worth the edit, because the person who needed it already knew it.

## Eight steps from the miss to the accepted filing

Each row is one decision or event, the person who made it, and the record it left behind. Read the third column as the evidence trail.

| Step | What happened and who decided | Record left | System |
|---|---|---|---|
| 1 | The process owner treats version 14 as the complete procedure | Page version 14 with editor and date | Knowledge base |
| 2 | Both teams sign the handover checklist line "Filing process documented: yes" | Signed checklist entry | Shared checklist |
| 3 | Years earlier, the senior manager noted the non-December rule in a ticket | 2021 ticket comment | Project tracker |
| 4 | The incoming team lead schedules a June year-end client on the December calendar | Task dates on the client project | Project tracker |
| 5 | A junior consultant asks why the prior filing shows a different date | Unresolved question logged on the ticket | Project tracker |
| 6 | The departing manager answers in writing, as the transition agreement requires | Answer comment with the calendar rule | Project tracker |
| 7 | The new process owner adds an exceptions section to the page | Page version 15, dated | Knowledge base |
| 8 | The engagement partner reviews the corrected filing; the client accepts it before the deadline | Deliverable sign-off | Deliverable record |

Steps 1 and 2 are the intended process. Step 4 is the miss in action. Steps 5, 6 and 7 are the repair, and step 8 is the checked outcome.

## The decisions that made the trail worth keeping

Three decisions turn an ordinary correction into evidence of how the firm actually works.

**The junior consultant asked instead of guessing (step 5).** The question was logged on the ticket, not raised in a hallway. That one choice dated the moment the gap became visible and tied it to a specific client project.

**The answer was written by the person who held the knowledge (step 6).** Because the transition agreement asked the departing manager to answer in the tracker, the tacit rule exists in her own words, with a timestamp. Many handovers lose exactly this step to a phone call.

**The page was revised, not overwritten (step 7).** Version 15 sits on top of version 14. In Confluence Cloud, every page keeps a version history, two versions can be compared, and restoring an older version saves it as the newest without deleting the later ones. The difference between 14 and 15 is the gap, stated precisely.

Remove any of the three and the case collapses. Without step 5 there is no dated discovery; without step 6 the rule is someone's reconstruction; without step 7's history the page looks as if it was always right.

## Why this sequence is useful evidence

The sequence pairs a stated procedure with the exception it missed, the question that surfaced it, an authorized correction and an accepted result. That shape of problem, decision and checked outcome is the kind of record AI developers describe needing when they study how real work handles cases the instructions did not cover. A clean process page shows intent. The gap trail shows where intent and practice diverged, and how the firm closed the distance.

It is also fragile in specific ways an advisor can ask about:

- **Page history.** A deleted page waits in the space trash until someone purges it; purging removes every version and attachment, and deleting a single version is permanent. A pre-closing tidy-up can erase step 7's before-and-after.
- **Tracker history.** Jira has no built-in report of when a field value changed; that sits in each issue's History tab. A consolidation that carries only current values loses when step 5 was raised and when step 6 answered it.
- **The checklist.** A signed "yes" on a shared workbook (step 2) is often the first file deleted after integration, yet it is the record that shows the gap passed review.

For how these records join across systems, the [handover gaps system map](/guides/knowledge-handover-gaps-records-across-systems) traces each linking key. For exception records in other workflows, see [procurement approvals and exception workflows](/guides/how-to-assess-procurement-approvals-and-exception-workflows).

## Recognizing the same pattern at a client

You will rarely hear a client describe "a knowledge handover gap." Listen instead for these signals during ordinary work:

1. A recent departure, retirement or acquisition, with a transition period written into an agreement.
2. Process pages with long version histories, especially versions added soon after a staff change.
3. A tracker where questions from new staff are logged as comments rather than handled in chat.
4. A phrase like "only she knew how to do the odd ones" about any recurring client task.
5. A planned space cleanup, tracker consolidation or tenant migration with a date attached.

Then confirm, at metadata level only, what exists: roughly how many process pages have more than a few versions, how many years of tracker history survive, who administers each system, and whether any purge or migration date is set. Never ask for page text, ticket content or client names. If the firm is losing an owner rather than being acquired, [knowledge transfer from a retiring owner](/guides/knowledge-transfer-retiring-owner) covers the related situation, and [what institutional knowledge is](/questions/what-is-institutional-knowledge) gives a plain definition to share with the client.

Before you introduce anyone, check the basics. The firm needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. In an acquisition, authority over the records can change hands at closing; the [who can license decision tree](/questions/who-can-license-knowledge-handover-gaps-records) shows whom to bring in on each side. What stays unknown until SourceX reviews it: which records the firm may license, what client details must come out, SourceX's current data needs and any offer.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's handover produced a trail like this one and its page and tracker history still survive, [register as a partner](/register), check the firm against [who qualifies](/who-qualifies) and read the [program terms](/terms) before you raise it with the owner.

## Sources

- https://refer.sourcex.si/terms
- https://support.atlassian.com/confluence-cloud/docs/create-edit-and-publish-a-page/
- https://support.atlassian.com/confluence-cloud/docs/delete-restore-or-purge-a-page/
- https://support.atlassian.com/jira/kb/how-to-identify-and-list-when-a-field-value-was-changed-in-jira/