Rejected again, and this time it was the status code
An engineer uploads a set of drainage drawings to the client's common data environment at the end of the day. The next morning, half of them have been rejected by the information manager. One has the wrong originator code. Another uses a volume code that was retired last month. Three have the right name but the wrong suitability code in the metadata. The engineer fixes them, re-uploads, and loses another hour.
On a project with a demanding information standard this can happen every week. Each project uses its own variation of the naming convention, and nobody in the office holds all of them in their head.
Why naming errors keep happening
- Each project's information requirements define their own codes for volumes, levels, types and roles.
- Code lists change during the project and the update sits in a PDF nobody rereads.
- File names are typed by hand at export, often at the end of a long day.
- Metadata fields in the CDE are filled separately from the file name, and they can disagree.
- Different CDEs, such as Viewpoint for Projects, Aconex, ProjectWise or Autodesk Construction Cloud, handle metadata differently.
ISO 19650 sets out the principles. Each project's information protocol turns them into specific rules. The rules are reasonable. Remembering them for five projects at once is not.
The workload is uneven too. Technicians who issue drawings every day learn a project's rules quickly. Engineers who upload a calculation report once a month do not, and they are the ones most likely to be rejected, usually late on a Friday when the information was promised.
What rejections cost
| Effect | Where it lands |
|---|---|
| Re-uploads and corrections | Engineer and technician time |
| Late availability of information | Other disciplines wait, programme pressure |
| Poor record with the client's information team | More scrutiny on every future upload |
| Inconsistent names in your own archive | Harder to find files later |
How we build a pre-upload checker
- For each project, we set up its naming convention, code lists and required metadata fields in a configuration you can update when the protocol changes.
- Files go into an upload folder, or are selected in the checker, before going to the CDE.
- Each file name is split into its fields and checked against the project's code lists.
- Metadata, such as suitability, revision and description, is checked against the file name and against the drawing register.
- Errors are shown clearly with suggested corrections, which the engineer accepts or edits.
- Where the CDE offers an API, the checked files and metadata are uploaded directly. Otherwise a metadata sheet is produced for bulk import.
- A log records what was checked and uploaded, useful when a question arises about a particular issue.
We also check your own internal naming for files that never go to a CDE, so the project archive stays consistent.
We normally configure the checker from the project's information protocol together with whoever acts as your practice's information lead, then test it against a batch of your past uploads, including ones that were rejected. That shows quickly whether the rules have been captured correctly before anyone relies on it.
After the checker is in place
Errors are caught at your desk rather than by the client. When a code list changes, it is updated once in the configuration, and everyone's next upload follows it.
Engineers spend their time on the drawings rather than on the names of the drawings.
Does this sound familiar?
- Uploads are rejected for naming or metadata errors.
- Engineers keep a printout of each project's naming rules at their desk.
- Code list updates are missed.
- Your own archive has inconsistent file names across projects.
- Metadata and file names sometimes disagree.