The story would not finish.

It was a clear, quiet space.

That is where the exercise from Monday actually runs, and it looks nothing like getting ready for a meeting. It looks like somebody trying to write something true.

I had all of it out on the desk. The articles, the notes, the details, the spreadsheets, the wikis, the policies, the standards. Years of a program describing itself, all of it produced by people who knew their own material cold and had every reason in the world to get the details right. Nothing in that pile was wrong.

The job I set myself was to construct sentences that pull it all together. Not slides. Sentences, because a sentence commits to something a bullet never has to. Two bullets can sit next to each other and imply a relationship without ever stating one, and everybody in the room fills in the connection privately, and everybody fills it in slightly differently. A sentence has to say the relationship out loud. If the relationship is not there, the sentence will not close.

It went well for a while.

Then I reached the place where the story stopped. I was writing the line that carries a reader from one part of the program into the next, and it would not finish. I went back into the source material, came back, tried the sentence again, and it still would not close. At some point I stopped blaming the writing.

Plot gaps. That's what those are. You are telling a story, the story has a shape, and there is a place where the shape breaks and no amount of craft repairs it, because the break is not in the telling.

Here is the part that took a while to absorb. Every document involved was complete. The person who owns that part of the program wrote each one, and owners write their own part thoroughly, because they know it and they care about it and their name is on it.

What nobody writes is the seam between two parts. Nobody owns the seam. It does not appear on an org chart, it has no artifact, and it has never failed an audit, because there is nothing there to audit.

I went into that week thinking the writing was the deliverable, the thing I would work from once the questions started. It was not. The writing was the instrument. The deliverable was the list of places it broke, and I did not understand that until the week was nearly over.

A plot gap is a break in a program's narrative that no single artifact can reveal. Every artifact passes on its own. The gap only exists in the relationship between two of them, which means it is invisible to any process that examines them one at a time.

That is most of our processes. An audit walks a control list and tests each control against its evidence, and a maturity model puts each capability in its own row and rates the row. Both produce findings, and findings are local by construction. A plot gap is not local, so neither one will ever hand you one.

There is a reason this is hard, and it has nothing to do with being bad at writing. Most practitioners do not know the outline. The craft and the responsibility run so broad and so far that no one person carries the whole fabric in their head, so you own your part completely, you can describe the two parts touching yours, and past that you are working from an org chart and good faith.

Then comes the translation problem. You take all of it and put it into words that resonate with skilled leaders from very diverse backgrounds, people who do not share your vocabulary and who are each expert in a domain you have never touched. That is why this matters, and it is exactly where it struggles.

The owner of one part wrote every document you have, and every one of them is complete. The story is the only thing that has to cross between them.

You can watch this pattern operate in a place that has nothing to do with governance. Hand your documentation to an analyst in their first month and listen to the questions they ask. They will not ask you what a control does, because the document says what it does. They ask what happens between two things, and they ask it constantly, and they are the only people in the building who ask it out loud.

Then at some point they stop. They did not get answers. They learned the shape of the organization, and the shape includes knowing which questions have no owner and therefore no answer worth chasing.

New people find plot gaps for free. Most programs get a short window of that per hire and spend it on onboarding logistics.

The same thing shows up in the maturity spreadsheet, which is where most of us keep our completeness story. Every row is a capability, every capability gets a score, and the sheet totals. There is no column for the seam between two rows. A spreadsheet cannot hold a seam that belongs to neither of the things it connects, so the sheet reports a maturity percentage and says nothing at all about whether the percentage connects.

Most teams treat completeness as arithmetic. Enumerate the risks, map controls to them, score each control, report the percentage. It is a defensible method and it has real virtues. The work divides cleanly across a team, you hand each piece to whoever owns that area, progress is measurable week over week, and the output is a number that a person outside security can hold in their head.

The arithmetic version is also easier to maintain, which matters more than anybody admits. A narrative goes stale the moment one system changes, and rewriting it is a whole afternoon. A spreadsheet row gets updated in forty seconds. Given a busy quarter, the spreadsheet wins every single time, and it wins for reasons that are not laziness.

Nothing has ever tested the arithmetic version. That is its real appeal.

Nobody asks you to narrate your program end to end. They ask about the number, or about last quarter's incident, and the arithmetic answers both beautifully. A method nothing ever stresses feels sound indefinitely. It feels sound right up until an incident makes somebody trace an actual sequence through your program, at which point the seams announce themselves in front of an audience.

Getting it right looks smaller than you would expect. Fewer artifacts, one continuous account, and a short list of named seams that you can talk about without flinching. What works is smaller than more documentation. Somebody sits down and tries to say the whole thing in order.

So run it that way. Clear the space, put everything the program has ever written about itself in front of you, and write one continuous account from risk through to the practitioner who acts. Do not build slides. Slides let you skip, and skipping is the failure mode you are trying to detect. Mark every place the sentence will not finish, and keep going rather than stopping to repair it, because the list is the point.

Saying it out loud is the piece I cannot fully explain, and it is the piece that does the most work. Practicing for a talk works the same way. You can read a paragraph on the page until you nearly have it memorized and it holds together fine, then you say it in your own voice and you hear the missing piece immediately. Something about claiming a thing out loud runs a check that silent reading does not run. Your ear catches the seam your eye skipped.

So read the account aloud, all of it, and listen for the place where your voice does the thing it does when you are covering for a part you would rather not examine. That is where the dark corners are. They are yours, which is the irony sitting underneath this whole exercise. You went looking for a way to defend the program. What you found was your own missing pieces.

Then notice where the marks cluster. My guess is that they land at handoffs, and if that holds it changes what you do next. A gap inside somebody's area is that person's work and they usually already know about it. A gap at a handoff belongs to nobody, and naming an owner for it is a different conversation than naming an owner for a system, because no job description mentions the seam and the two people on either side both reasonably believe the other one covers it.

Your ownership map changes shape after that, and nobody warns you about it. You stop maintaining a list of systems and their owners and start maintaining a list of seams and their owners, which is a smaller list and a more useful one. Almost none of that work involves buying anything, which is the part that makes it hard to fund and easy to postpone.

The pull to fix the writing instead of the program is the thing to watch for here. You will find a sentence that almost works, and you will find a phrasing that gets you past it, and that phrasing will be true enough to survive a meeting. Resist that, or at minimum write the phrasing down in a separate list titled what I would have said, so you can see how long that list gets.

Volume is the other problem. The exercise finds more than one cycle can fix. You then have to decide which gaps you carry on purpose, and carrying a gap on purpose is a completely different position than carrying one by accident. The first you can defend anywhere. The second one defends itself right up until it does not.

When a gap resists you, take it to the two practitioners on either side of it and ask each of them to tell you what happens. Sometimes they tell you the same story and it turns out the handoff has worked fine for as long as either of them can remember and nobody wrote it down. That is a documentation fix and it is the good outcome. When they tell you two different stories, you have found the real thing, and you found it in a quiet week in August instead of on an incident bridge in November.

When was the last time anybody said their entire fabric out loud?

If you can't tell the entire story, those plot gaps are real.