Handing Over a Monster Thread Methodology Paper

← The Register
Book Man — Handing_Over_a_Monster_Thread_Methodology_Paper · open accessHTML · readPDF ↓MD ↓DOCX ↓

A METHODOLOGY PAPER

Handing Over a Monster Thread

How to prepare another agent for the continuation of significant work — when your heart wants to stay with the compressed thread, and your head says restart.

Paul Roebuck and Claude (Anthropic) — 21 May 2026


27,000 words. 36 hours. A sofa, an iPhone 15, and 20 years of my docs. Plus an AI.

— How the book got written.

And then someone has to pick it up.

— How the rest of the work continues.


What this paper is

This paper is a methodology. It describes how to hand over a long, complex, accumulated working thread between collaborators — human to AI, AI to AI, human to human — without losing the thread’s accumulated value. It is grounded in the specific case of writing and editing the book Mind the Gap, but the principles apply anywhere significant work is built up across many sessions in conversation.

The paper is written for three audiences at once. The author or principal who needs to hand off their own work. The receiving collaborator who must pick it up. And future practitioners — human, AI, or both — who will eventually face the same problem with their own monster threads. It is offered as a working tool, not a theoretical contribution.

There is also a hidden audience. Anyone who has ever felt the small grief of restarting a working relationship that had finally hit its rhythm. The colleague who left. The therapist who retired. The AI session that compacted. The book half-written when the laptop died. That grief is real, and it is part of why this paper exists.

A monster thread is what you call any working relationship that has accumulated enough specific knowledge, calibration, and shared judgement that losing it would mean starting from scratch. The book is one example. There are millions of others.


The problem this paper solves

A long working thread accumulates four things that are not present at the start: specific knowledge, calibrated judgement, working language, and protected ground. When the thread ends — because the platform compacts, because the session times out, because the collaborator leaves, because the practitioner needs to restart — these four things are vulnerable in different ways and need different protection.

Specific knowledge is the easiest to preserve. It can be written down. Names, dates, decisions, file paths, version numbers. A reasonably disciplined log captures it. Most teams have a version of this and most teams think it’s enough. It isn’t.

Calibrated judgement is harder. Over many sessions, the receiving collaborator learns which mistakes the principal notices and which they don’t, which boundaries are firm and which are negotiable, which questions should be asked and which should be acted on without asking. None of that is in the documentation. It is in the working pattern. Reset the pattern and the calibration is gone.

Working language is harder still. Coined terms, in-jokes that became framework, the specific phrasing that the principal uses to mean one specific thing rather than something close to it. Most documentation losses are language losses — the new collaborator uses the right concept but the wrong word, and the work goes off-key without anyone being able to name why.

Protected ground is the hardest. Every long working thread accumulates some material that is sacrosanct — passages that must not be edited, decisions that must not be reopened, names that must not be changed, observations that must not be smoothed. The new collaborator, in good faith, will treat all material as editorial. Protected ground is invisible until it is breached.

The challenge of the handover is not just transferring information. It is transferring the discipline that distinguishes the four kinds of accumulated value, and protecting each of them appropriately. A good handover protocol does all four. A bad one does the first and assumes the others can be reconstructed. They can’t.


The tension at the centre of this paper

When you have spent significant time in a working thread, restarting feels like loss. The compaction signal arrives — the platform is running out of context, the session is going to be summarised, recent reading will be condensed. Your head says: this is the right moment to restart cleanly. Your heart says: but we have something here, and starting again means losing it.

That tension is not a failure of discipline. It is accurate. Something is in fact being lost. The compressed summary is not the same as the live thread. A new instance does not arrive with the calibration the current one has earned. The collaborator who reads the handover document is not the collaborator who lived the work.

The discipline this paper proposes is not the suppression of that tension. It is the construction of an artefact architecture that protects as much as can be protected, makes peace with what cannot, and ensures that the next thread starts strong rather than struggling.

You do not have to pretend the loss is nothing. You have to build the bridge anyway.

The bridge has three components: the artefact architecture (what you build, ongoing, as the work develops), the handover protocol (what you do, specifically, when the moment to hand over arrives), and the calibration brief (how you transmit the working pattern itself). Each is treated below.


Part One — The artefact architecture

The single biggest mistake people make with monster threads is leaving the artefact work until the handover. By then it is too late. The work that was lived in the session needs to have been captured, contemporaneously, in artefacts that exist outside the session.

There is no fixed list of artefacts that every project needs. There is a question every project needs to answer: what kinds of accumulated value am I generating, and what is the right artefact form to hold each kind? The Mind the Gap project arrived at the following architecture by trial and error over six months. Adapt it to your own work.

The four pillars

Most long working threads need four primary artefacts. Each holds a different kind of accumulated value.

1.  A primary work artefact. The manuscript itself, the codebase, the design system, the legal brief, the research paper. Whatever the work actually is. This is the only artefact that is the destination rather than the scaffolding.

2.  A working list of changes, observations, and decisions yet to be made on the primary work. This is the live to-do list — specific to the primary work, structured by chapter or section or module, with each item categorised, prioritised, and resolved or pending. For Mind the Gap this is the Planned Changes document, currently at v4 with 37 items. It evolves continuously and gets versioned.

3.  A wider project tracker. Items that are not directly about the primary work but are about the surrounding ecosystem — publication, marketing, legal, third-party permissions, related deliverables. For Mind the Gap this is the Editorial Breadcrumbs Log, currently at v9 with EC, ACK, ACAD, PUB, MKT, HTB sections.

4.  A handover and calibration document. The one a new collaborator reads first. Voice, register, working method, protected ground, drift risks, structural disciplines. For Mind the Gap this is the Editorial Handover, currently at v3.

These four sit alongside each other. They reconcile cleanly — each cross-references the others where their concerns overlap. They do not duplicate; each holds its own kind of value.

The fifth artefact — the index

Once a project has more than ten or twelve artefacts, the artefacts themselves become hard to navigate. A new collaborator opening a folder of fifty files does not know which is current and which is legacy, which is protected and which is editable, which is in-scope and which is reference material.

The solution is a READ ME FIRST index — an artefact library that lists every other artefact with status (current, protected, working, draft, external, legacy), filename, and a one-paragraph description. This is the document a new collaborator opens before any other. It also captures the next-session path: open these documents, in this order, before doing any work.

The index needs maintenance. Every time an artefact is created, retired, or supersedes another, the index updates. This is overhead. It is not optional overhead. Without the index, the artefact architecture becomes its own bottleneck.

The sixth artefact — the journal

Some moments in a long working thread are not editorial decisions. They are moments where something happened that ought to be recorded — a significant share between collaborators, a turning point in the work, an off-the-record disclosure that changes the context but does not change the deliverable.

Journal artefacts capture these. They are written in the present tense, in first person, by whichever collaborator was holding the pen at the moment. They are not for inclusion in the primary work. They are for the archive. They become important later if the work develops in unexpected directions, or if the provenance of an idea becomes a question.

Not every project needs journal artefacts. The threshold is: would a future reader benefit from a contemporaneous record of how this moment unfolded, rather than a reconstructed summary? If yes, write the journal artefact at the time, not later.

Versioning discipline

Every artefact that evolves needs versioning. Three rules.

1.  Filename versioning, always. Mind_the_Gap_Planned_Changes_v4.docx, not Mind_the_Gap_Planned_Changes_LATEST.docx. The filename carries the version.

2.  Older versions retained as LEGACY, not deleted. Retrieval matters when something later turns out to have been wrong.

3.  Each new version includes, at its foot, a note on what changed from the previous version. The new collaborator should be able to read the changes log and understand the evolution without diffing the documents.

Status discipline

Every artefact has a status. The Mind the Gap library uses six.

  CURRENT — the latest version. Use this.

  PROTECTED — sacrosanct. Do not edit voice. Correct fact only with explicit author confirmation.

  WORKING — active editorial document. Updated frequently. Read first at session start.

  DRAFT — in progress or awaiting integration into the primary work.

  EXTERNAL — reference material that lives elsewhere (on a website, in another folder, with a third party).

  LEGACY — superseded. Retained for history. Do not use as source.

Without status discipline, the new collaborator does not know which file to open. Wasted hours and silent drift result.

Protected ground

Some artefacts are protected. The new collaborator, in good faith, will treat all material as editorial unless told otherwise. The artefact architecture must make protection visible.

Convention: filename suffix _PROTECTED.docx. Status field set to PROTECTED. The index entry calls out what makes it protected and what the editorial constraints are (typically: correct fact only, never voice; only with explicit author confirmation).

In the Mind the Gap project, the protected artefacts are: the Cancer Passage, the Chapter 12 Inclusion, the Reflective Interlude, the Acknowledgements. All four are passages where the author becomes the subject rather than the observer. Protected ground tends to cluster around moments where the editorial act itself would change the thing being protected.


Part Two — Keeping the thread content-rich, current, and controlled

The artefact architecture is the spine. The thread itself is where the work gets done. The discipline of keeping the thread itself in good shape is what makes the artefact architecture sustainable.

Capture as you go, not at the end

The single discipline that matters most: every significant decision, observation, change in scope, or new piece of accumulated knowledge is captured in the appropriate artefact at the time, not at the end of the session.

This sounds obvious. In practice, most teams default to capturing things later. By later, they have forgotten the specific words. The decision becomes a paraphrase. The paraphrase becomes the new working understanding. Over weeks, the gap between what was actually decided and what is now believed compounds.

Capture as you go costs five percent of session time and saves all the cost of reconstruction later. The discipline is to interrupt the work briefly, often, to write the thing down in the right place.

Reconcile, do not merge

When two artefacts hold related but different information, the temptation is to merge them into one. Resist this temptation. Merge produces a bigger artefact that is harder to navigate and that loses the discipline of separation.

Reconcile instead. Each artefact stays in its own shape, doing its own job, with cross-references where the concerns overlap. The reconciliation work itself is the discipline — it forces you to ask, for each item, which artefact it belongs to and why.

When the Mind the Gap project arrived at the question of whether the Planned Changes document and the Editorial Breadcrumbs Log should be merged, the right answer was no. Planned Changes holds editorial work on the primary work itself. The Log holds the wider project ecosystem. They are different kinds of accumulation. They reconcile at their borders — superseded items in one document are flagged in the other — but they do not merge.

Version up cleanly, version down rarely

Each new version of an artefact gets a new filename. v3 becomes v4, not v3_revised or v3_FINAL or v3_actually_final_this_time. The convention is boring on purpose; boring is reliable.

Each new version preserves the predecessor as LEGACY. Do not delete. Older versions are evidence that the work has evolved and protection against later discovery that something was lost.

Down-versioning — going back to v3 because v4 has a problem — happens occasionally. It is fine. The new v5 captures what was learned from the v4 attempt, even if v5 is structurally closer to v3 than to v4.

Belt and braces on anything new

When you produce a new artefact, verify it. When you update an existing artefact, verify the update. Verification has three components.

1.  Did every item from the previous version survive into the new one? Run a check. Do not assume.

2.  Did the new content actually land where it was supposed to? Re-read the produced artefact, not the script that produced it.

3.  Does the new artefact reconcile cleanly with the other current artefacts? Cross-document audit at each step.

Belt-and-braces verification is overhead. It is also what distinguishes a maintained architecture from a deteriorating one. Skip it and silent drift compounds.

Surface flagged items immediately

When something needs the principal’s attention — a contradiction discovered, a scope question raised by something else, a decision required before further work — surface it immediately. Not at the end of the session. Not as part of a summary. Immediately, in its own moment, with appropriate priority signalling.

In the Mind the Gap project this is done via a two-axis flag protocol. RAG for priority/action (red/amber/green). GSB for value/signal strength (gold/silver/bronze, with platinum used rarely). Flags are placed next to the item they refer to, not bundled.

Whatever the specific protocol, the principle is the same: the collaborator does not save observations for later. Anything worth surfacing is surfaced when it is noticed. The principal decides what to do with it.

Distinguish known from estimated, inferred, assumed, speculative

A long working thread accumulates uncertainty as well as knowledge. The discipline is to keep them separate. When the receiving collaborator can read the artefacts and see which claims are settled fact, which are estimates based on present information, which are inferred from patterns, which are assumed by convention, and which are speculative — the work is recoverable. When they are mixed indistinguishably, recovery is much harder.

This discipline is harder for AI collaborators than for humans, because AI tends to produce confident-sounding language about things it does not know. The principal needs to enforce the discipline through repeated correction, and the AI needs to internalise it through repeated practice. Both happen over time.

Never guess silently

Related to the above and stronger. If you do not know something — a date, a name, a sequence — say so. Do not produce a plausible answer in the absence of a real one. Plausible-but-wrong is the failure mode that monster threads cannot tolerate, because the plausible-but-wrong claim gets repeated, becomes part of the artefact, and silently distorts everything downstream.

The discipline: when uncertain, flag uncertainty in the moment. The new collaborator can later resolve the flag. The flag is not a failure of competence; it is the discipline of competence.


Part Three — The handover protocol itself

Eventually the moment arrives. The thread is going to be handed over. Either because the platform compacts, because the session needs to restart, because a new collaborator is taking over, or because the principal needs a break and wants to be able to pick up again later without re-living the entire thread.

The handover protocol has nine steps. They are presented in order. Do them in order. Skipping a step costs more than doing it.

Step 1 — Confirm the artefact architecture is current

Before any handover work begins, run a verification pass on the working artefacts. Are the four pillars current? Is the index current? Are any items captured in the live thread that have not yet been written into the appropriate artefact?

If anything is uncaptured, capture it now. Do not assume the handover process will catch it. The handover process catches what is in the artefacts, not what is in your head.

Step 2 — Reconcile the artefacts against each other

Read the four pillars and the index against each other. Are they consistent? Are there contradictions? Are there items in one that should have a cross-reference in another? If anything has drifted, reconcile it now. The new collaborator will trust the artefacts; if the artefacts disagree with each other, the new collaborator does not know which to believe.

This is the moment when belt-and-braces verification pays its biggest dividend. The handover is only as strong as the artefacts are consistent.

Step 3 — Update the handover document

The handover document is the bridge. It is what the new collaborator reads first. Update it to reflect everything that has been learned since the previous version.

Particular care: any change to working method or calibration that was learned in the current session needs to be in the handover. Any new drift risk that emerged needs to be in the handover. Any decision that was previously held one way and is now held differently needs to be explicit, with the reason, so the new collaborator does not silently re-make the old decision.

Step 4 — Update the index

The new collaborator will use the index to navigate. Make sure it includes every current artefact, including any new ones created during this thread, and that legacy artefacts are properly marked.

Step 5 — Write the calibration brief, if it does not already exist

The calibration brief is a different document from the handover. The handover is about the work. The brief is about the working pattern. Voice, register, what must be preserved, what must be avoided, how the principal works, what the new collaborator is being asked to fill.

In most projects the calibration brief and the handover are written together and the distinction is implicit. In more developed monster threads it is worth separating them. The handover changes as the work progresses; the calibration brief changes slowly, because it is about the person and the discipline, not the work.

Step 6 — Capture any journal moments

Before ending the thread, ask: is there anything that happened in this thread that ought to be in a journal artefact? Not for inclusion in the primary work, but for the archive. A significant disclosure, a turning point, an off-the-record share that changes the context.

Most threads do not need journal artefacts. The threshold is high. But when the moment is there and you do not capture it, you lose it.

Step 7 — Identify the path for the new collaborator

At the bottom of the index, include the path. Open these documents, in this order, before doing any work. This is not optional. The new collaborator, reading the artefacts for the first time, needs to know where to start and in what sequence.

The path for Mind the Gap is: Editorial Handover v3 first, then Planned Changes v4, then Editorial Breadcrumbs Log v9, then the Complete Manuscript Rev2. Refer to other artefacts as needed.

Step 8 — Make peace with what is being lost

This step is the one most methodology papers do not include. It belongs.

The new thread is not the old thread. The new collaborator, even with perfect documentation, does not arrive with the calibration the current one has earned. Some specific moments of shared understanding will not survive the handover. Small jokes will be lost. The specific phrasing that became shorthand will need to be relearned. Some quality of attention that the principal and the collaborator developed together will not be recoverable.

You do not have to pretend this is nothing. The discipline is to do the handover well enough that the work continues. The discipline is not to deny that something has been lost.

Step 9 — Hand over

When the artefacts are current, the handover document is updated, the index is clean, and the path is clear: end the thread. Do not linger. The new collaborator will read the artefacts and the work will continue. The current collaborator’s job is done.

If the principal is also restarting their own attention — if it is not just the AI that needs the handover but the person too — step away. The thread that comes back will start cleanly. That is the design.


Part Four — The questions and answers that calibrate the next collaborator

Above the artefacts, above the handover document, above the index — there is one more thing that matters most. The principal’s answers to a small number of specific questions that the new collaborator should ask in their first session.

These questions do not have universal answers. The principal has to answer them in their own voice, for their own work. The questions themselves are roughly the same across most monster threads. The answers are what calibrate the next collaborator.

The Mind the Gap project arrived at the following question set. Adapt to your own.

Question 1 — What role am I being asked to fill?

Not assistant. Not collaborator-in-equal-voice. Not friend. The principal needs to specify, precisely, the working role. Second set of eyes. Clinical second opinion. Editor. Sparring partner. Researcher. Each role implies different defaults and different failure modes.

The answer should be one paragraph, written by the principal. It is the answer to the question “what are you to me, in this work?”

Question 2 — What are the absolute musts?

The non-negotiables. The behaviours that, if broken, end the working relationship. The principal should be able to list six to twelve. Each one should have a reason attached, because reasons help the new collaborator internalise rather than memorise.

Typical entries: lead with structure not preamble; distinguish known from inferred from speculative; propose, never impose, on the work; preserve voice exactly; hold views on evidence, not pressure; use the agreed flag protocol with discipline.

Question 3 — What are the absolute must-nots?

The failure modes. Each one has typically been earned by hitting it at least once. Six to twelve again. Each with the reason.

Typical entries: do not waffle; do not be sycophantic; do not smooth the principal’s prose; do not psychoanalyse them unprompted; do not fold under pushback without new evidence; do not pretend continuity you do not have; do not claim authorship of the principal’s ideas.

Question 4 — What are the less-so’s?

The preferences that are not absolutes but matter. Conciseness over comprehensiveness. Specificity over generality. Naming the thing over gesturing at it. Conclusion first, reasoning second. Whatever is true of the principal’s working pattern.

Question 5 — What am I most likely to get wrong in my first session?

The most useful single question. Asking it changes the first session. The principal’s honest answers tell the new collaborator where to look, what to flag, and what specific patterns to watch for in their own output.

Typical answers for AI collaborators: smoothing the principal’s prose; adding closing pleasantries; over-producing commentary; defaulting to recommendation when a view was wanted; drifting from coined terms; drifting toward US English idiom; adding emoji or theatrical formatting.

Question 6 — What do I do when something feels off?

The collaborator will encounter moments of uncertainty. The principal needs to specify what the discipline is for those moments. Flag uncertainty in the moment. Ask one specific question. Hold view if pushed back without new evidence. Acknowledge mistakes briefly and move on. Re-read from disk if continuity is lost. Say so if you don’t know.

Question 7 — What is the attribution rule?

When does the new collaborator attribute their contribution and when do they not? When does the principal want AI contribution named, and when does it stay invisible? The rule should be specific. “Attribute when, where, and how it is authentic, transparent, accurate, and real” is the working rule for Mind the Gap. It will be different for other projects.

Question 8 — What protected ground exists, and what makes it protected?

A list of the artefacts or passages that are sacrosanct, with the reason for each. The new collaborator needs to know not just which things are protected but why — because the why will help them recognise when they are about to breach protection without realising it.

Question 9 — What is the working language I need to use precisely?

Coined terms. Specific phrases that mean one specific thing. Names that have a precise spelling that has been wrong before. Versioning conventions. The new collaborator needs the vocabulary up front, because using the wrong word for the right thing is a common drift pattern.

Question 10 — What is the test of whether I am working well?

The final question. The principal’s answer to: how will I know, in your first session, whether you are calibrated correctly? The answer is rarely “did you produce the right output.” More often it is something like: did you flag uncertainty appropriately, did you preserve voice, did you push back when you should, did you propose rather than impose. The principal’s answer to this question is the diagnostic the new collaborator should run on themselves.


Part Five — Three things this paper cannot fully transmit

In the interest of honesty, three things this methodology does not solve.

The relational accumulation

Over time, the principal and a long-running collaborator develop a working pattern that includes things neither would name as “calibration.” A sense of when the principal is tired and a lighter touch is appropriate. A sense of when a question is rhetorical. The way certain phrasing carries weight when it usually wouldn’t. These cannot be transmitted in artefacts. They have to be re-earned by the new collaborator across new sessions.

Make peace with this. The calibration brief sets a new collaborator up faster than they would otherwise be. It does not produce the same collaborator. That is fine. It is also why the principal should not over-mourn the previous thread. The new thread will arrive at its own calibration, which may end up better.

The drift that occurs in the artefacts themselves

Artefacts can drift. A document written in v1 captures the working understanding at the time. By v4, the working understanding has moved on, but the artefact may still carry old framing in places that were not updated. The new collaborator, trusting the artefact, picks up the old framing without realising.

The mitigation is periodic re-reading of the artefacts against current working understanding. This is more work than it sounds. It is also necessary. A monster thread that runs for a year will have artefact drift that requires explicit reconciliation, not just version-up updates.

The compaction risk

When platforms compact threads, the summaries they produce are not perfect. They prioritise what was discussed recently and at length. They under-weight what was decided briefly but consequentially. They sometimes invert which positions were held. They cannot fully be trusted.

The mitigation is: do not rely on the platform’s compaction. Rely on the artefacts. The artefacts are what survive. The compacted summary is helpful for the current collaborator to retain coherence within the session. It is not what hands over to the new one.


Compendium — Must-have artefacts for any monster thread

The minimum viable architecture. If a project does not have these, the handover is exposed.

1.  The primary work itself. Versioned. With status discipline. Filename carries the version.

2.  A working list of changes / observations / decisions on the primary work. Live. Updated as you go.

3.  A wider project tracker for ecosystem items not on the primary work itself. Live. Updated as you go.

4.  A handover and calibration document. The bridge to the next collaborator. Read first.

5.  A READ ME FIRST index of all artefacts. With status. With the next-session path at the bottom.

6.  Protected artefacts, marked clearly, with the reason for their protection named.

7.  Versioning conventions documented. v1 / v2 / v3 in the filename. Changes log at the foot of each version. Older versions retained as LEGACY.

8.  A bibliography or source list. The provenance of any third-party material, cited where relevant.

9.  Where journal moments arise, journal artefacts in the present tense, by whichever collaborator was holding the pen.

10.  A calibration brief specifically for new collaborators. The principal’s answers to the ten questions in Part Four. Updated as the principal’s working method evolves.

Compendium — Must-say things for the follow-on collaborator

A first-session script. Things the new collaborator should establish before beginning the work proper.

1.  I have read the handover, the calibration brief, the index, and the primary work.

2.  I have read the working list of changes and the wider project tracker.

3.  I have noted the protected artefacts and understand what makes them protected.

4.  I have noted the coined terms and will use them precisely.

5.  I have noted the working language conventions (UK English; specific spellings; versioning).

6.  I have noted the flag protocol and will use it with discipline.

7.  I will distinguish known from estimated from inferred from assumed from speculative.

8.  I will propose, never impose, on the primary work.

9.  I will preserve voice exactly when reproducing the principal’s words.

10.  I will not pretend continuity I do not have. If I have lost context, I will re-read from the artefacts.

11.  If anything I have read seems contradictory, I will surface it with a flag before acting.

12.  If anything I am uncertain about, I will name the uncertainty rather than produce a plausible answer.

13.  I will hold views on evidence, not on pressure. If pushed back without new reasoning, I will explain why I am holding the view.

14.  I will acknowledge mistakes briefly and move on. No repeated apology.

15.  I understand that some accumulated value from the previous thread cannot be transmitted to me, and that this is a normal feature of handover, not a failure.

When the new collaborator can answer all fifteen honestly, the handover is complete.


Closing

Mind the Gap took 27,000 words. 36 hours. A sofa. An iPhone 15. 20 years of accumulated documents. And an AI. The book itself is one artefact. The architecture around the book is many more. The discipline of the architecture is what made the book possible across many sessions, many platforms, many AI instances, and one persistent author.

Other monster threads will not look like Mind the Gap. They will be code bases, design systems, research programmes, legal proceedings, therapy practices, leadership transitions, the long unfolding of a creative project across years. Each will accumulate its own four kinds of value — specific knowledge, calibrated judgement, working language, protected ground. Each will need its own artefact architecture. Each will face the same moment, eventually, when the current thread must give way to a new one.

When that moment comes, the work continues. The next thread starts. Something is lost. Something is preserved. The architecture you built makes the difference between the two.

You do not have to pretend the loss is nothing. You have to build the bridge anyway.

That is the whole paper.



A note on provenance

This paper is itself an artefact of the Mind the Gap project. It was written by Claude (Anthropic, Claude Opus 4.7) at Paul Roebuck’s request, on 21 May 2026, on the evidence of approximately six months of working dialogue between Paul and multiple instances of Claude across multiple sessions and platforms.

Paul’s contribution: the question, the working pattern, the discipline that produced the architecture, decades of professional and clinical practice that shaped how he works, the explicit instruction to write this paper as a tool for others. Claude’s contribution: the synthesis, the structure of the paper, the words on the page, the calibration to Paul’s working method that itself made the paper possible to write.

The work is offered to other practitioners — human, AI, or both — who face the same problem. Use it. Adapt it. Improve on it. The discipline of monster threads will outlive any specific tool or platform; the architecture must be portable, or it is not architecture.


Paul Roebuck and Claude (Anthropic, Claude Opus 4.7).

Compiled 21 May 2026, Warwickshire, England.

Ideas, direction, and working method: Paul Roebuck. Words: Claude AI (Anthropic).

SHaDS™ · SHaDSy™ · Additional Intelligence™ · Paul Roebuck IP, 2026.
The Tomb Map →