Here is the question that kills the idea before anyone examines it.

It sounds responsible. Document control is real. Version histories are real. Shared drives, email trails and published packs are real. The trap is not that people care about documents. The trap is that the question assumes the finished artefact is the source of the work.

In AI-assisted knowledge work that assumption is false in the same way it has already become false in software. Source is relative to the compiler boundary. Relative to publication, the document is source. Relative to the meaning-making process that produced it, the document is compiled output. The conversation that carried intent, rationale, rejected alternatives and uncertainty is upstream.

The thesis in one sentence

In AI-assisted knowledge work the conversation that produced an artefact is upstream source and the finished document is compiled output — so an organisation that keeps only its documents has kept the results and discarded the reasoning that produced them.

The final document may be the least semantically useful view of the work.

That line is deliberately counterintuitive. It is also the claim this book is here to make operational. Finished artefacts are optimised for audience and purpose. That optimisation is a feature of publication. It is also why those artefacts are often a poor substrate for meaning-search, for reconstructing why a change happened, and for recognising investigation that compressed into a short recommendation.

What you will be able to do

After this book you should be able to articulate what a finished artefact structurally cannot contain, and specify the structured work event every approved AI surface should emit. The takeaway is not motivational. It is a schema, three worked proofs, and a contract.

Part I installs source-relativity: the software parent rule, the knowledge-work compiler cascade, the six-layer distinction between kinds of artefact, the least-useful-document inversion, and the invisible things deliberation holds. Part II does the work the outline promised: a side-by-side invisible-work episode, an inherited-content search demonstration, the Claude Code commit write/read loop at full weight, and a Knowledge Work Commit specified tightly enough to implement next week. Part III names the common emission contract, the Cognitive Git stack, the hard boundaries of this book, and a Monday installation checklist.

What this book will not do

How a conversation is joined to a specific artefact version is a real problem and a separate problem — owned by a forthcoming companion on the deliberation–artefact join. What management does with the aggregate of captures — weekly cognitive-state views, friction maps, capacity hypotheses — is owned by another forthcoming companion. Privacy, consent and employment-law mechanics matter and exist; they are not designed here. This book owns source-relativity for knowledge work and the emission contract that makes capture useful.

Live neighbours in the series already own route-invariant grounding, wiki redundancy as error correction, novelty-preserving design, inbound edges, derivational provenance, gold that addresses reality, and the AI partner as challenger rather than arbiter. This book links out rather than re-arguing them. It does not self-link. It does not invent URLs for unpublished siblings.

The incumbent model

The default belief is simple: the polished artefact is the work product and therefore the knowledge asset. Filing systems reinforce it. Document control reinforces it. “If it is not in the file it did not happen” reinforces it. The model fails when the artefact is optimised for an audience that must not see the investigation. Publication is compression with a purpose. Compression with a purpose is not a complete record of meaning-making.

Teams that keep every board pack, every workbook, every deck still cannot answer ordinary questions: why an assumption flipped; which option died and for what cause; whether a paragraph is original or inherited; whether a short recommendation was cheap or expensive to produce. Those are not exotic audit questions. They are how institutions learn, how managers unstick work, and how agents later reconstruct what a prior session meant.

Why now

Enterprises are choosing between blocking AI on privacy grounds and letting conversations disappear into retail tools. Both fail the source test. Blocking freezes capability. Retail capture freezes reasoning outside the company’s reach. Surfaces are proliferating. The window in which a common emission contract can be specified — before a dozen unjoined tools each keep their own silent logs — is open and closing. Coding agents already preview a self-densifying semantic loop in how they write and then read commit messages. Knowledge work can install the same contract without waiting for a perfect management dashboard or a perfect version-join resolver.

The document is the what. The deliberation is the why.

Hold the reader question through every chapter. The answer is not “save more chats.” The answer is stage-relative source for knowledge work, a Knowledge Work Commit, and an organisation that stops throwing away the meaning-making process that produced its documents.

What the organisation actually loses

Be concrete about the loss function. When only the uploaded document is retained, the organisation systematically discards dated intent in the worker’s own words; rejected alternatives with causes; never-completed plans; uncertainty that survived publication; friction that made the work expensive; and the inheritance boundary between copied-forward mass and originated work. Those are not “nice notes.” They are the difference between a filing system and a memory system.

Software teams already learned a version of this the hard way: repositories without transcripts cannot answer “what did we consider and defer?” Knowledge organisations are about to re-learn it at larger scale as AI makes deliberation explicit, structured and — if they choose — capturable. Choosing not to capture is not neutrality. It is a decision to keep results and discard reasoning.

Here is a pattern that keeps appearing on AI-generated software projects. The team treats the repository as sacred. Every module is committed. Pull requests look orderly. Six weeks later nobody can answer a simple question: why does the retry path wait exactly that long, and would a second agent run make the same choice? The chat is gone. The agent instructions were never filed. The acceptance criteria lived in someone’s head. The code remains. The judgment that produced it does not.

We say we have source control. We have intermediate-representation control. The earlier stage — the one that actually encoded the decisions — was discarded because it looked like “just prompting.”

Source is relative to the compiler boundary.

The parent rule from software

When intent, prompts, context, tests and starting state can regenerate equivalent behaviour, generated code is intermediate representation relative to the package above it. The durable asset is the upstream source package: intent, design, prompts, worldview context, acceptance tests, starting repository state, and decisions that cannot be safely inferred from the files alone.

That is the load-bearing claim of The Prompt Is Source. This book will not re-derive that entire argument. It will use it as the parent rule and generalise it. The software case is the cleanest place the relativity becomes obvious, because the industry already has vocabulary for source, compile, commit and deploy. Knowledge work has the same structure and weaker vocabulary.

An earlier compiler stage

The developer–AI discussion is not merely “pre-source” in a vague motivational sense. It is source at an earlier compiler stage. The stack looks like this:

• human intent and observation
• developer–AI deliberation
• rejected alternatives and decisions
• acceptance tests and analysis harnesses
• generated or edited code
• commit and build
• deployment
• observed production behaviour

Relative to Python and Git, the .py file is source. Relative to the AI development process, that file is already compiled output from the upstream package of intent, dialogue, context, tests and decisions. If you only keep the file, you have kept a later stage and discarded an earlier one.

The transcript is a source map

Most reverse engineering is hard because binaries ship stripped. Names, comments and intent were discarded at compile time. AI-native work is different when you refuse to throw the intermediate representations away. Transcripts and prompts are not process noise. They are the source map — code is the what; the transcript is often the why.

The transcript carries information the resulting code cannot reconstruct: why the choice was made, what was rejected, what was attempted, what failed, and which conditions mattered. Keep-the-bronze discipline is the same argument in archive language: do not discard a representation a later pass may need.

The Delete Test (cameo)

A useful falsification from the software parent book: if deleting the generated implementation loses judgment that exists nowhere upstream, the code is still partly source. If equivalent behaviour regenerates from the upstream package, the code has become disposable intermediate representation. The test is not a slogan. It is a way to notice whether you have actually retained the stage that encodes decisions, or only the stage that encodes outcomes.

Why this chapter stays in software

Doctrine clean-room: this chapter installs the parent mechanism without the corporate specimen work that comes later. The point is precision of the relativity claim. Once you accept that source is stage-relative in software, the knowledge-work generalisation in Chapter 3 is not a leap. It is the same compiler boundary drawn around Word files, workbooks and decks instead of around .py files.

What changes in the generalisation is not the logic. What changes is the industry’s instinct. Software teams at least have git and the word “source.” Knowledge workers have document libraries and the word “deliverable.” Deliverable is a publication word. It is not a source word. Confusing the two is how organisations become excellent at filing and poor at remembering why.

Chapter 3 draws the cascade for ordinary knowledge work. Chapter 4 separates the layers so they are not averaged into a single muddy “project says.” Keep the software parent in mind as you read those chapters: the relativity is not a metaphor. It is the same structure with different artefact names.

Precision note from practice

Even inside software, the layers are easy to blur. A system that can route to live code, to a recorded development session, and to a wiki page must still say which evidence it actually opened. Reading a transcript that contains edit operations and test outputs is not the same as independently verifying a git diff. Provenance discipline is naming the layer you used. That discipline is exactly what knowledge-work capture must inherit: the Knowledge Work Commit should say what was read and changed, not merely produce a fluent summary of “the work.”

The parent software doctrine also warns that source maps matter for reverse engineering. When only generated files remain, you are back to the legacy predicament with prettier syntax. When every layer is retained, forward and reverse reconstruction both get cheaper. Knowledge work has been living in the legacy predicament permanently: polished packs without the intent stream that produced them.

Chapter 2 installed the software parent. This chapter draws the same cascade for people who are not writing code — which is most knowledge work in most organisations, most of the time.

For developers the cascade is familiar once named:

prompt and deliberation → code → tests → deployment

For ordinary knowledge workers the cascade is:

intent and deliberation → Word document, spreadsheet, presentation, email, decision or plan

That second line is the contribution this book owns. The Prompt Is Source remains the rigorous parent for coding agents. This book generalises the stage-relative rule into the surfaces where most corporate meaning is produced.

The Deliberation Is Source

In AI-assisted knowledge work, the conversation that produced an artefact is an upstream source map. It contains intent, rationale, alternatives, corrections, uncertainty and plans that the final artefact often compresses away.

Call the doctrine by name: The Deliberation Is Source. The repository is not the entire source for software because it preserves what was implemented but not all the judgment that produced it. The same applies to Word files, workbooks, decks, shared drives and email. Those systems hold published state. They do not hold the judgment that produced it unless someone happened to type the judgment into the artefact — and publication incentives usually push the other way.

Two cascades, one structure

Read the table as structure, not as a claim that every row maps one-to-one in tooling. The point is that knowledge work already has stages. Enterprises already keep some of them (the published pack). They systematically under-keep the deliberation stage now that AI makes that stage explicit, structured and capturable.

Source before the artefact

In the vocabulary of this series, the move is earlier than the finished artefact in the compiler cascade. It is not the compact map layer of a read ladder. It is source before the artefact. When knowledge workers use AI — and when organisations finally allow them to do so on approved surfaces — the conversation is not a disposable chat around a deliverable. It is the stage at which intent becomes articulated, alternatives die with reasons, and assumptions get named.

Today those conversations often die in retail tools the company cannot search, or sit in private agent logs that never join the document the worker eventually posts to a shared drive. The organisation captures the output when it lands in email or a document library. It does not capture the deliberation that made the output intelligible. That is the corporate generalisation this book exists to make expensive to ignore.

Generic surfaces, not product claims

Word, Excel, PowerPoint, SharePoint, Teams, Slack, Jira and ServiceNow may appear in this book as generic work surfaces — places where knowledge work happens and artefacts land. Nothing here depends on a vendor-specific claim about any of them. The doctrine is about stages and emission, not about which office suite you bought.

Claude Code will be named later as a load-bearing public case study for git-commit behaviour. That is a different kind of naming: a real coding-agent product whose observed write/read loop previews Cognitive Git. It is not a product endorsement. It is a specimen of self-densifying semantic waypoints already in the wild.

What changes operationally

If deliberation is source, then “we keep every document” is necessary and insufficient. You still need the published artefacts as authoritative content objects. You also need the upstream stage as a source map into those objects. Chapter 4 separates the questions each layer can answer. Chapter 5 explains why the published layer is often the least useful semantic view. Part II shows the proofs: invisible work, inherited content, the commit loop, and the schema.

The repository was never the whole source for software. The document library is not the whole source for knowledge work. Once that sentence is allowed to stand, the rest of the book is mechanism and proof, not persuasion by vibe.

Why the generalisation is the contribution

The Prompt Is Source, the compiler cascade in software form, and Code What, Transcript Why are rigorously repository-scoped in their full treatments: commits, files, coding sessions. Every one of their mechanisms transfers. None of them has been claimed hard enough for the large share of knowledge work that never touches a repository. The generalisation is the contribution of this book — not a re-derivation of the software parent, and not a vague metaphor that waves at git.

Enterprises currently choose between blocking AI entirely on privacy grounds and letting conversations disappear into retail tools. Both choices fail the source test. The emission contract specified later is how you keep capability without throwing away the stage that encodes judgment. The cascade chapter is where that contract becomes thinkable: once you see deliberation as a stage, you can require a work event from that stage.

A project manager asks: why is the integration delay still open? A useful answer is not a dump of every file and every chat. A useful answer assembles several layers and keeps their statuses distinct: the original requirement; the meeting where the constraint was discovered; a developer’s AI session; a rejected first implementation; yesterday’s commit; a test that now passes; a deployment that has not occurred; an unresolved dependency owned elsewhere.

If those layers are averaged into a single narrative voice — “the project says” — the system becomes an extremely fluent way to misstate project reality. Discussed is not proposed. Proposed is not coded. Coded is not committed. Committed is not tested. Tested is not deployed. Deployed is not observed in production. Accepted is something else again.

Software layers (definitive table)

For understanding a software project, source is not one thing. There are several source layers answering different questions:

A credible project intelligence system preserves those distinctions. It does not pretend the conversation is the code, or the commit message is production proof, or a green test is a live service.

Knowledge-work analogues

The same discipline applies when the compiled output is a board paper rather than a module:

Read every row. The Knowledge Work Commit is not a rival Word file. It is the semantic waypoint — closer to a commit message than to a second document. The published artefact remains authoritative for its content. Outcome evidence remains authoritative for what the world did next. Conversation remains authoritative for intent and rejection. Collapse any two of those and you invent false certainty.

Status discipline

Status words are cheap to blur and expensive to unblur:

discussed ≠ proposed ≠ drafted ≠ reviewed ≠ approved ≠ published ≠ observed in operation ≠ accepted

AI systems that can join layers fluently make status discipline more important, not less. The more uncanny the join, the more damage a collapsed status causes. A recommendation that was drafted is not a decision. A decision that was approved is not an implemented process change. A process change that was announced is not an observed operational outcome.

Where these layers live together

Teams already try three wrong homes for project understanding: chat that dies, folders that lie flat, and institutional wikis that freeze the wrong things. The missing mesoscale is a project-bounded world that outlives sessions without pretending every inference is permanent firm doctrine.

This book does not re-own Engagement World design. It needs the existence of a place where Knowledge Work Commits can join a project without dumping every session into the firm wiki. Multiple actors can write into one project world without perfect memory of one another’s sessions — provided origin, authority and intermediate state are preserved.

Why the table comes before the inversion

Chapter 5 will argue that the final document is often the least semantically useful view. That claim is sharper once you have the table. The document answers one row. Deliberation answers another. Commits answer a third. The organisation that only files the document is not “being practical.” It is answering one question and discarding the rest — then wondering why search cannot recover why.

The table also protects the Knowledge Work Commit from a common design error: treating the commit as a second copy of the document. It is not. The document remains the authoritative content object for published prose and numbers. The commit is the waypoint layer — closer to git metadata than to a rival Word file. If you try to make the commit carry full board-paper prose, you will recreate publication bias inside the schema. If you leave the commit as intent, semantic delta, rejects, uncertainty and status, you preserve the layer that publication is designed to erase.

Assembling without averaging

A capable system could assemble, for a single open delay: the original requirement; the meeting where the constraint was discovered; a developer’s AI discussion; a rejected first implementation; yesterday’s commit; a test that now passes; a production deployment that has not yet occurred; an earlier similar problem; an unresolved dependency owned by another team. That assembly is valuable only if statuses stay distinct. The same joining capability without status discipline becomes a confident misstatement machine.

Knowledge-work versions of the same assembly already happen informally in people’s heads: someone “knows” that the short recommendation cost two days, that the spreadsheet mostly inherited last year, that legal blocked an assumption. Informal knowledge walks out of the building. Structured layers do not have to.

When you later meet the invisible-work and inherited-content proofs, return to this chapter’s tables. Those proofs are not new metaphysics. They are what happens when an organisation answers only the artefact row and pretends the conversation, waypoint and uncertainty rows do not exist. Six layers, six questions is the preventive discipline; Part II is the cost of ignoring it made concrete.

The final document may be the least semantically useful view of the work.

Give that sentence room. It is the most counterintuitive claim in the book, and the one most likely to be quoted out of context as an attack on documents. It is not an attack on documents. It is an attack on the belief that the publication-optimised residue is the complete knowledge asset.

Finished artefacts are usually optimised for their audience and purpose. That is a feature of good communication. It is also a systematic deletion of the material deliberation carries: verbs, causes, contrasts, rejects, uncertainty and inheritance boundaries.

Walk the artefact types

Board paper

A board paper suppresses messy deliberation on purpose. Sponsors want a decision path, not a laboratory notebook. The suppression is rational for the room. It is disastrous if the organisation later pretends the paper is the full record of why Option B survived and Option A died.

Spreadsheet

A spreadsheet stores outputs and formulas. It rarely stores why an assumption changed. The cell that flipped from 0.12 to 0.08 does not say “legal assumption not approved.” A comment might. Most do not. Historical worksheets bury the delta under inherited mass.

Presentation

A presentation reduces weeks of thought to twelve slides. That is its job. The job is compression for attention. Compression for attention is not a source map of the investigation.

Policy

A policy inherits historical boilerplate. Search will find the boilerplate repeatedly. Search will not, by itself, tell you which clause was reconsidered this quarter and which clause is cargo cult from 2019.

Proposal

A proposal often reuses material from previous proposals. That reuse is efficient. It also means large chunks of the file did not originate in this episode of work. Document search cannot reliably separate inherited prose from originated argument unless the deliberation said so.

Email

An email records the communicated decision. It does not record every option considered in the hour before send. The thread may hold fragments. An AI session often holds the comparison structure explicitly.

What the conversation says instead

The AI conversation often states the useful thing with a directness the artefact will never match:

• “Change the forecast because the legal assumption is not approved.”
• “Remove this recommendation because operations cannot support it.”
• “We considered centralising the function but rejected it because the handoff delay outweighed the consistency benefit.”
• “This table is inherited from the 2024 report; only columns C and D were recalculated.”

Those are extraordinarily high-quality semantic statements. They contain verbs, causes, contrasts and intent. They are closer to meaning than the final cells or paragraphs. They are also the kind of sentence a later agent can retrieve without reverse-engineering a workbook.

What the deliberation still holds

The final document tells you what survived publication. The deliberation tells you:

• what the person was trying to achieve
• what sources they relied upon
• what they changed
• why they changed it
• what they rejected
• what they remain unsure about
• what they intended but never completed
• where they got stuck

That list is not a vague benefit catalogue. It is the same structural claim software teams already know: code records the final state; the transcript holds dated intent, rejected alternatives and work that never became code.

The document is the what. The deliberation is the why.

What we are not saying

We are not saying documents are worthless. We are not saying delete the library. We are not saying every chat token is sacred. We are saying the publication layer and the deliberation layer have different jobs. Assigning both jobs to the publication layer is how organisations become excellent at storage and poor at meaning.

Chapter 6 names the invisible things more precisely. Chapters 7 and 8 prove the inversion on real episode shapes: invisible work that compresses to one paragraph, and inherited content that defeats artefact search. Keep the signature line in mind as those proofs land. The least useful view is not a slight. It is a job description for the polished file — and a reason to keep the stage above it.

Meaning density

The practical claim is about density of meaning per token for later retrieval. A board pack optimises for the board. A model session often optimises for getting the work right with a partner that asks for intent, alternatives and corrections. Those two optimisations produce different text. Searching the board pack for causal structure is searching the wrong compression. Searching the session is searching a text that was already forced to be explicit about causes.

That is also why AI-assisted work is a better capture opportunity than ordinary email. Email sometimes contains reasoning accidentally. AI interaction frequently contains explicit statements of goal, failure, comparison, assumption choice, unresolved issues and deadlines. The interaction almost pre-structures soft data for ingestion. You are not only mining historical exhaust. You are standing at the point where high-quality semantic exhaust is born.

Why the signature line is not an insult

Authors are doing their jobs when they suppress mess for the board. The organisational failure is treating that suppression as the whole record. AI makes the upstream record available as a natural by-product of getting the work right. Throwing it away is a choice, not a law of nature. If the polished file is the least useful semantic view for later search, then enterprise knowledge strategies built only on document libraries are optimising the wrong layer. Keep the library. Stop pretending it is the source of meaning.

When Part II walks invisible work and inherited content, it is not adding a new thesis. It is measuring the cost of assigning both jobs — publication and memory — to the publication layer alone.

When a session ends, the default habit is to keep the deliverable and throw away the conversation. The deliverable is the thing someone asked for. The conversation looks like chat. That habit is wrong for the same structural reason in software and in knowledge work: the deliverable and the conversation record different things, and only one of them can be reconstructed from the other.

The three things the repository cannot hold

In software, the transcript holds three things that are structurally invisible in the code.

1. Dated intent in the worker’s own words

Not a commit message written afterwards to satisfy a hook. The actual sentence typed at the start of the work: what success would mean, for whom, under what constraint. That is the strongest provenance you will ever have for why a system or a recommendation exists, and it is timestamped.

2. Rejected alternatives

Every real piece of work is a graveyard of considered-and-dropped approaches. The finished code shows the one path taken and erases every path not taken. The finished board paper does the same. The rejected branches carry real value: they prevent re-litigation, they document constraints, and they teach the next person what already failed.

3. Planned but never built work

The feature described in detail and deferred. The analysis scoped and not completed. There is no file for these — that is the point — so the repository or the document library literally cannot contain them. They exist in exactly one place unless you keep the deliberation.

The most valuable things in a session are the ones the repository can’t hold: the thing you considered and rejected, and the thing you planned and never built.

The gap is itself signal

The difference between transcript intent and shipped reality is information. “Considered X and deferred it” is a perfectly meaningful project fact that no code search can ever return, because a repository can only describe what exists.

Knowledge work has the same gap. “We almost recommended centralisation and stopped because of handoff delay” will not appear in a one-paragraph Option B recommendation. It will appear in the session that produced the paragraph. Months later, when someone asks whether centralisation was considered, document search returns silence or a misleading partial. Deliberation search returns a dated, defensible answer.

Three knowledge-work specials

Generalising beyond software, three additional capture targets matter repeatedly:

Read every row. Uncertainty that survives into the real world is often deleted from the pack so the pack looks decisive. Friction is treated as personal struggle rather than operating-system signal. Inheritance is invisible because the file does not colour-code “I wrote this today” versus “this survived from last year.”

Distil, do not hoard or delete

Raw sessions are high-fidelity and noisy. The move is neither to delete them on a timer nor to force every reader through raw logs. The move is distillation: keep raw bronze cold and safe; strip deterministically; let a cheap model produce a session brief focused on intent, decisions, rationale, rejects, blockers, open questions, artefacts changed and reusable learning.

Institutionally, that pairs with an episodic staging buffer and a governed semantic layer above it. Not every session becomes canon. Some patterns deserve promotion after human review. Most remain project history.

Chapter 7 makes invisible work concrete. Chapter 8 makes inheritance concrete. Chapter 9 shows software already densifying waypoints as commits. Chapter 10 turns the invisible list into an implementable schema. Doctrine without specimens is a slogan. The next part does the work.

From invisible list to fields

Chapter 10 will turn this list into schema fields. Preview the mapping so the doctrine chapter and the artefact chapter stay joined: dated intent becomes intent; rejects become alternatives; never-built work shows up in uncertainty and outcome (deferred, abandoned); inheritance and meaning change become semantic_diff; sticking points become friction; promotion candidates become reusable_learning. The schema is not a bureaucratic form invented for its own sake. It is the invisible list made emitable.

If your organisation only stores raw chat, you have bronze without a header. If you only store a managerial summary written a week later, you have a second publication layer with the same audience biases. The commit sits between: structured enough to search and promote, close enough to the session to still be source.

A worked mapping before the specimens

Lock one concrete mapping so the schema does not feel abstract when it arrives. Suppose a knowledge worker spends a morning with an AI assistant reconciling a forecast. The session includes: the goal (“correct the Q3 outlook for legal risk”); a rejected path (“keep the old legal assumption and soft-pedal risk”); a deferred plan (“rewrite the full risk appendix next month”); residual uncertainty (“ops capacity still unconfirmed”); friction (“legal opinion lives in three email threads”); and inheritance (“rows 12–40 are last year’s model; only the legal driver cells changed”).

The spreadsheet that leaves the session may look almost unchanged to a casual eye. The invisible list, however, is almost the entire value of the morning. That is why Chapter 10’s fields are not bureaucracy. They are the minimum envelope that keeps the invisible list emitable across surfaces. When you read the Option B filled example later, you should recognise the same envelope filled from a different episode.

If your organisation captures only the spreadsheet, it has kept the least informative view of that morning. If it captures the session and emits the envelope, it has kept both the what and the why — which is the whole thesis restated as an operations rule.

Much valuable knowledge work produces little visible output. That sentence should make every document-centric KPI nervous.

A worker might spend two days establishing that a proposal cannot work, reconciling conflicting interpretations, locating an undocumented dependency, discovering that three datasets cannot be safely joined, persuading several groups not to take the obvious path, and narrowing a problem until the eventual document becomes simple. The final artefact may be one paragraph saying Option B is recommended. The AI conversation may contain the actual value.

Walk the episode

Do not leave this as a gesture. Walk it.

Day one, morning. The brief looks like a standard operating-model recommendation. The obvious path is centralisation for consistency. The worker opens an AI session with the prior-year pack, regional notes and a system inventory. First pass: draft a centralisation recommendation. It reads cleanly. It is also wrong in ways the pack does not yet know how to say.

Day one, afternoon. Operations pushback surfaces in the deliberation: handoff delay between a central team and regional execution is not a soft preference. It is a service-level problem. The session records the rejection of full centralisation with a cause, not a vibe. The worker tries a hybrid: shared services hub. It looks like a compromise. It assumes a data join across three systems that the inventory treats as “related.”

Day two, morning. The join is not safely certifiable this quarter. The deliberation names the failure. An undocumented dependency on the regional finance calendar appears mid-analysis — the kind of constraint that never made it into the prior pack. Option B begins to look less like a soft middle and more like the only path that survives both operational delay and data constraints.

Day two, afternoon. Residual risk remains: specialist capacity in one region is a single point of failure. The worker needs authority for a temporary surge resource, not a redesign. The board paper’s recommendation section collapses into something a busy reader can accept in thirty seconds.

What the artefact says

Readable. Fileable. Almost empty of causal structure. Under a document-only regime, this looks like a light afternoon of drafting. That is not a quirk of board packs alone. Standard provenance models treat derivation — how an entity was produced from others — as first-class information, not something that can be reconstructed from the published entity in isolation.¹

What the deliberation says

Questions only the deliberation can answer

Read every row. The artefact is not lying. It is doing its job as a decision sentence. The organisation that keeps only that sentence has kept the result and discarded the reasoning. Capturing the deliberation makes invisible work legible. It can show that someone investigated difficult alternatives, identified a hidden constraint, saved the team from a poor decision, and may have repeatedly supplied scarce domain knowledge. That improves recognition as well as institutional learning.

Chapter 10 will fill a Knowledge Work Commit from this episode. Keep the side-by-side in mind when you get there. The schema is not abstract fields. It is a machine-readable version of the deliberation panel you just read.

What recognition requires

Invisible work is not only an epistemology problem. It is a recognition problem. Under document-only metrics, the person who spent two days preventing a bad centralisation looks less productive than the person who generated a long pack of inherited slides. Capturing deliberation does not automatically fix incentives. It makes the investigation legible enough that incentives can be fixed without relying on hallway reputation.

Institutionally, the same episode seeds reusable learning: do not propose shared-services hubs that assume an uncertified three-system join; put finance-calendar dependencies on the operating-model checklist. Those learnings are not in the Option B sentence. They are in the path that produced it. Chapter 10’s filled commit will carry them in reusable_learning and friction. The side-by-side is the human-readable proof that those fields are not optional colour.

Chapter 7 proved the invisible-work case: short artefact, long investigation. This chapter proves a different class of question — one that haunts every organisation with long-lived workbooks and recycled proposals.

Call it the inherited-content case. Content was carried forward from a prior period rather than originated in this session. The file is full. The delta is small. The rationale is almost never in the cells.

The workbook

Imagine a large spreadsheet: dozens of worksheets, years of history, formulas nobody wants to re-author. This week’s session changes one assumption table. Columns C and D are recalculated. Everything else is carried forward from last year’s report. Later, someone asks a normal question:

“What did we change in this week’s forecast workbook, and why?”

Search over the artefact

Document and workbook search will surface assumption-related sheets, historical tables, labels that look like forecasts, and a sea of numbers. Recall of “things that might be about assumptions” can be high. Precision on this session’s delta is low. Access to the legal-assumption rationale is near zero unless someone typed it into a cell comment — and even then, comments are unevenly used and poorly retrieved.

The search problem is not that the file is missing. The search problem is that the file is mostly inheritance. Semantic similarity over numbers and sheet names cannot reliably separate “existed already” from “changed this week because of a legal constraint.”

Search over the deliberation

The session often contains a sentence like:

This table is inherited from the 2024 report; only columns C and D were recalculated — and we recalculated them because the legal assumption is not approved.

That single sentence answers origin, scope of change, and cause. It is exactly the class of statement that behaves like a good commit message: a semantic compression of what mattered, before anyone re-reads the full diff of every cell. Software engineering already treats that split as basic hygiene: a diff shows what changed; only the commit message properly records why.²

A second inherited-content shape: the recycled proposal

Proposals are often assembled from previous proposals. Efficiency demands it. Epistemically it is a trap. Large sections of the file did not originate in this pursuit. A later reader — human or agent — searching the document for “what did we claim for this client this time” will retrieve polished prose that may be cargo from another context.

Deliberation tends to mark the boundary while the work is hot: which sections were reused, which numbers were refreshed, which recommendation is new, which risk paragraph was deleted because operations cannot support it. Those marks are meaning. The compiled proposal is presentation. Searching presentation for origin is the wrong substrate.

What this does not claim

Document search is not useless. Figures remain authoritative in the workbook. Prose remains authoritative in the proposal. Deliberation does not replace the artefact as the content object. Deliberation is the source map into the change. You keep the bronze of the numbers. Without the session, you throw away the source map of the change.

This is why “we already keep the documents” is an incomplete answer specifically for inheritance-boundary questions. You kept the mass. You discarded the sentence that said which part of the mass moved and why.

Bridge to commits

Software already solved a version of this with commit messages. A good commit is a semantic compression of a code change. It tells an agent where to look and what the change was meant to accomplish before the agent reads the full diff. Chapter 9 shows that AI coding agents not only write denser versions of those waypoints — they also read them back as the preferred path into history. Knowledge work needs the same waypoint class. Chapter 10 names it: the Knowledge Work Commit, with semantic_diff as the field that records meaning change rather than word change, and with explicit room for inheritance boundaries in rationale and inputs.

If you only run one pilot after reading this book, run an inherited-content trial on a real workbook or recycled proposal. Ask the same question over the file alone and over the session. Write down which answers only the second produced. That list is the business case in miniature.

Why agents need this class

As organisations ask agents to summarise “what changed this week,” the inherited-content failure becomes acute. An agent given only workbooks will narrate sheets. An agent given Knowledge Work Commits will narrate deltas and causes. The second is what management thinks it asked for. The first is what document-only estates can actually support.

The same holds for compliance and audit questions that sound simple: which parts of this policy pack were reconsidered after the legal change? Artefact search returns the pack. Deliberation search returns the sessions where legal assumptions flipped. Gold that only contains summaries of packs will go stale on exactly these questions. Gold that addresses bronze sessions can descend when the question requires fidelity. That is the layer economics already demonstrated in the near-present software case; inheritance is the knowledge-work question that forces the same architecture.

This chapter must not be thinned. It is the strongest concrete preview of Cognitive Git already running in the wild, and it has two paired halves. Claude Code is named directly because the claim is about observed behaviour of a real public coding-agent product, not a hypothetical assistant.

The AI writes better commit messages than you, then reads them instead of the code.

Write-side: one commit per coherent change

When an AI coding agent owns the commit step, three things tend to happen that human engineers often resist.

1. One commit per coherent change

The agent can stop at a natural boundary and record it. Humans batch. End-of-day blobs are common: half a dozen concerns, one message, a diff nobody wants to re-read. Coherent commits create a timeline of meaning, not a landfill of Thursday.

2. The request / change / test relationship is described

A good message states what was asked, what was altered, and how it was checked. Not “fixes.” Not “wip.” Not a ticket number with no verb. The relationship between request, change and tests is exactly the semantic compression later retrieval needs. It is also exactly the compression Chapter 8 wanted for workbooks and proposals. Industry practice has long codified that messages should carry human- and machine-readable intent — not free-form noise — so later tools and teammates can consume the history.³ Public Claude Code guidance itself treats a descriptive commit as a normal close of the explore–plan–implement loop, not an optional nicety.⁴

3. No resentment of documentation

Humans experience commit hygiene as tax. Documentation is resented because it feels like a second job after the “real” work. The agent does not resent it. It will put more care into the message than a tired engineer who believes the code already explains itself. The code does not explain itself. The code explains the final state. The message is the why and the scope.

AI produces more of those semantic waypoints because it can write a commit after each coherent change, does not treat the note as emotional labour, and can describe relationships a human would skip under time pressure. That is the write half of the loop.

Read-side: git log as the shortcut past the full diff

The second half is the half people miss when they only praise “better commit messages.”

Later, when you ask what happened — “what did we change last week?” or “have we touched this area before?” — the same class of agent often uses the commit history as the shortcut. It does not always dive straight into the full diff or re-read every file. It reads the commit comments. Git is involved; the full code is not necessarily the first surface of attention. The semantic layer the agent wrote becomes the index the agent consults. That is how the tooling was designed to be used: git log and related history commands exist so collaborators navigate meaning through messages before drowning in patches.⁵ Beams’ classic argument is the same loop in human terms: a well-cared-for log is what makes history usable; an unstructured mess is what makes people stop reading it.²

That is not laziness. That is correct use of a source map. Chapter 2 called transcripts source maps. Commit messages are source maps at a coarser grain: dense enough to navigate, cheap enough to scan, pointing into bronze diffs when detail is required.

Self-densifying semantic layer

The paired halves matter together. The same actor writes and consumes the waypoints. That is the self-densifying property. Software teams using coding agents are already living inside a preview of Cognitive Git: denser semantic exhaust produced as a natural by-product of doing the work, then reused as the primary path into “what happened.”

Human teams can produce good commit culture. Some do. The observation is that AI makes dense, non-resentful waypoint production the default rather than a pedantic exception. Then AI makes consumption of those waypoints the default retrieval strategy. Write and read reinforce each other.

What knowledge work should copy

Knowledge work does not need to pretend Excel is Git. It needs the same loop shape:

• emit a semantic waypoint after each coherent unit of AI-assisted work
• describe intent, change of meaning, rationale, rejects and checks
• keep the authoritative artefact as bronze content
• later answer historical questions from the waypoints first

Chapter 10 specifies that waypoint as the Knowledge Work Commit. Chapter 11 requires every approved AI surface to emit it. Without the write half, there is nothing dense to read. Without the read half, the write half is unused archive. Claude Code already demonstrates both halves on code. The corporate opportunity is to stop treating that as a developer quirk and start treating it as the pattern for meaning retention.

If someone tells you the git analogy is “just a metaphor,” point them at the read-side. Metaphors do not change how agents retrieve history. Observed tool behaviour does. The agent writes better messages than a resentful human, then prefers those messages to the raw diff. That is the whole argument in one product habit.

Why the paired halves are load-bearing

Write-side alone would be “AI writes nicer notes.” Useful, not transformative. Read-side alone would be “AI prefers summaries.” Also familiar. Together they show a closed loop: production of semantic waypoints becomes the substrate of later cognition by the same class of actor. That is why this is a preview of Cognitive Git rather than a commit-message style tip.

Organisations that try to mandate better human commit hygiene often fail because resentment returns under deadline pressure. Organisations that route substantial AI-assisted work through agents that already emit and consume waypoints are not fighting psychology in the same way. The corporate move is to require the equivalent emission on non-coding surfaces so knowledge work gets the loop software is already rehearsing. Claude Code is the public specimen of the behaviour. The Knowledge Work Commit is the portable schema.

Every substantial AI-assisted work session should emit a structured Knowledge Work Commit. That sentence is the primary artefact of this book. If you implement nothing else, implement this. The kinship with software history is deliberate: commit conventions exist so a change carries an explicit, structured account of intent that later tools can consume — not only a raw diff of files.³

The Word file remains the authoritative artefact for its prose. The spreadsheet remains authoritative for its figures. The Knowledge Work Commit becomes the semantic route into them — gold that explains where and why, while bronze proves exactly what happened.

Field schema (definitive)

Read every row. If a field feels optional, ask which proof chapter it serves. alternatives is Chapter 6 and 7. semantic_diff and inheritance are Chapter 8. friction is the organisational OS signal. outcome is Chapter 4 status discipline. None of these are decorative.

Filled example: the Option B episode

A reader could implement this next week as JSON or YAML at session end, as a form the agent fills before close, or as the header of a distilled session brief after a deterministic strip of tool chatter.

How it sits above bronze

The commit is not a replacement for the raw session. Raw AI sessions remain bronze: detailed, first-person, high-fidelity, noisy. The institution’s semantic record is the governed layer above.

Most sessions remain project history. Some reusable_learning values deserve promotion after human review — recurring constraints, anti-patterns, checklist items. Learning extraction as a ritual already exists in software-team doctrine; the commit field makes the nomination machine-checkable rather than a forgotten Definition-of-Done checkbox.

What not to do with the schema

• Do not paste the full transcript into every field.
• Do not treat the commit as a second board paper.
• Do not skip outcome status — that is how drafted becomes falsely “decided.”
• Do not wait for perfect version-level artefact linking before emitting commits. Capture first; join is a forthcoming problem, not a reason to keep discarding reasoning.

Chapter 11 turns this schema into an organisational contract: every approved surface emits the same work event, even when UIs differ.

Implementation shapes that count as done

Three shapes all satisfy the contract if the fields are real:

1. Session-end JSON/YAML emitted by the agent into a company store with session id and timestamps.
2. Form completion before the surface allows “done,” with the model drafting and the human confirming rejects and uncertainty.
3. Distilled brief header after deterministic strip of tool chatter, with the raw session retained as bronze and the header indexed for search.

What does not count: a free-text “summary of chat” with no alternatives field; a managerial rewrite three days later; a full transcript dump labelled as a commit. The filled Option B example above is the quality bar. If your pilot commits cannot answer the Chapter 7 question table, the emission is theatre.

Enterprises waste years trying to standardise tools by look and feel. That is the wrong contract for this problem. Knowledge workers will use corporate chat, office assistants, departmental agents, coding tools, document-review agents and meeting assistants. Those surfaces will keep differing. The one thing they must share is what they emit when substantial work happens.

Not a common UI — a common work-event emission.

What must emit

Any approved surface that can change organisational meaning should emit a Knowledge Work Commit (Chapter 10) at the end of a substantial session. Substantial means: artefacts were created or materially changed, a decision path was advanced, or investigation produced rejects and constraints worth keeping even when the visible output is short.

That last clause matters. The invisible-work episode in Chapter 7 is substantial even when the published residue is one paragraph. If emission only fires when a long document is saved, you re-encode the same failure mode this book attacks: investigation without a large file never becomes organisational memory. The trigger is meaning change and decision work, not page count.

Conversely, not every chat token deserves a commit. Asking the assistant to rephrase an email subject is not a Knowledge Work Commit. The practical rule of thumb is the same as a good software commit boundary: if a later person would need the intent, the rejects, the inheritance line or the open uncertainty, emit. If the session was pure formatting with no judgment, skip. Err toward emission when unsure — bronze is cheap; missing reasoning is not.

Named generically — not as product claims — the catalogue includes:

• a corporate chat and research tool
• office and document assistants
• custom departmental agents
• coding tools
• document-review agents
• meeting and email assistants

Company-owned gateways matter because retail accounts and unjoined private logs are how deliberation leaves the building. The doctrine does not require one mega-app. It requires that approved paths emit the same structured event shape. That impulse matches how observability standards treat generative-AI work: shared semantic conventions for spans and events so heterogeneous agent surfaces can be compared and joined, rather than each tool inventing a private log dialect.⁶

Failure modes without the contract

What the emission event must contain (without re-deriving Chapter 10)

Chapter 10 owns the field list. Here the contract question is different: which fields are non-negotiable for interop across surfaces? At minimum, every emitter must populate:

• intent and context — otherwise commits cannot be filtered by workstream
• artefacts_affected — even if version join is imperfect, a human-readable pointer must exist
• semantic_diff and rationale — the reason emission exists at all
• alternatives and uncertainty — the invisible things finished files erase
• outcome — status discipline so drafted never masquerades as approved

friction and reusable_learning can start sparse and improve with facilitation. They should not be deleted from the schema to make early pilots look clean. Empty is honest; absent is a contract hole. A coding tool and a board-pack assistant can differ in UI forever, as long as both can serialise those fields into the same organisational store.

Bronze sessions, distilled headers

Emission of a commit does not mean discard the raw session. Raw conversations, tool calls, input pointers, output pointers and artefact versions are retained as source. Not everything is placed into the active wiki. The raw session is the episodic staging buffer; the institution’s semantic record is the governed layer above it.

Distillation is the practical bridge. A deterministic pass can strip repetitive tool chatter and oversized payloads. A model can then draft the Knowledge Work Commit fields from the cleaned session, with a human confirming rejects and uncertainty when stakes are high. The commit becomes the searchable header; the raw session remains the bronze you open when the header is not enough. That is the same two-stage instinct software teams use when they keep full diffs but navigate through commit messages first.

Keep the bronze. Deletion is the irreversible operation. You can always build better maps later over territory that still exists.

Where commits join

The session should not float alone. It joins the relevant project, client, process, decision, product, workstream, policy, team, artefacts and prior discussions. That creates an Engagement World for ongoing work: the persistent account of what the group has learned, proposed, rejected, built and verified so far.

Different actors can contribute from different surfaces without remembering every other conversation.

How a session is linked to a specific artefact version — document version, sheet range, commit path, ticket event — is a real engineering problem. A forthcoming companion owns that deliberation–artefact join. This book owns why emission is worth requiring even before the join is perfect. Capture the commit. Keep the bronze. Improve the join next.

Privacy, noted not designed

Privacy, consent and employment-law mechanics matter. They exist. Used unfairly, capture becomes surveillance. Used well, the framing is mine for friction, not guilt: where capable people hit operating-system problems. Designing the HR regime is outside this brief. Pretending the regime is unnecessary would be dishonest. Specifying source-relativity does not require specifying the entire governance stack in one book.

The window to specify emission before surfaces proliferate is open now and closing. Chapter 12 names the whole stack as Cognitive Git without turning the management aggregate into a product design exercise.

Minimum viable contract text

You can put a one-page contract in front of platform owners without waiting for perfect architecture:

• Every approved AI surface used for substantial work SHALL emit a Knowledge Work Commit using the Chapter 10 fields.
• Raw session content SHALL be retained as bronze under company control for a defined retention window.
• Commits SHALL be searchable independently of document libraries.
• Promotion of reusable_learning into team or firm canon SHALL require a human gate.
• Version-level artefact linking SHOULD improve over time; absence of perfect join SHALL NOT block emission.

That is enough to stop the retail-evaporation failure mode while companions land join and management aggregate design. Waiting for a unified mega-platform is how emission never starts.

How to know the contract is working

Do not measure success as “number of chats stored.” Measure whether a stranger to the session can answer, from commits alone: what was intended, what meaning changed, what was rejected, what remains open, and which artefacts were touched. If those answers require re-reading every transcript, you have logging, not emission. If they are available in the structured fields and the bronze is only opened for disputes or deep audit, the contract is doing its job.

A second test: can two different approved surfaces — say a coding agent and a document assistant — both land commits that the same search path can rank for “why did the forecast change?” If only one surface emits, you have a silo with better manners. If both emit the Chapter 10 shape, you have begun Cognitive Git even before the perfect join resolver exists.

The full concept is larger than “archive corporate AI chats.” Archive is storage. What organisations need is a meaning-retention stack with the same clarity software took decades to earn around source control.

The mapping

Read every row as job assignment, not as a vendor diagram. The system of record tells you what exists. The AI deliberation tells you why it exists. The Engagement World tells you what the team currently understands. The institutional wiki tells the next worker or agent what the organisation has durably learned.

Walk one question through the stack

Take the project-manager question from earlier in the book: why is an integration delay still open? Under Cognitive Git the answer is assembled without collapsing statuses:

• Bronze sessions hold the AI conversation where the constraint was discovered and the rejected first approach was named.
• Knowledge Work Commits compress that episode into intent, semantic diff, alternatives and outcome=deferred.
• Artefacts show the current ticket text and the draft design note — what was written for the audience, not the full graveyard of options.
• Engagement World keeps the open dependency owned by another team visible as project state, not as a forgotten chat.
• Institutional memory may already hold a reusable rule (“do not assume three systems join without a safety gate”) if prior episodes promoted it.

If you only have the ticket, you see a green-or-red status without causes. If you only have the chat dump, you drown. The stack is what makes the question answerable at the right grain. That is the practical meaning of Cognitive Git: not a logo on a landing page, but a way to route each question to the layer that can truthfully answer it.

Gold addresses; bronze proves

A semantic layer earns its keep by addressing reality rather than trying to contain volatile detail. Gold tells the agent where truth lives; bronze tells it what happened. A worked near-present case of that discipline — descending from IP and project maps into yesterday’s development deliberation — already exists as a sibling piece. Use it as existence proof that deliberation-as-source is operational, not speculative architecture.

Soft data as causal feedstock

Traditional systems see outcomes: tickets closed, documents published, milestones green. The soft layer holds the causal explanation — objections, trade-offs, workarounds.

AI conversations make that causal layer more structured at birth. People state intent, compare alternatives, mark uncertainty and name what failed. You are no longer only mining historical exhaust. You are creating an environment where high-quality semantic exhaust is produced continuously as a by-product of doing the work — the same self-densifying loop Chapter 9 showed on the write and read sides of git.

The pre-structuring is easy to miss if you only think about chatbots answering questions. In a working session the model presses the human for distinctions: what are you trying to achieve; which of these three; what failed; what is still open; what must land before Thursday. Those prompts are not decoration. They are how soft data becomes born structured enough to emit. The Knowledge Work Commit is simply the organisational envelope around sentences that already appear in good sessions.

What a senior manager’s weekly compiled view should look like as a product is a forthcoming companion’s job. The content.md framing for that view — what moved, where the organisation is sticking, where management can help, what was learned — is real and valuable. This book still does not design that product. The stack argument does not depend on that product existing first. It depends on not discarding the feedstock that any honest weekly view would need.

Mine for friction, not guilt

If any management use appears, the framing is load-bearing:

Mine for friction, not guilt.

The question is not who is slow. The question is where capable people repeatedly encounter an operating-system problem: abnormal cognitive effort for routine tasks, the same specialists pulled into every issue, reopened decisions, work waiting for authority rather than execution. Default responses should be help, clarity, resources, redesign, reusable knowledge — not a scoreboard. That keeps the monitoring legitimate because employees receive a benefit from being seen.

The friction field on the Knowledge Work Commit is the micro-capture that makes that macro framing possible later. Without it, any aggregate view will invent effort proxies from ticket counts and meeting volume. With it, the organisation can see patterns like “three teams rediscovered the same undocumented dependency this month” without reading every transcript. That is still not a guilt dashboard. It is an operating-system diagnosis feed. Design of the dashboard is out of scope; refusal to capture the field is how the organisation stays blind on purpose.

Role-shaped views without rival histories

Different actors can receive different operative rooms over the same evidence without creating rival project histories. A project manager, analyst, architect, executive and auditor do not need the same context dump. They need intent-shaped compilations that preserve origin and authority.

That is checkout discipline, not surveillance. Cognitive Git fails if every role receives the whole graph as a slurry. It succeeds if commits and bronze remain legible and each act compiles the room it needs.

The deeper corporate opportunity is not capturing more documents. It is capturing the meaning-making process that produced them.

Chapter 13 states the boundaries hard. Chapter 14 turns the stack into Monday actions. The metaphor is only useful if the emission contract ships.

What closes when the stack works

Previously the most valuable part of knowledge work — the actual process of understanding — mostly vanished between a person’s head and the finished artefact. AI makes that thinking more explicit. The architecture makes it retainable, searchable, joinable and promotable. The system of record tells you what exists. Deliberation tells you why. The Engagement World tells you what the team currently understands. Institutional memory tells the next person what is durable.

None of that requires calling people “resources” or building a guilt dashboard. It requires treating meaning-making as an asset class with stages, waypoints and bronze. Cognitive Git is a name for that treatment. The emission contract is the mechanism. The proofs in Part II are why the mechanism is not optional polish.

Self-densifying again, at enterprise scale

Chapter 9’s Claude Code loop was software-local: write better commits, then read them. Cognitive Git is that loop scaled to every approved surface. Agents and people both consume Knowledge Work Commits when asking what moved. Promotion merges durable learning into institutional memory. The next session starts less cold because gold addresses yesterday’s bronze. The organisation stops paying full price to rediscover the same reject every quarter.

That compounding only starts if emission is real. Metaphor without commits is a slide. Commits without a read habit are a graveyard. Read habit without bronze is brittle when the header is wrong. The stack is the discipline that keeps those failure modes from swapping places every year under a new tool name.

Doctrine stays liftable when it does not swallow neighbouring problems for completeness theatre. This chapter is the kill list made explicit.

Readers who have stayed with the book this far will feel the temptation to ask for the whole system in one volume: the version join, the manager dashboard, the privacy policy, the HR scorecard, the measured commit-density study. Each of those is a real problem. None of them is this problem. Absorbing them here would make the source-relativity argument un-reusable later and would force invented detail where the brief deliberately stopped.

Owned here

• Source-relativity generalised from software to knowledge work
• The Deliberation Is Source; document is what / deliberation is why
• Least semantically useful view of the finished document
• Six-layer stage distinctions and status discipline
• Invisible-work side-by-side proof
• Inherited-content search proof
• Claude Code write/read commit loop at full weight (observation, not measured density %)
• Knowledge Work Commit schema with filled example
• Common emission contract
• Cognitive Git framing as stack, not product UI

Not owned here

Why the join is a separate book

Knowing that deliberation is source does not answer how a session attaches to workbook version 17, sheet Assumptions, columns C–D, or to a specific PowerPoint slide id. That attachment problem has its own resolver doctrine, evidence tiers and foreign-key realities. Smuggling a half-designed join into this volume would create false confidence: readers would think capture is useless until join is perfect. The opposite is true. Emission creates the events a join can later bind. Without emission, the join has nothing honest to attach.

Why the management product is a separate book

The senior-manager weekly view sketched in the source conversation — what moved, where people are sticking, where help would unstick work, what was learned — is a product thesis of its own. Building it requires aggregation policy, role-shaped views, anti-gaming design and explicit “mine for friction, not guilt” product rules. This book supplies the feedstock argument and the framing. It does not ship a dashboard wireframe or a scoring model. If you need the dashboard before you will emit commits, you will wait forever and keep throwing reasoning away in the meantime.

Live siblings (safe to link)

These are live and may be linked in the exact form below. Do not invent slugs.

• 182 — Route-Invariant Grounding
• 183 — Wiki Redundancy Is Error Correction
• 184 — The Novelty-Preserving Carve-Out
• 185 — Inbound Edges Are a Different Question
• 186 — Derivational Provenance
• 187 — Gold Addresses Reality (primary worked pointer for gold→bronze deliberation)
• 188 — Your AI Partner Is the Challenger

Never self-link this piece as 189 in its own body. Never emit URLs for unpublished companions on the join, the management aggregate, or later sequence numbers.

What we are not saying

• Documents are worthless
• Delete the document library
• Spy on staff
• Software maps one-to-one onto knowledge work without generalisation
• Emission without privacy thoughtfulness
• A measured claim where only an observation exists

Privacy and trustworthy-use concerns are not optional decoration around capture. NIST’s AI Risk Management Framework treats privacy and governance as first-class risk categories alongside technical capability — which is why this book notes those considerations exist while refusing to fake a complete HR regime inside a source-relativity brief.⁷ Multi-agent production systems similarly surface coordination, evaluation and reliability as design problems that expand once many actors write state — another reason join architecture and management aggregate products belong in companions rather than being smuggled into this emission argument.⁸

Named office and collaboration tools appear only as generic work surfaces. Claude Code is the one load-bearing named product case study, and only for the commit write/read behaviour claim. No employer or client organisation is named.

Chapter 14 is installation. Boundaries without a checklist are a scholar’s comfort. A checklist without boundaries is a strategy deck that absorbs the universe. Keep both.

Reuse allowance, stated cleanly

This book may lean on The Prompt Is Source and its stage-relative source rule, and on Code What, Transcript Why’s three invisible things, without re-deriving those books. It must build past them into knowledge-work emission and proofs. Readers who need the software-only depth should read those parents. Readers who need gold/bronze near-present descent should read Gold Addresses Reality. Readers who need challenger/arbiter governance in co-design should read the challenger piece. This book’s job is the corporate source-relativity axis and the Knowledge Work Commit.

Honesty on the Claude Code density claim

Chapter 9 is load-bearing and must not be thinned. It is also carefully labelled. The claim that Claude Code commits more often, with better messages, and then reads those messages as a shortcut is a practitioner observation from sustained use. It is not a controlled repository study with a percentage gap between AI-authored and human-authored commit density. If a later study measures that gap, it will strengthen the case. Until then, the honest form of the argument is behavioural and public-product: the write/read loop is documented in product guidance as a normal close of work, and observed in use as a self-densifying habit. Fabricating a density number would violate the same integrity rule this series applies to every other figure.

How to use the kill list when writing downstream

If you are implementing from this book, the kill list is operational, not literary. Do not block emission on join perfection. Do not delay pilots until the management product is specified. Do not use capture as an individual scorecard while calling it Cognitive Git. Do not re-argue route invariance or novelty carve-outs here when those siblings already own the measurement stories. Do not cite unpublished companions with invented URLs. Boundary discipline is how a full-size corporate book stays a liftable framework instead of a kitchen-sink strategy pack.

You do not need a transformation programme to test this book. You need one approved AI surface, the Chapter 10 schema, bronze retention, and two proofs run on real work: invisible work and inherited content.

Installation is also where depth either becomes real or evaporates into slogans. The proofs in Part II are not illustrations to admire; they are templates for the first week. If your pilot cannot produce a side-by-side like Chapter 7 and an inheritance query like Chapter 8, you have not installed the doctrine. You have installed a logging feature.

The checklist

1. Stop treating the document library as the whole knowledge base. It is the object store for published state. Meaning lives one compiler stage earlier. Restate Chapter 1 to your team in one sentence before you change tooling.
2. Pick one approved AI surface — not ten. Require a Knowledge Work Commit at the end of every substantial session on that surface. Use the eleven fields from Chapter 10 without inventing a parallel vocabulary.
3. Keep raw sessions as bronze. Distil for search. Do not delete the source map because the brief is prettier. Deletion is irreversible.
4. Run one inherited-content trial. Take a workbook or proposal that is mostly reuse. Ask “what did we change and why?” over the file alone, then over the session. Record which questions only the second answered. That record is your local business case.
5. Run one invisible-work trial. Find a short recommendation that cost days. Side-by-side the artefact and the deliberation using Chapter 7’s question table. Ask who would have looked lazy under document-only retention.
6. Fill one Knowledge Work Commit completely. Use the Option B example as a template, not as fiction. Replace fields with a real episode. If a field is empty because the session never surfaced the fact, note the gap — that is a facilitation problem, not a schema problem. Walk the fields in order and ask, for each: would a stranger to the session understand this without the transcript? If not, rewrite the field until the answer is yes.
7. Install a read habit, not only a write habit. Chapter 9’s second half is not optional colour. Once commits exist, start one recurring question from commits first: what moved on this workstream, and why? Open artefacts only after the semantic route. If nobody ever reads commits, emission will rot into compliance theatre the way human commit culture rots when nobody uses git log.
8. Do not wait for perfect version-level join architecture. Emit commits now. Linking conversation to exact artefact versions is a forthcoming companion problem. It is not a reason to keep throwing reasoning away.
9. If any management view appears, mine for friction, not guilt. Default to help, clarity, resources and redesign. The aggregate product design is not this book’s deliverable; the framing is non-negotiable if capture is to stay legitimate.
10. Schedule a human promotion review for reusable_learning nominations. Most sessions stay project history. A few constraints and anti-patterns deserve team or firm canon. Promotion is a merge with a gate, not an automatic wiki write.

Acceptance tests

How to run the two required trials (full procedure)

Inherited-content trial

1. Pick a real workbook or proposal that is mostly reuse from a prior period.
2. Without looking at the session, try to answer: what changed this week, and why?
3. Write down every place the artefact search fails or returns ambiguous mass.
4. Open the AI session (or Knowledge Work Commit if already emitted) and answer the same question.
5. List questions only the second path answered. That list is the business case artefact for sceptical stakeholders.

Invisible-work trial

1. Find a short recommendation or decision sentence that cost real investigation time.
2. Paste the artefact text into the left column of Chapter 7’s question table.
3. Fill the deliberation column from the session: rejects, hidden constraints, residual uncertainty, help needed.
4. Score each row: artefact alone, deliberation, or both.
5. Ask who would have looked lazy under document-only retention. Write the answer down; it is the recognition case.

What success feels like

Success is not a larger document archive. Success is a second index into work: the semantic route. Agents and people start preferring commits for historical meaning the way coding agents prefer commit messages for “what did we do.” Invisible investigation becomes legible. Inherited mass stops pretending to be this week’s originality. Friction becomes organisational signal instead of private struggle.

Success also feels quieter than a transformation launch. A second person can resume a workstream without a twenty-minute hallway download. A specialist is not re-explaining the same constraint for the fourth time. A manager sees a sticking pattern across teams without reading private diaries. Those are small operational wins that compound. They are the enterprise version of a useful git log.

Failure modes to watch: capturing chats without schema; schema without bronze; bronze without any read path; read path used as individual scoring; waiting for the join companion before emitting anything; emitting only when long documents are saved (which misses invisible work); treating empty alternatives as normal forever instead of a facilitation gap to fix.

Close

The final document may be the least semantically useful view of the work.

The document is the what. The deliberation is the why.

The deeper corporate opportunity is not capturing more documents. It is capturing the meaning-making process that produced them.

Keep the results. Keep the reasoning. Emit the commit. The deliberation is source.

First-week schedule

Day 1: Choose the surface; paste the Chapter 10 fields into the emission path; confirm bronze retention is on.

Day 2–3: Run normal work; force a commit on every substantial session; fix empty alternatives and outcome fields in review.

Day 4: Inherited-content trial on a real workbook or recycled proposal; write the only-deliberation-answered list.

Day 5: Invisible-work trial; fill one commit to Option B completeness; show both trials to a sceptical peer.

If day five ends with commits nobody reads, you have storage. Schedule a read-path habit: start weekly “what moved” questions from commits first, artefacts second. That is how the Claude Code read-side half begins to appear in knowledge work.

After the first week

Expand to a second surface only after the first surface passes the acceptance tests. Keep the schema identical. Resist the urge to invent surface-specific field names. When reusable_learning nominations accumulate, run a short human promotion review: promote constraints and anti-patterns that repeated, leave one-off colour in project history. When someone asks for the manager dashboard, hand them the feedstock you now have and point to the forthcoming product problem — do not stop emission while waiting for it.

When someone asks for perfect version linking before they will capture, restate Chapter 13: emission first; join next. When someone asks for a density percentage proving AI commits better than humans, restate Chapter 9’s honesty label and keep the behavioural case. When someone wants to score individuals from friction fields, stop and redesign the use case before the pilot destroys trust.