Public event site plan
What the score means for your operation
The gauge at the top of this report is how well the file is built. This one is what that means for your business: the risks you carry while it stays as it is. The two move together, one is the cause, the other the consequence. Each risk below is drawn from the drawing evidence further down, tap any card to see it.
Key-person dependency
The file has almost no class system of its own, most of the class list is imported CAD dumped in, and most of the event plan has no class, so the drawing largely makes sense only to whoever built it. That is a single point of failure.
Onboarding and scaling the team
There is little in the class structure a newcomer can learn: 913 classes, most of them imported survey coding and near-duplicates, with the file's own readable scheme only about 19 classes. That means a long handover before anyone is productive.
On-site accuracy and safety
The plan is not pinned to the real world and its base is a traced imported survey, so anything set out from it could be wrong on the day. At a public event, that is a safety exposure.
Change turnaround
Nothing counts itself and the file is heavy with an imported survey and hidden duplicates, so every change means manual recounting in a slow file. Late changes are slow and error-prone.
Procurement and budget accuracy
The file cannot count itself and hidden duplicates inflate every tally, so quantities taken off it are unreliable. That risks over-ordering or under-ordering.
Reusability across events
The venue is not held as a reusable master and there is no shared asset library or template, so each event risks a rebuild. The bright spot: the venue and event are already on separate layers.
Handover and supplier independence
The file is self-contained and opens cleanly elsewhere, which is a real plus. But with a class list that is mostly imported CAD and no documentation, a handover would still be messy and slow.
Single source of truth
The event assets are copied into the file rather than shared from one library, and this is not set up as a central working file, so copies drift and it is easy to work from an out-of-date one.
Governance and approvals
The printed sheets are there, but there is no revision or issue history in the file and the name-and-details panel is not a managed one, so there is no reliable record of what was issued when. That is a gap if a plan is ever questioned.
Future value and strategic readiness
Almost the whole file is raw survey carrying no information, and it is not tied to the real world, so it cannot feed a twin, automation or reporting tools as it stands. Fixable, but not today.
Two things are genuinely good. The class list is not one of them.
Where the file stands for a decision-maker: a real head start on the structure, held back by gaps that cost your team time and certainty on every event.
What is working
- The site survey and the event plan are already kept on separate layers.
- The event assets are built as real, reusable objects, drawn at their true real-life size.
- The file's own event classes, about 19 of them, are named in plain, readable words. That is the part worth keeping.
- The units are consistent and the printed sheets are set up cleanly. The bones are here to build on.
What it is costing you
- The file cannot count itself, so barriers, generators and capacities are counted and scheduled by hand, and recounted on every change.
- You cannot be sure the plan matches the real site, because it is not pinned to real-world map coordinates.
- The class list is overwhelmingly an imported CAD survey and bound references, about seven in ten, plus a foreign coded standard with no key, so it is not a system anyone can pick up and follow.
- More than half the event plan is left with no class, so items cannot be reliably controlled as a set.
Where it sits
- 28 out of 100. Fragmented.
- Good bones, but almost no class system of its own.
- Someone new could not pick this up and work efficiently without a long handover or a discovery session.
- The good news: the layer split and the event assets are solid, and every gap is fixable.
Right now this is a picture of a site. Here is what it could become to run your events.
Investing in the plan buys back time and certainty. In plain terms, the work is:
- Clear out the clutter and give every object a home. Strip the tens of thousands of leftover objects dragged in with the old survey, then give everything a class it locks to, so nothing gets lost, mislabelled or dropped when a plan is shared, and the file stays fast with numbers you can trust.
- Build the venue once and reuse it. Hold the site as a single master that every event plan references, so it is never redrawn from scratch and a change is made in one place.
- Name everything to one simple system. So anyone on your team can open the file and find their way around it without a handover.
- Anchor the plan to the real world. Fix it to real-world map coordinates with a dynamic grid overlay, so a point on the plan is the same point on the ground, and your crew can call a location off any drawing with everyone meaning the same place.
- Put the event assets in one shared library, and information on every object. Barriers, generators and marquees held once so an update pushes to every plan, and each object carrying its own data so the plan counts itself.
Then the plan tallies its own barriers, generators and capacities the moment anything changes, the office and the install crew work from the same numbers, and every future event starts from certainty instead of assumptions.
The good news is you are starting from a real base, not from nothing. The event assets are already built at true real-life size, and the site survey and the event plan are already kept on separate layers.
Because this file is not pinned to real-world coordinates (not georeferenced) and its base is a traced-over survey, there is also an optional first check worth doing: a measured pass proving whether the base plan is truly to scale, how far it departs from the real world, and whether it corrects with a simple rescale or needs more. It is the cheapest way to know what the base is worth before anything is built on it.
The four that cost you most
The file cannot count itself
Every barrier run, generator and crowd capacity is counted by hand, then recounted from scratch every time the plan moves, and the install crew's schedules are built the same way. Change the layout on the Tuesday and someone spends the Wednesday recounting, and on site the printed count and the live plan have already drifted apart. A file that carries data counts itself the moment anything changes, so the office, the order and the crew always work from the same numbers.
You cannot trust the plan matches the real site
The base is an imported combined CAD survey, traced over, and the drawing is not pinned to real-world map coordinates (in CAD terms, it is not georeferenced). It does sit at what look like real map coordinates, but nothing formally locks it there, so the software treats it as floating thousands of kilometres from its zero point. There is no way to know the plan is actually to scale, or that it still matches the site, without measuring it on the ground. Anything set out from it, distances, quantities, vehicle access, could be wrong on the day. Pinning it to real-world coordinates, plus one site check, turns the plan into something you can set out from with confidence.
Half the event content is not sorted, so it cannot be controlled
In a drawing, a class is like a labelled pen: it sets how something looks and lets you control every item of one kind at once, turning it on or off, recolouring it, hiding it. On the layer your team actually draws in, more than half the event plan, 56 per cent, has no class at all, left on the drawing's default, the catch-all for anything not given a class, and the underlay layer is entirely unclassed. Anything sitting there cannot be reliably switched on or off, recoloured, or hidden as a group, and it quietly drops out when a plan is exported or handed to someone else. Sorting everything onto the file's own readable classes, locked so nothing slips out, makes the plan quick to build and safe to hand to anyone.
The class list is mostly an imported CAD survey, not a system
Seven in ten of the 913 classes are an imported CAD survey and bound external drawings, tipped straight into the file, which drags in every layer of every referenced drawing as a class (the tell is the $0$ bound-reference marker). On top of that, 368 classes are near-duplicates of one another. It makes the file heavy to open and buries the genuine content, and the file's own small, readable class scheme, under clutter. This is not your team's doing, it is what importing raw CAD drags in, and it clears out in a cleanup pass. Cleaning it makes the file faster and its structure legible.
A picture is lines a person reads. A model is objects that carry data and count themselves.
The single biggest daily win from a model is reporting: the file counts itself, live, on every change, instead of being counted by hand and recounted every revision. AI, automation and a digital twin can do nothing with a picture. Here is where this file sits.
The base is a picture
Of the objects in the file are the raw lines and text of an imported CAD survey. That base cannot report, count or schedule anything.
The event assets are real objects
Genuine, reusable event objects, drawn at their true real-life size, so the hard half of a model is already done. But even these carry no information yet, so nothing in the file counts itself.
The deciding fact sits across both: not one object in the file, survey or event, carries any information of its own. The fix puts that information onto the objects the event assets already give you, which is the shortest path from a picture to a file that reports itself.
The ten areas we measured
These ten technical areas are what we actually checked inside the file. The operational exposure at the top is drawn from them. This is a site and event plan, so production content (rigging, positions, equipment) is out of scope and not scored.
Tap any area to jump to the detail behind its score.
Everything we examined
Each area shows what good looks like, what this file actually is, then the specifics underneath.
Structure & governance
Classes & appearance
25 · FragmentedThink of classes as the labelled pens you draw with. A class sets how something is drawn, its colour, line weight and fill, and groups like things together so they can be controlled as one set. Good practice is one clear set of classes used on everything, sorted so anyone can find the right one, and named to one structured system so the name itself tells you what a thing is and where it sits, like Event-Barriers-Fence rather than a loose FENCE or fence_1. Items are locked to their class so nothing ends up on the wrong one or left with no class at all.
There is almost no class system of its own. About seven in ten class names are an imported CAD survey and bound external drawings dumped straight in, and most of the event content is left with no class, so the working layer has little real control.
- 913 classes in the file. About 70 per cent are an imported CAD survey and bound external drawings tipped in whole, not classes anyone designed. The chart below shows the breakdown.
- A further block follows a coded standard imported from elsewhere (a surveyor or council CAD scheme). It is consistent, but it is a cipher with no key in this file, so it means nothing to whoever opens the drawing.
- The file's own readable class scheme, in plain words, is about 19 classes. That is the part worth keeping and building on.
- On the layer your team draws in, 56 per cent of the event plan has no class at all, left on the drawing's default, the catch-all for anything not given a class; the underlay layer is 100 per cent unclassed.
- 368 of the 913 classes are near-duplicates of one another, mostly inside the imported sets, the classic sign of drawings built up and merged over years.
- Objects are not locked to a class, so anything can be drawn onto the wrong one, or none at all, by accident.
Layers
58 · DriftedThink of layers as sheets of tracing paper laid over one another: you turn a sheet on or off to show or hide a whole part of the drawing. Good practice is a short set of clearly named layers, with the venue kept on its own layers, separate from the event, so you can show exactly what each audience needs to see.
The strongest part of the file. The layers are sensibly purposed and already separate the imported survey base from the event content, which is a real head start for the fix.
- Three working layers, clearly purposed: the imported survey base map, an Event Overlay, and an underlay maps layer.
- Venue and event are already separated, which is exactly the right instinct.
- No duplicate or near-duplicate layer names across the 18 layers in the file.
- Fifteen printed sheets sit on top, more presentation structure than most event files carry.
Resources & tidiness
25 · FragmentedA tidy, filed set of the drawing's stored items (the patterns and styles it keeps on a shelf to reuse), named for people to read, with nothing dead left in the file.
The file is carrying a lot of imported clutter here, patterns and records tipped in from CAD imports and never cleaned out, almost none of them filed. It bloats the file and buries the few items that matter.
- 155 stored patterns and records in the file, and almost none are filed: 153 of them sit loose at the top level.
- Many are machine-generated names from imports (ANSI31, AeccArwClosedFilled), not names a person would choose.
- 141 classes carry no objects, more dead weight waiting to be cleared.
- No set styles for repeated things like walls or ground surfaces. How things look is left to the classes.
Shared library & links
35 · FragmentedOne central asset library that every file references, so a change to a barrier or chair is made once and pushes everywhere.
The file is self-contained, which is good for opening it elsewhere, but nothing is shared, so every fix has to be redone by hand in every file it touches.
- No broken links. The file does not depend on missing external files, so it opens cleanly on another machine.
- No shared library is used. The event assets are copied into this file rather than pointing at one central library.
- That means updating a barrier or a generator has to be redone by hand in every file it appears in, instead of once.
Content & intelligence
Event assets & scale
40 · FragmentedThe event assets built as real, reusable objects (a barrier, a generator, a marquee, drawn once and dropped in wherever needed), each at its true real-life size, with clean insides, and everything filed where you would look for it.
A real strength and a real weakness in the same place. There are 541 genuine event assets drawn at true real-life size, which matters. But they are buried under nearly 11,000 machine-named objects tipped in from a raw CAD survey import, so the library is far harder to trust and navigate than it should be.
- 541 genuine, hand-built event assets (barriers, marquees, bins, benches), all confirmed drawn at their true real-life size (what CAD calls real-world scale). That is how it should be, and often is not.
- But the file holds 11,358 reusable objects in total: nearly 10,800 are machine-named leftovers from a DXF/DWG survey import (names like A$C677F448E), not a real library.
- Those import leftovers are filed into four folders, but that is an import dump, not a filing system, so it does not count as tidy.
- None of the reusable objects are shrunk to page size; every one is world-based (true real-life size), which is a genuine positive.
- A handful of event assets are likely duplicates of one another, and some carry stray survey labels inside them (the audit flags candidates, not confirmed duplicates).
Real objects vs raw lines
25 · FragmentedA drawing made of intelligent objects that know what they are, not thousands of raw lines, and no hidden duplicates dragging on the file.
The file is overwhelmingly a picture, a huge imported CAD survey, and it is heavy to work in because of it, with hidden duplication inflating every count taken off it.
- Around 96 per cent of the objects in the file are the raw lines and text of an imported CAD survey. That base is a picture, not a model.
- The survey base is heavy: over 31,000 of its objects sit as flat linework on the drawing (layer) plane, which is what makes the file slow to open and pan.
- 1,834 objects are exact duplicates stacked on themselves, invisible on screen. They slow the file and inflate counts and exports.
- The genuine event objects are real, but they are a small fraction of the file by count.
- The whole drawing sits about 6,264 km from the file's zero point, because the survey was placed at real map coordinates but never formally pinned there.
Data & reporting
10 · No systemObjects that carry their own information, so the file counts itself, live, on every change: barriers, generators, capacities, all reported automatically.
This is the biggest gap and the biggest opportunity. Almost nothing in the drawing carries any information, so every count and schedule is manual and every revision means recounting from scratch.
- Across nearly 39,800 objects, on every layer, effectively nothing carries information of its own. The file holds almost nothing about what its objects are.
- There are effectively no auto-counting tables driving off the objects: one small plant list is the only live one, and a leftover imported table counts nothing.
- There are no labels that read information off the objects.
- Every barrier run, generator, capacity and count is done by hand today, and redone from scratch every time the plan changes, which is where the daily hours and the on-site errors come from.
Spatial & output
Real-world position
12 · No systemThe drawing pinned to real-world map coordinates (this is what CAD calls georeferencing), with its zero point locked and a coordinate grid you can read locations off, so the same spot reads the same numbers at any scale and the plan sits correctly on a map or an aerial photograph.
The drawing is not pinned to the real world, and its base is a traced imported survey, so there is no way to be sure it is to scale or still matches the site without checking on the ground. Anything set out from it is an assumption until verified.
- The drawing is not pinned to real-world map coordinates (not georeferenced). It carries no map reference the software recognises.
- The survey does sit at what look like real map coordinates, but nothing formally locks it there, so the software treats it as floating about 6,264 km from its zero point, and it can shift if that zero point is ever reset.
- Because it is not formally pinned, there is no fixed grid to read locations off, and the same point can read different numbers at different scales.
- The base is an imported combined CAD survey. Whether it is truly to scale cannot be confirmed from inside the file; it needs measuring against the real site.
- The drawing does not sit on an aerial photograph, so it cannot be checked against the real site by eye.
Units
60 · DriftedOne unit setting, consistent across the file, and the right base unit for the size of the site.
Units are consistent, which is good. But the file is set in millimetres for a large outdoor site, where metres would be the natural choice and easier to read and check.
- The document is set to millimetres, with no mixing of millimetres and metres. That consistency is a genuine positive.
- For a site of this size, millimetres is a heavy choice. Metres is the norm at site and precinct scale.
Sheets & presentation
42 · DriftedClean sheets, with the on-screen windows (viewports) set from styles rather than tweaked one by one, and a managed name-and-details panel that carries the issue and revision history automatically.
The sheets and viewports themselves are clean, and there are more of them than most files carry, but the title block is not a managed one, so there is no revision or issue history and sheet information is typed by hand.
- Fifteen viewports (the framed windows on the printed sheets that show the plan), and none carry one-off tweaks. That is clean; the sheets are not being hand-hacked.
- Fifteen printed sheets are present, more presentation structure than most event files carry.
- The title block (the drawing's name-and-details panel) is not the managed kind that carries revision history automatically.
- There are no revision or issue tables on the sheets, so there is no drawing history captured in the file.
- No set text styles sit behind the 21,756 pieces of text in the file, so labels are placed by hand rather than from a standard.
The standard this is scored against
Generic good, a file any team can pick up and run. Reporting is the flagship. This file already has part of 4 (the layer split), part of 8 (event assets at true real-life size) and part of 9 (clean sheets and consistent units). The gaps are the rest.
- Reporting: the file counts itself. Barriers, generators, capacities, live on every change.
- Objects that carry their own information, with labels that read straight off the object. The engine under reporting.
- One set of classes, sorted so they are easy to find, and named to one structured convention so the name itself tells you what a thing is and where it sits in the hierarchy (the multi-separator style flagged in the naming chart, for example Event-Barriers-Fence rather than a loose FENCE or fence_1). That is what lets anyone read a class name and know exactly what it controls. Every object locked to its own class, so nothing drifts or ends up with no class.
- A short set of clearly named layers, the venue kept separate from the event.
- The venue held as one master, built once, every event plan pointing at it.
- Pinned to real-world map coordinates, its zero point locked. Nothing floats.
- A real-world coordinate grid you read locations off, the same numbers at any scale.
- One central asset library, held once and reused, at true real-life size.
- Set styles for the on-screen windows and printed sheets, managed title-block details, fonts and units. Repeatable output.
Items 5 and 7 are built once by a superuser, not chores landed on the drag-and-drop crews. They are things the file has, not tasks for every planner.
The evidence behind the scores
The measurements behind each score, from a 71-part audit that read every object in the file. The figures that carry a finding are shown here; the full raw data sits behind them.
Classes
| Total classes | 913 |
| Your own readable system | ~19 classes |
| Imported coded standard (no key) | ~97 classes |
| Imported CAD dump / bound refs | ~638 classes ($0$ bound xrefs) |
| Unused | 141 |
| Near-duplicate flagged | 368 |
| Event plan with no class (default) | 875 of 1,567 (55.8%) |
| Underlay layer with no class (default) | 6 of 6 (100%) |
| Objects locked to a class | No |
Layers
| Working (design) layers | 3 |
| Survey base map | 38,259 objects |
| Event Overlay | 1,567 objects |
| Underlay maps | 6 objects |
| Printed sheets | 15 |
| Total layers in file | 18 |
| Duplicate/near-duplicate layer names | None |
Stored items (non-symbol)
| Stored patterns and records | 155 |
| Filed into folders | 2 of 155 |
| Loose at the top level | 153 |
| Machine-named import leftovers | Many (ANSI31, AeccArwClosedFilled) |
| Unused classes carried | 141 |
| Set styles for walls/surfaces | None |
Event assets (reusable objects)
| Genuine event assets (hand-built) | 541 |
| Confirmed at true real-life size | All (world-based) |
| Shrunk to page size | 0 |
| Machine-named import leftovers | ~10,817 (DXF/DWG dump) |
| Total reusable objects in file | 11,358 |
| Import leftovers filed in | 4 import folders (an import dump, not a filing system) |
| Duplicate candidate groups | Flagged (candidates, not confirmed) |
Objects & duplication
| Objects checked | 39,832 |
| Share that is imported survey | ~96% |
| Hidden duplicate stacks | 713 |
| Objects duplicated on themselves | 1,834 |
| Survey base on the drawing plane | ~31,600 flat objects |
| Drawing type | Essentially flat plan |
Data & reporting
| Objects carrying information | Effectively 0 of 39,832 |
| Auto-count tables (worksheets) | 1 live (a plant list) |
| Auto labels (data tags) | 0 |
| Automatic counts or schedules | None |
Real-world position & units
| Pinned to real-world coordinates | No |
| Map reference | None recognised |
| Coordinate grid | None |
| Base plan confirmed to scale | No, needs on-site verification |
| Centre of drawing vs the file's zero point | ~6,264 km away, unlocked |
| Sits on an aerial photograph | No |
| Measurement unit | Millimetres |
| Unit consistency | Consistent, no mm/m mix |
| Unit vs site size | Mm on a large site; metres is the norm |
Sheets & title panel
| Viewports (windows on sheets) | 15 |
| Viewports with one-off tweaks | 0 |
| Printed sheets | 15 |
| Title panel | Not the managed kind; no revision history |
| Revision / issue tables | None |
| Set text styles behind 21,756 labels | None |
Shared library & links
| Broken links | None |
| Shared library used | None; the event assets are copied into the file |
| Opens cleanly elsewhere | Yes, everything is baked in |
Get this for your own plan
This is an example of the report you receive when you have your own drawing audited. The file behind it has been anonymised. Yours reads the same way, on your own plan, with your own numbers.
- Book an audit and upload your native Vectorworks file.
- We run the same checks on your drawing and score it the same way.
- You get a report like this one, in plain English, on your own site.
No obligation. You keep the report either way.
Book your audit →