Support/Files & Handover/How file naming works
Files & Handover

HOW FILE NAMING WORKS

2,005 views
fileshandover

Xylora Studios enforces a strict naming convention across all client uploads, internal drafts, and final handovers to maintain version control and prevent production errors.

Xylora Studios enforces a strict file naming protocol across all client uploads, production drafts, and final project handovers to eliminate version ambiguity. Every asset catalogued or exported by our Creative and Technology departments follows a standardised syntax based on client codes, asset types, version indices, and ISO dates.

The standard studio naming syntax

All working files, exports, and project assets generated by the studio adhere to a five-part naming structure separated by underscores:

`[PROJECT-CODE]_[ASSET-TYPE]_[DESCRIPTOR]_[VERSION/STATUS]_[DATE].[ext]`

  • Project Code: A unique three-to-four-letter identifier assigned by Operations & Client Services upon project setup.
  • Asset Type: A short functional category marker denoting the medium (for example, `BRAND`, `UI`, `DEV`, `COPY`, `MOTION`, or `PRINT`).
  • Descriptor: A hyphenated, human-readable summary of the exact component (for example, `PrimaryLogo-Dark` or `CheckoutModal-Desktop`).
  • Version or Status: A sequential version marker (`v01`, `v02`) for drafts, `REV` for client review files, or `FINAL` exclusively for approved, signed-off deliverables.
  • Date: The date of export in standard numerical format (`YYYYMMDD`).

An approved vector asset for a brand identity handover appears as: `XYL_BRAND_PrimaryMark-Reversed_FINAL_20240418.svg`

Client uploads and asset ingest

When you supply source assets (such as raw photography, existing vector artwork, font licences, or technical documentation), upload them directly via the portal rather than third-party transfer links.

When preparing files for upload: 1. Maintain descriptive filenames that indicate the contents (for example, `StaffHeadshots_Archive_2024.zip` rather than `IMG_0492.zip`). 2. Do not apply `FINAL` or `LATEST` tags to your source files; internal studio tags override incoming labels. 3. Keep original file extensions unchanged.

Operations & Client Services inspects all incoming files during studio working hours (Monday to Thursday, 09:00–17:00 GMT). Files uploaded outside these hours are logged the following working morning. Our team validates the integrity of the files, appends your project code prefix, and deposits them into the departmental archive.

Internal drafting and revision tracking

During active production, the Creative and Technology teams maintain version control strictly through incremented numerical suffixes (`v01`, `v02`, `v03`).

Studio teams do not use informal suffixes such as `revised`, `new`, or `final2`. When a milestone is issued to you for feedback or staging review, the file or build is marked with `REVIEW` alongside the specific iteration number (for instance, `XYL_UI_DashboardLayout_v03-REVIEW_20240418.fig`). This ensures that your written feedback aligns exactly with the correct asset state.

If you provide change requests through Ask Xylo, the production team increments the version number immediately before starting revisions. Working drafts are archived at each stage, ensuring a complete historical audit trail remains accessible should an earlier design element or code branch need to be recovered.

Handover structure

When a project reaches completion and final milestone approval is confirmed, Operations & Client Services compiles the handover package. Files designated for production, deployment, or print receive the `FINAL` status token.

Final handovers are categorised into clean directory structures according to departmental standards: - Creative handovers: Grouped by format and colour profile (such as `Print/CMYK`, `Digital/RGB`, and `Vectors`). - Technology handovers: Packaged with version-tagged release builds, documentation, and asset manifests matching the repository commits.

Once the handover archive is assembled, filenames are locked. No further modifications are made to those files without commissioning a new scope or revision cycle.

Failure cases and resolution

  • Ambiguous or generic client uploads: Files submitted with system-generated names like `Document.pdf` or `Untitled-1.png` cause intake delays. Operations & Client Services will flag these via Ask Xylo within our standard 24-hour response window, requesting clarification before passing them to production.
  • Conflicting version references: If client feedback references a file without its complete version suffix, the studio pauses the dependent task until the exact version is confirmed. Always cite the full filename in written communications.
  • Corrupted or broken archives: Archives missing constituent linked assets (such as missing fonts or unlinked raster links in vector artwork) are rejected at the ingest check and logged back to the client.

File naming checklist

Before submitting materials to the studio portal, ensure your items comply with the following:

  • [ ] File names use standard alphanumeric characters, hyphens, and underscores only (no spaces or special characters).
  • [ ] Descriptors clearly identify the specific asset or page.
  • [ ] Files are not labelled with arbitrary words like "final", "new", or "updated".
  • [ ] Asset archives (`.zip`) contain an organised internal folder structure with corresponding labels.
  • [ ] Any queries regarding file requirements have been sent to Operations & Client Services via Ask Xylo.

Was this helpful?

Tell us honestly. It is read by the people who write these pages.

If this didn't answer your question, ask Xylo.

Back to Files & Handover