Last time, the match lines drifted because the alignment moved. The seam slid down the corridor and the match line stayed where it was. This time the geometry doesn't move at all, and the match lines break anyway.
That's the part that surprises people. You'd think a match line is safe as long as nobody touches the design. But a match line doesn't only depend on where the seam is. It depends on what sheet it points to, and the sheet it points to can change without a single line of geometry moving. All it takes is for the scope to shift, and on a real project the scope shifts constantly.
Before that, one thing worth being clear about. The native match line object only exists along an alignment, but the see sheet marker it stands in for belongs on every tiled plan in the set. The site, utility, and grading plans that aren't driven by an alignment still get tiled, still have seams, and still need a label telling the reader where they continue. On those the tool gives you nothing, so the labels are drawn and typed by hand. Only the details and the sections, which stand alone, are exempt. That matters here, because the renumber doesn't break one plan series. It breaks every tiled drawing at once, the alignment-driven labels with their stored sheet numbers and the hand-typed ones alike, each with its own chain of see sheet references that has to be walked separately.
What a renumber actually does
A reach gets value-engineered out and three tiles disappear from the north end. A connection gets added at the south and two tiles appear. A reviewer wants the grading plans split onto their own sheets. None of this moves the alignment an inch. But the sheet count changed, and the moment the count changes, the set has to renumber.
That renumber is where the match lines and the Sheet Set Manager collide. A match line label doesn't say continued on the next frame. It says see sheet 12. And that 12 is a stored value, the number that lived on the view frame or got typed into a hand-drawn label, right only because of where sheet 12 happened to land in the set. And a set is never a clean march of plan tiles. It's plan tiles interleaved with single-viewport sheets, a key plan, a notes sheet, plan-and-profile sheets that count differently than the single-viewport plans around them. Insert one sheet near the front and every number downstream shifts by one. Every see sheet label that pointed past the insertion is now off by one. The Sheet Set Manager will happily renumber its own sheets, but it has no link to the match line labels out in the drawings; those stored numbers don't move when the SSM numbers do. Nothing about the geometry changed, and yet every cross-reference in the set is quietly wrong.
Why it's worse than the alignment case
When the alignment moves, the error is visible. The plan runs past the match line, the viewport frames the wrong extent, something on the sheet looks off, and a careful reviewer catches it.
The renumber leaves no visible trace. The sheets still look right. The plan still frames the geometry. The match line still sits exactly where it belongs on the page. It's only the number in the label that lies, and a number is the hardest thing in the world to proofread, because there's nothing visually wrong with it. See sheet 12 looks exactly as correct as see sheet 13. The only way to catch it is to walk the entire set in order, sheet by sheet, checking every label against the actual sheet it lands on. That's the afternoon nobody scheduled, and on the renumbers that happen late, it's the afternoon nobody has.
And because match lines live on every tiled drawing, the renumber doesn't touch one plan series. It touches the site plans and the utility plans and the grading plans all at once, each with its own chain of see sheet references, each of which has to be walked separately. One scope change, every tiled sheet in the set, every cross-reference suspect until proven otherwise.
The workarounds we've all built
The honest answer is most teams don't fix this so much as survive it.
Somebody keeps the renumber to the very end, refusing to assign real sheet numbers until the set is frozen, which works right up until the set is never actually frozen. Somebody maintains a master list mapping every match line label to its target sheet and updates it by hand after each change, which is a second set of bookkeeping nobody has time for. Somebody just doesn't put sheet numbers in the match line labels at all, leaving a generic see adjacent sheet, which is safe and useless, because the whole point of the label is to tell the contractor where to go.
Every one of these is a way of admitting the label and the sheet number are two separate things that have to be kept in agreement by hand, and that the agreement breaks every time the count changes.
The honest cost
The first numbering is cheap. The set gets built, the sheets get numbered, the labels get filled in, and on day one everything agrees.
Then the scope moves. Two tiles cut, one added, and the renumber walks an off-by-one through every label in the set. Not just the alignment plans, every tiled drawing. You go down the whole set, in order, reconciling each label against the sheet it now points to, checking the Sheet Set Manager properties against the title blocks, fixing the ones that drifted. A few hours, if nothing else changed at the same time. Usually something else changed at the same time.
Do that across three revision cycles, on a set with several tiled plan series, and the renumber reconciliation quietly becomes one of the larger line items in sheet production. It never appears in a proposal. It gets absorbed, or written off, or paid for after hours, like the rest of the cleanup.
What changes when the number is the number
The fix isn't a faster renumber. It's making the renumber stop cascading.
That's how SheetAgent for Civil 3D treats it. The see sheet label doesn't store a number that has to be re-checked after every change. It references the sheet itself, and the sheet's number is computed from where it actually sits in the set. Add a tile, drop a tile, slot a single-viewport sheet in ahead of the plan run, split the grading plans onto their own sheets, and the set renumbers as one operation. Every label reflows to the new numbers. The Sheet Set Manager properties move with them. The title blocks read off the same source. There's no off-by-one to hunt down, because the label and the sheet number were never two numbers that had to be kept in agreement. They're the same number, read in two places.
And because it's the same mechanism on every tiled drawing, the renumber is one operation across the whole set, not one operation per plan series repeated by hand. The site plans, the utility plans, the grading plans all reflow together. This is also the part the native tool simply can't reach: it only makes match lines along an alignment, so the non-alignment plans were never in the system to renumber in the first place. Here they are, treated like any other tiled sheet, reflowing with the rest. The scope change stops being a day of reconciliation and goes back to being what it actually was: a scope change.
Why this matters
The alignment case costs you a visible error you can usually catch. The renumber case costs you an invisible one you usually can't. It's the see sheet 12 that should have said 13, sitting on a sheet that looks perfect, issued for construction, found by a contractor in the field three weeks later. The hours to fix the renumber are real, but the worse cost is the cross-reference that slips through because there was nothing to see.
A set where the number is always the number is a set you can renumber without dread. The scope can move as many times as the project needs it to, and the labels just keep telling the truth. That's the difference between sheet production that fights every change and sheet production that absorbs it.
What's next
That's both halves of the match lines, the alignment trigger and the scope trigger. Next, the title blocks and the Sheet Set Manager in their own right, the field expressions we've all decided are too fragile to trust and why they break. After that, the key plans, and the project-wide picture across multiple files and multiple designers, which is the part almost nobody automates well.
If you've ever frozen a set just to stop the numbers from moving, you already know why this one needed its own post.
See it on your own project at setline.ai.