On a large project, every discipline has to agree on where the sheets are.
Existing conditions, demolition, layout, grading, drainage, utilities. Each is its own set of plans, and every one of them has to be tiled the same way. The grading sheet ending in 04 has to cover the same ground as the drainage sheet ending in 04. If they don't line up, the set stops making sense: a reviewer flipping from one discipline to another at the same suffix is suddenly looking at a different part of the project, and the key plan can't describe both.
So the tiles have to be shared. And Civil 3D has no idea that's a thing you need.
What we all do instead
Everyone solves this the same way, which is how you know it's a real gap.
You work out how much ground each sheet has to cover. You draw those rectangles in model space. You build one discipline first, usually the busiest one, and you look at it. If the tiling reads well, if the sheets break in sensible places, you keep it. Then you take those rectangles, put them in their own drawing, and XREF that drawing into every other discipline. Now every discipline can see the same tiles, and everyone builds their viewports against them.
It works. It's the right instinct, honestly, because it puts the tiling in one place. But it's held together by hand, and it only holds as long as nothing changes.
Then something changes
The project moves. Or the tiling just isn't right: one sheet is too crowded and needs to be smaller, another is mostly empty and should be bigger. A reach gets added at the north end and the whole run needs re-tiling.
Now you go change the rectangles. And then you go do the work again in every discipline, one at a time. Grading, drainage, utilities, layout, each one opened, each one's viewports reframed to the new tiles, each one checked. The change was one decision. The execution is the same manual task repeated as many times as you have disciplines.
And it doesn't stop at the viewports. The key maps break, because the tile they highlight moved. The key plans break, the cover sheet and index that show the whole project and where each sheet falls. Those were drawn against the old tiling too, and they're on their own sheets, in their own files, often owned by someone else. So one re-tile ripples out into every discipline's viewports, every key map, and every key plan, and every piece of it is a manual job.
Keeping all of that in sync, across disciplines and across the people working them, is one of the hardest things to do well on a big project. Not because any single step is difficult. Because there are so many of them, and nothing tells you when you've missed one.
Match lines made it worse
There's a second thing that broke constantly, and it's worth naming because it shaped the design.
The most common way to get sheet references into match line text was a block/field wired to the Sheet Set Manager. That works, if the person setting it up knows exactly what they're doing and nothing about the file structure moves. In practice it's fragile. Things get renamed, files get moved, someone works outside the sheet set for an afternoon, and the references break. On a project split into many files across many disciplines, the risk of breaking is high, and if you done it you know it breaks in the most inconvenient time.
So we didn't want to build something that depended solely on it. The tile is the truth. The tile knows what it covers and what sheet it is, and the match line reads from that. The sheet set is still wired up as well, so everything reads through it the way you'd expect, but it isn't the only thing holding the reference together. Two layers instead of one. When something upstream moves, the tile still knows what it is. And since Tiles are part of the drawing data is preserved and SSM now acts like a safety net instead of main dependency.
What Project Control does
Project Control is where you define the project once and let it build the disciplines for you.
You name your disciplines the way you'd say them out loud: grading, drainage, layout, existing conditions. You decide how sheets are named and where each layout goes. You set how many layouts you want in a single drawing, because large sheets in large numbers make a file unmanageable, so if you cap it at eight and the discipline needs twenty four, that's three files. You can split one discipline across several files, run several disciplines at once, or do both together, all from the same place.
Then it takes the tiling you previewed and generates the discipline drawings from it. Same tiles everywhere, so every discipline lines up sheet for sheet. The sheets are numbered and named the way you specified and wired to the sheet set. That's the layout work done, which is the part that used to be repeated by hand in every discipline. From there the drawing is yours: attach your design references and get to work.
Key maps come from the same definition. Add one and it goes to every sheet that needs it, across every discipline. You can work in zones and give each zone its own key map, or give a discipline a single key map covering the whole project. Because it's all defined in one place, it stays consistent without anyone maintaining it.
And it doesn't take the drawing away from you. These are normal sheets. Go into any of them and add your legends, freeze what you need frozen, use the rest of the tools exactly as you would on a sheet you built by hand or using SheetAgent . Project Control lays the sheets out correctly and keep them in sync when things change.
Why we built it the way we did
The main thing we wanted was for it to not feel like a new system to learn. It works the way the rest of the tool works, and it uses words civil engineers and surveyors already use. Disciplines. Sheets. Zones. Nothing invented, nothing you'd need a manual to decode. You describe your project the way you'd describe it to a colleague, and it builds that.
That was deliberate, because the problem we were solving is a coordination problem, and coordination tools fail when they're complicated. If setting it up is harder than the manual work, nobody uses it, and everyone goes back to XREFing a drawing full of rectangles and updating it by hand forever.
What it changes
The re-tile stops being a project event. You change the tiling once, and every discipline follows: the viewports, the key maps, the key plans. What used to be an afternoon of repeating the same task across six disciplines, plus a hunt for the pieces you missed, becomes one change.
And the disciplines match, because they came from the same definition. Not because someone kept them matching. The set reads as one project across every discipline, which is what it was always supposed to be.
See it on your own project at setline.ai, or read setting up one tiling every discipline inherits in the documentation.