Indoor venue 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 51 class names are one-off labels, and appearance is overridden object by object, so how the drawing is meant to look and behave lives in one head. That is a single point of failure.
Onboarding and scaling the team
There is no naming system to learn, and because colours are hand-set, a newcomer cannot even trust what they see on screen to follow a rule. Learning the file means opening things one at a time.
On-site accuracy and safety
The geometry is drawn locally and much of it is genuinely modelled, but the plan carries no map reference and nothing has been verified against the building, so setout still needs a site check.
Change turnaround
Moving modelled objects is quick, but appearance is hand-set, so changes mean repainting as well as redrawing, and nothing counts itself afterwards.
Procurement and budget accuracy
The file cannot count itself and hidden duplicate stacks inflate what a manual tally would find, so quantities need verifying every time.
Reusability across events
Template layers for the exhibition display system and market layout show reuse intent, and the venue geometry is the raw material of a master. It is not set up as one, so each event still works over a copy.
Handover and supplier independence
The file is self-contained and opens cleanly anywhere, and its assets are almost all filed. A competent firm could pick it up, then spend their first days decoding names and hand-set colours.
Single source of truth
The file is clear about what it is, but market layout content exists in two generations of layers, and nothing records which is current.
Governance and approvals
Two viewports and no revision or issue history: the file does not record what was issued or when.
Future value and strategic readiness
The modelled geometry has forward value, but with no naming system, no information on objects and no map reference, none of it can feed a twin or reporting as it stands.
The venue is here. The control system is hand-painted.
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
- Around two thirds of the file is real modelled geometry, including solid 3D and meshes of the venue structure.
- The 97 reusable assets are all at true real-life size, and almost all are filed into folders.
- Template layers for the exhibition display system and market layout show genuine reuse intent.
- The file is light, self-contained and opens cleanly anywhere.
What it is costing you
- The 51 class names are one-off labels with no scheme, so the class list cannot be learned or handed over.
- Appearance is hand-painted: for every object that follows its class colour, twelve override it, so the classes control almost nothing.
- Nothing carries information, so every count and schedule is manual and redone on every change.
- 462 objects sit stacked exactly on top of themselves, and the plan carries no map reference and no issue history.
Where it sits
- 28 out of 100. Fragmented.
- A workable venue picture run on memory and hand-set colours.
- Someone new could open it and see the venue, but could not change anything with confidence.
- The good news: the modelling is real, and every gap is a system fix, not a redraw.
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 venue becomes a master anyone can plan over, appearance comes from the classes instead of hand-set colours, and every layout counts itself instead of being tallied by eye.
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
Appearance is hand-painted, not driven by the classes
In a drawing, a class should set how its objects look, one change recolours every barrier or every garden bed at once. Here the audit found 449 objects overriding their class appearance against 37 following it, twelve overrides for every follower. The look of the drawing has been painted object by object, so a class change does almost nothing, a recolour means touching things one at a time, and two objects that look the same may be different kinds of thing entirely. Putting appearance back into the classes is what makes the drawing behave like a system instead of a painting.
The class list has no system
There are 51 class names and the audit could not credit one of them to a readable system: one-off labels in three mixed styles, no families, no key. The file still works because its author knows every label, but nothing about it can be taught or handed over, and with appearance hand-set on top, the class list is doing almost no work at all.
Nothing counts itself
Not one object carries information, there are no auto-counting tables, and no labels that read off the objects. Every stall count, display count and equipment tally is manual, and redone from scratch when the layout changes. The assets are already real objects at true size, so putting information on them is a data job rather than a redraw.
Hidden duplication is high for a file this size
462 of the 5,797 objects, about one in twelve, sit stacked exactly on top of another copy of themselves across 148 hidden stacks, invisible on screen. They slow the file and inflate every count and export taken off it, so even a careful manual tally overstates what is really there. Clearing them is quick once found, and until then no number taken off this file should be trusted without a check.
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 are raw lines and loose text. The rest is real modelled geometry, a far better balance than the precinct site plans.
The event assets are real objects
Reusable event assets, all at true real-life size and almost all filed into folders. A real kit. But nothing carries information yet, so the file cannot count 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 named to one structured system, with every object locked to its class and appearance driven from it.
No readable system, and the classes control almost nothing in practice, because appearance has been hand-set object by object on top of them.
- 51 classes, three naming styles mixed, and not one name credited to a readable system by the audit.
- 9 classes are unused and 2 are near-duplicates.
- Appearance is the standout fault: 449 objects override their class colour against 37 that follow it.
- Most objects are at least given a class; the drawing default carries very little.
- Objects are not locked to a class, so filing drifts.
Layers
35 · FragmentedThink 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 classes doing the fine sorting.
One layer per venue element, the same pattern as the other venue file: readable at this size, but it is the class list by another name.
- 23 design layers, mostly one per element: gutters, grates, doors, garden beds, buildings, tenant zones.
- The gutters layer is the heaviest, holding 619 objects, over a third of the drawn content.
- Market layout content exists in two generations of layers, current and template, with nothing marking which rules.
- Template layers for the exhibition display system and market layout are a reuse instinct worth keeping.
Resources & tidiness
30 · 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.
A well-stocked but unfiled shelf: most stored items are actually in use, which is unusual, but nearly everything sits loose at the top level.
- 80 stored patterns and styles, and only 7 are unused, the healthiest use rate in this set.
- 86 of 105 stored items sit loose at the top level rather than filed into folders.
- No text styles, so the 214 text blocks are formatted by hand.
- No set styles for repeated structures.
Shared library & links
35 · FragmentedOne central asset library that every file references, so a change to a display unit or a stall is made once and pushes everywhere.
Self-contained and portable, but nothing is shared, so nothing here updates anywhere else.
- No broken links. The file opens cleanly on another machine.
- No shared library is used; the assets live only in this file.
- The venue geometry is the raw material of a referenced master, not yet set up as one.
Content & intelligence
Event assets & scale
40 · FragmentedThe event assets built as real, reusable objects (a display unit, a stall, a door, 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 decent kit with tidy filing and a duplication problem: one in nine assets is flagged as a likely duplicate candidate of another.
- 97 reusable assets, 91 of them filed into folders.
- All 97 are drawn at true real-life size (what CAD calls real-world scale). Nothing needs redrawing for scale.
- The audit flags 11 likely duplicate candidate groups (candidates, not confirmed), high for a library this size.
- Asset naming mixes six styles, from plain names to machine codes.
Real objects vs raw lines
40 · FragmentedA drawing made of intelligent objects that know what they are, not thousands of raw lines, and no hidden duplicates dragging on the file.
A mixed picture: two thirds real geometry including genuine 3D, one third raw lines, and the highest rate of hidden duplication of the venue files.
- About 33 per cent of the objects are raw lines and loose text; the rest is real geometry.
- Real 3D is present: 281 solids and 252 meshes of the venue structure.
- 462 objects sit in 148 hidden duplicate stacks, about one object in twelve. High for a file this size.
- 5,797 objects in total, a light file that would be lighter still once the stacks are cleared.
Data & reporting
8 · No systemObjects that carry their own information, so the file counts itself, live, on every change: stalls, displays, equipment, all reported automatically.
Nothing. No records, no auto-counting tables, no labels that read off objects. Every count in this venue is manual.
- 0 of 1,122 top-level working objects carry a data record.
- No auto-counting tables exist in the file.
- One built-in label type is the only data-driven object present.
- The assets are real objects at true size, so adding information is a data job, not a redraw.
Spatial & output
Real-world position
18 · No systemThe drawing pinned to real-world map coordinates (this is what CAD calls georeferencing), with its zero point locked, so the plan sits correctly on a map and positions can be trusted.
Not pinned, drawn locally near the zero point. For an indoor venue the exposure is lower than a precinct plan, and it is noted rather than laboured.
- The file is not pinned to real-world map coordinates and carries no map reference.
- The content sits locally, tens of metres from the zero point, which is tidy practice.
- Whether the modelled venue matches the building as built cannot be confirmed from inside the file.
- The drawing does not sit on a floor plan or aerial reference it can be checked against by eye.
Units
60 · DriftedOne unit setting, consistent across the file, and the right base unit for the size of the site.
Consistent millimetres at venue scale. No unit faults found.
- The document is set to millimetres, with no mixing of millimetres and metres.
- At indoor venue scale, millimetres is a defensible choice; one rule should be settled across the whole file set.
Sheets & presentation
25 · FragmentedClean 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.
Two clean viewports and nothing else: no managed title panel, no revision history, no text styles. Not set up to issue a governed drawing.
- 2 viewports (the framed windows on printed sheets that show the plan), with no one-off tweaks.
- No managed name-and-details panel found.
- No revision or issue tables, so no drawing history is captured.
- No text styles behind the text in the file.
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 | 51 |
| Naming styles present | 3, mixed |
| Credited to a readable system | 0 |
| Unused | 9 |
| Near-duplicate flagged | 2 |
| Objects following their class colour | 37 |
| Objects overriding their class colour | 449 |
| Objects locked to a class | No |
Layers
| Design layers | 23 |
| Pattern | One layer per venue element |
| Heaviest layer | Gutters, 619 objects |
| Template layers | 2 (exhibition display system, market layout) |
| Market layout generations | 2, side by side |
Stored items
| Stored patterns and styles | 80 |
| Unused | 7 |
| Loose at the top level | 86 of 105 stored items |
| Text styles | 0, behind 214 text blocks |
| Set styles for structures | None |
Event assets (reusable objects)
| Reusable assets | 97 |
| At true real-life size | 97 (100%) |
| Page-scaled | 0 |
| Filed into folders | 91 of 97 |
| Duplicate candidate groups | 11 (candidates, not confirmed) |
Objects & duplication
| Objects checked | 5,797 |
| Raw lines and loose text | ~33% |
| Solid 3D and mesh objects | 533 |
| Hidden duplicate stacks | 148 |
| Objects duplicated on themselves | 462 (~1 in 12) |
Data & reporting
| Objects carrying information | 0 of 1,122 top-level |
| Auto-count tables (worksheets) | 0 |
| Auto labels (data tags) | 1 type |
| Automatic counts or schedules | None |
Real-world position & units
| Pinned to real-world coordinates | No |
| Map reference | None |
| Content position | Drawn locally near the zero point |
| Verified against the building | No |
| Measurement unit | Millimetres |
| Unit consistency | Consistent, no mm/m mix |
Sheets & title panel
| Viewports (windows on sheets) | 2 |
| Viewports with one-off tweaks | 0 |
| Title panel | None found |
| Revision / issue tables | None |
| Text styles | None |
Shared library & links
| Broken links | None |
| Shared library used | None |
| 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 →