LuxHub DIALux freelance workflow: what happens from project brief to QA?

What should happen after a DIALux freelancer accepts a project?

The work should move through a traceable sequence: confirm the accepted brief, review the supplied material, build and calculate the model, check the required deliverables, submit the package for QA, respond to legitimate review points and wait for customer acceptance. LuxHub is designed to keep those steps attached to one project record instead of scattering them across unrelated messages and folders.

The current public specialist demo uses fictional data and cannot create or update real records. Some production controls, including secure mission-file storage, must be enabled and verified before real Agent onboarding. This article explains the verified workflow shown by the current interfaces and the operating boundaries a freelancer should expect; it does not promise approval, projects, selection, income or immediate work.

A structured brief makes the deliverable testable

A useful DIALux brief identifies the project category, technical outcome, relevant geometry, calculation areas, exact photometric data, applicable criteria, report use and deadline. LuxHub's specialist workspace is built to keep the accepted scope, bounty and deadline visible while presenting required outputs as a checklist rather than a vague request to 'do the lighting'.

The brief still needs professional judgement. If a calculation surface, mounting height, luminaire variant or target is missing, the freelancer should use the structured clarification route and explain the technical consequence. If the real project is materially larger or different, the scope-report route is more appropriate. A platform can organise the facts, but it cannot make an incomplete brief technically complete by itself.

Project materials and submission files should stay grouped by purpose

Plans, IES or LDT files, technical notes and accepted decisions belong with the project they support. Working files and final deliverables should be labelled clearly so the specialist, QA reviewer and customer can distinguish an input from a revised output. A grouped record reduces the chance of calculating with the wrong photometric file or issuing an outdated report.

LuxHub's current pilot workspace labels its mission files as samples and performs pre-submission file checks locally. It states that secure mission storage will be activated before real Agent onboarding. Until that production control is enabled and verified, the demo should be treated as a workflow preview, not as a place for live customer material.

Progress stages separate activity from an approved result

A status such as modelling, calculating, quality check, revision or report ready should describe the project's actual state. It should not be advanced merely to look fast. The current LuxHub order-room design exposes a staged path from receipt and acceptance through model, calculation, QA and completion, while the specialist workspace distinguishes work in production from submissions awaiting QA.

Before submission, the freelancer should verify that the required report, DIALux project file and any specified false-colour or summary output are present and correspond to the same model revision. Submission means the package is ready for review. It does not mean QA has passed, the customer has accepted it or settlement has been released.

QA review, customer acceptance and settlement are three different gates

QA should compare the submitted package with the accepted scope and deliverable checklist. A review point needs a specific technical basis: for example, a missing calculation object, mismatched luminaire data, an unexplained assumption or a report that does not show the required result. It should not quietly expand the agreed project into unpaid extra work.

After the package clears the applicable review route, the customer still decides whether to accept the delivered work under the project terms. Settlement is a later controlled step. The current interface describes external payout onboarding and settlement records, but production release depends on QA, customer acceptance, payment operations and completed payout onboarding. A submitted file is therefore not the same as available earnings.

Matched alerts and the project board come before production

LuxHub may email an approved freelancer when a compatible opportunity matches their DIALux skills, work preferences and availability. That email is an alert and entry point, not the whole project experience. Approved specialists can also browse the private available-project board and open a compatible project preview without depending only on email.

The preview should be used to inspect the brief, supplied-material summary, expected effort, deadline and pricing route before responding. An eligible freelancer may accept a Fixed Bounty at its displayed price after review. For an Open Quote, the freelancer may instead propose a price and delivery time. Not every project supports both routes, a proposal is not an acceptance, and unsuitable work may be declined without a bidding penalty.

Remote delivery still needs a deliberate handover

For a Saudi Arabia-based specialist delivering remote DIALux work worldwide, the handover should state the project reference, calculation revision, included scenes, units, output files, unresolved limitations and the time zone used for any deadline. That short record helps a customer or reviewer understand exactly what was delivered without guessing from filenames.

A specialist lighting design freelance job platform is useful when it reduces ambiguity at each transition: opportunity to acceptance, brief to production, production to QA, and QA to customer review. The workflow cannot guarantee demand or remove every disagreement, but it can make the agreed facts and next action easier to verify.

A quick decision check before you join

1. 01
   Confirm the accepted outcome

   Identify the exact DIALux model, checks, report and source files the project requires before production starts.

2. 02
   Validate every input

   Check geometry, mounting data, IES or LDT files, calculation surfaces, targets, units and project assumptions.

3. 03
   Keep files versioned

   Separate supplied material, working files, technical decisions and final deliverables with clear project-specific names.

4. 04
   Update only the real stage

   Use modelling, calculating, QA, revision and completion statuses to describe actual progress rather than expected progress.

5. 05
   Run the deliverable checklist

   Open every submitted file and confirm that its results and luminaire schedule match the final DIALux model.

6. 06
   Separate the three gates

   Submission, QA approval and customer acceptance are different events; settlement follows the applicable controlled route.