LuxHub DIALux freelancer records: how do QA and customer acceptance connect?

The short answer: submission, QA, acceptance and settlement are separate events

A useful DIALux freelancer platform should preserve one traceable project record from the accepted brief through delivery, QA, customer acceptance and the applicable route to settlement. Uploading a file should not automatically mean that QA has passed, customer acceptance has occurred or money has been released. Each event needs its own status, time and supporting evidence so the freelancer can see what happened and what remains outstanding.

LuxHub's current public specialist portal is an English-only demo with fictional information. Its sample earnings ledger separates approved net value from value under QA and states that no real money can move there. It does not prove a production customer-acceptance or settlement route, so approved freelancers must verify the live controls and terms in their own account. Joining never guarantees approval, projects, selection, income, payout or immediate work.

Start the record before work begins

Traceability begins at the protected project preview, not after a dispute. Review the required DIALux outcome, supplied-material summary, calculation criteria, photometric files, expected effort, deadline, revision allowance and commercial model before responding. A later QA decision is meaningful only when it can be compared with the scope and checklist that existed at commitment.

For a Fixed Bounty project, an eligible freelancer may accept the stated price after reviewing the preview. For an Open Quote project, an eligible freelancer may propose a price and proposed delivery time; that proposal is not an acceptance, and a project should not be described as offering both choices unless its preview actually does. The accepted or selected record should identify the controlling brief, bounty or agreed proposal and deadline.

Make QA refer to a named deliverable version

A QA status should point to the files that were actually reviewed: for example, a named DIALux project, PDF report, luminaire schedule and requested summary views. The record should show the upload version, time, checklist and any returned issue. Replacing a file without preserving version context makes it difficult to know whether a comment applies to the first submission or the corrected one.

Technical QA should test the agreed outcome rather than introduce a new project. Useful checks can confirm that geometry matches the supplied revision, the exact IES or LDT data is used, maintenance assumptions are documented, reported values reconcile with the editable model and every promised file opens correctly. A legitimate correction remains inside the accepted scope; an additional room, option or calculation method needs an approved scope decision.

Define what customer acceptance means

Customer acceptance should be a recorded decision against the agreed deliverables, not an ambiguous silence or a private message. The platform terms should explain who can accept, what evidence is available, whether a review window applies, how a valid correction is requested and how a disagreement is escalated. The freelancer should also be able to distinguish technical QA approval from the customer's commercial acceptance.

Acceptance is not the same as a bank receipt. A controlled route to settlement can begin only after the conditions in the applicable project and platform terms are met. Processing, identity checks, currency conversion, provider rules and local obligations may still sit outside the project status. Never infer a payout date from a fictional demonstration or another freelancer's experience.

Read the ledger as an audit trail, not a promise

A traceable ledger should connect the accepted commercial basis with later project events: the original bounty or agreed quote, the accepted deadline, submission version, QA status, customer-acceptance event and settlement status. Each label should describe a real event and retain its timestamp. An unexplained total or a single word such as complete is not enough when the underlying review has several gates.

The public demo currently shows fictional gross bounties, illustrated service fees, estimated net values, approved net and net under QA. That is useful orientation, but it does not demonstrate real balances, transfers, customer acceptance or production payout timing. An approved specialist should confirm what the live ledger includes, which provider handles sensitive payout onboarding and where a correction or escalation appears before relying on it.

An Australia example: convert every review window

A remote DIALux freelancer in Australia may submit to a customer or QA reviewer operating in Malaysia, Europe or the Americas. Convert the delivery deadline, QA response window, correction due time and customer-acceptance period to the named local time before committing. A status change dated one day earlier or later can simply reflect the time-zone boundary, so the record should retain an unambiguous timestamp.

Australia is a scheduling example, not a claim about local LuxHub availability, project demand or payout support. Specialists worldwide should confirm the operating time zone, public holidays, response expectations and production settlement terms that apply to their own account. The safest decision is to decline when the timing, scope, qualification or access conditions do not fit.

Use both discovery routes, then decide from the protected preview

LuxHub may email an approved freelancer when a compatible project matches the person's skills, work preferences and availability. The message is an alert and entry point, not the whole project experience. Its call to action should lead to the relevant first-party available-project board or protected preview. Approved specialists should also be able to browse compatible opportunities on the board instead of depending only on email.

From the preview, inspect the brief, scope, files or safe supplied-material summary, bounty or customer budget, expected effort and deadline before deciding. Then use only the response model shown, or decline the mission without treating a match as an obligation. The public demo does not verify production project routes; unapproved readers should use the LuxHub join queue rather than attempting a protected login or guessed project URL.

A quick decision check before you join

1. 01
   Preserve the accepted baseline

   Confirm the controlling brief, deliverables, bounty or selected quote, deadline and revision allowance before production starts.

2. 02
   Name every submission

   Tie QA comments to a specific DIALux file, report package and upload version rather than an overwrite with no history.

3. 03
   Separate scope from correction

   Fix genuine errors within the accepted outcome, but route added areas, options or methods through an approved change process.

4. 04
   Identify the acceptance event

   Verify who records customer acceptance, what review window applies and how a disagreement is escalated.

5. 05
   Reconcile the ledger

   Connect commercial terms, submission, QA, acceptance and settlement statuses without treating an estimate as a receipt.

6. 06
   Verify production controls

   The public portal is fictional, so confirm live project, acceptance, ledger and payout behaviour inside an approved account.