The Lighting Approval RACI: Owner, Designer, Consultant, Contractor, and Supplier

A lighting approval RACI should tell a hotel project team who prepares,
reviews, authorizes, purchases and receives each lighting deliverable. It
should not merely list job titles. The useful unit is a specific decision—such
as accepting a finish sample, closing technical comments or releasing a
drawing for production—tied to one revision, required evidence and one
accountable authority.

This matters because “approved” can mean several different things. A designer
may accept appearance, a consultant may close a technical comment, an owner
may authorize cost, and a contractor may issue the purchase instruction. None
of those actions automatically substitutes for the others. The matrix below is
a starting framework for hotel owners and developers; the project contract,
appointments and procurement route always govern the actual assignments.

The approval rules that prevent ambiguous release

• Use four decision rules to prevent ambiguous lighting release. Assign RACI letters to a deliverable and decision, not to a broad job title.
• Name one Accountable role for each approval row.
• Separate design, technical, commercial, purchasing and site-acceptance
  decisions.
• Record the accepted revision, evidence, conditions and downstream release.

What does a lighting approval RACI control?

The
PMI Lexicon
defines RACI as a responsibility assignment matrix using four participation
states: Responsible, Accountable, Consulted and Informed.
Responsible does the work, Accountable owns the decision, Consulted gives
input before it, and Informed receives the outcome.

For lighting approvals, apply those letters to a named deliverable and
decision—not to an entire discipline.
“Designer: A” is too broad. “Designer: A for visual acceptance of finish
sample FS-03, revision B” is usable. It identifies what was decided and
prevents a comment on one attribute from being mistaken for blanket production
approval.

This task-level approach is consistent with the RIBA Plan of Work, whose toolbox includes a Design Responsibility Matrix and organizes tasks and information exchanges by project stage. RIBA source
PMI defines the general project-management tool. The transferable lesson
for lighting is to apply it to specific deliverables; that is not a rule imposed by
PMI or RIBA. Neither source dictates a universal lighting role split.

Which lighting deliverables need assigned approval roles?

Assign approval roles to every lighting deliverable that can change design
intent, technical suitability, cost, programme, purchasing or site
acceptance.
Start with the project brief and fixture schedule, then follow the information
through supplier selection, production, installation and handover.

The Centre for Digital Built Britain guidance describes a well-defined responsibility matrix as a key part of an information delivery plan and discusses assigning information-management activities to parties. For a lighting package, that supports treating drawings, samples and evidence as controlled information deliverables, while the project agreement still decides who holds each role.

• Design basis: room intent, fixture type, dimensions,
  finish, light effect, controls intent and coordination constraints.
• Supplier submission: product proposal, deviation list, data
  sheets, drawings, material samples and finish samples.
• Technical evidence: applicable test reports, electrical
  data, driver and control information, mounting loads, maintenance access and
  project-specific compliance records.
• Commercial release: quotation, inclusions, exclusions,
  quantity, delivery terms, approved variation and purchase order.
• Physical verification: prototype or mock-up, pre-production
  sample, production inspection evidence and site sample.
• Site and handover: installation inspection, snag closure,
  commissioning records, as-built information, spare-parts schedule and
  operating information.

A deliverable belongs in the matrix when ambiguity about its status could
trigger rework or an unauthorized commitment. A finish chip and a full
luminaire sample are not the same approval object. If both matter, give them
separate rows, acceptance criteria and release effects. Project images can
help identify the room context, mounting condition and visible coordination
that should be requested in a submission; they are prompts for questions, not
proof that another project’s solution or result applies here. For context,
examine Kinglong Lighting’s relevant project references.

What should each project participant own?

The owner, designer, consultant, contractor and supplier need distinct
responsibilities, but their exact RACI letters must be set by the project
agreements.
The following descriptions are questions to resolve, not assumed contractual
appointments.

• Owner or developer representative: confirms business
  priorities, budget authority, programme trade-offs and the person permitted
  to accept changes on the owner’s behalf.
• Interior or lighting designer: defines design intent and
  reviews visible form, proportion, finish, light effect and integration with
  the interior concept.
• Lighting, electrical or other consultant: reviews the
  technical subjects in its appointment, such as performance criteria,
  coordination, electrical interfaces or controls.
• Main or specialist contractor: coordinates submissions,
  site conditions, programme, installation method, interfaces and formal
  communications within its scope.
• Supplier or manufacturer: prepares accurate product
  information, drawings, samples, technical evidence, deviation disclosures
  and production records for its offered scope.

Do not confuse ownership of information with authority to accept it. A
supplier can be Responsible for preparing a shop drawing without being
Accountable for project acceptance. A contractor can be Responsible for
routing a submission without being authorized to approve a design change.

How do you build the RACI row by row?

Build each row around one deliverable, one decision, one Accountable role,
required evidence, a due date and a release condition.
Use the table as a starter matrix only. Replace every role assignment with the
project’s agreed allocation before issue.

The repeated “Project-defined” cells are deliberate. A generic article cannot
safely assign contractual authority. In the working matrix, each must be
replaced by one named role. If two parties appear Accountable, split the row
into two decisions—for example, visual acceptance and technical acceptance—or
name one final integrator.

For custom decorative packages, identify whether the deliverable is a concept
image, engineering drawing, control sample or production standard. Teams
evaluating complex hotel scopes can use
Kinglong Lighting’s hospitality lighting process
as a prompt for supplier inputs that may need to enter the project matrix.

Why is design approval not the same as technical or commercial approval?

Separate aesthetic acceptance, technical review, contractual authorization
and purchasing because each answers a different question.
Aesthetic acceptance asks whether the proposal preserves the intended
appearance. Technical review asks whether submitted information addresses
applicable criteria and interfaces. Commercial authorization accepts cost or
programme consequences. Purchasing commits the order.

The
AIA overview of architects’ basic services
notes that construction-phase scope is defined by the owner–architect
agreement and describes the architect helping the contractor build from
owner-approved construction documents.
The project lesson is not that one profession always approves lighting. It is
that authority follows the appointment and approved documents.

Put an “approval type” field beside each RACI row. Useful values include
design acceptance, technical comment closure, commercial authorization,
procurement release and site acceptance. Then use a clause-level lighting bid
compliance matrix to keep evidence and deviations visible instead of hiding
them inside a broad “approved” stamp.

An approval may also be conditional: accepted subject to a revised driver
location, owner confirmation of finish, or contractor verification of ceiling
support. Record the condition, the person who closes it and whether production
may start before closure. Without those fields, a conditional review can be
misread as an unconditional release.

How should submissions move through review and escalation?

A controlled submission moves through completeness check, discipline
review, consolidated comments, resubmission, decision and recorded
release.
The document controller should not start the review clock on an incomplete
package if the agreed workflow allows a completeness check. Missing drawings,
sample identifiers or declared deviations should be returned with a specific
reason.

1. Submit: identify deliverable, fixture or area, revision,
   purpose, required-by date and related documents.
2. Check completeness: confirm that the evidence named in the
   RACI row is present and internally consistent.
3. Review: route appearance, technical, commercial and
   site-interface questions to the relevant Consulted roles.
4. Consolidate: remove contradictory instructions or escalate
   them before returning one controlled comment set.
5. Resubmit: show how each comment was answered; do not
   silently replace documents.
6. Decide: the Accountable role records approved, approved
   with conditions, revise and resubmit, or rejected.
7. Release: communicate the status, accepted revision,
   remaining conditions and effect on purchasing or production.

Set escalation triggers in advance: overdue decision, conflicting comments,
requested change outside appointment, unaccepted deviation, cost or programme
impact, or missing approval authority. The destination should be a named role,
not “management.” When a proposal changes scope or value, a
three-party value-engineering review can compare design, engineering and commercial effects before approval. A
value-engineering proposal does not grant permission to copy a protected
design: any alternative must be original or properly authorized, and its
drawings, rights position and acceptance route should be recorded.

Keep a decision log beside the RACI. The matrix says who acts; the log says
what happened. Minimum fields are deliverable ID, revision, submission date,
decision, conditions, accountable person, decision date and downstream
instruction. This prevents old email comments from being treated as the
current status.

How does an approved decision reach purchasing and installation?

Carry the accepted revision, exclusions, quantities and conditions into the
purchase order, production instruction, installation package and handover
record.
Approval is not complete when a PDF receives a stamp; it is complete when
downstream teams can identify the same controlled decision.

The
WBDG commissioning-document guidance
separates preparation, review, approval and use roles and describes updating
commissioning plans with assigned responsibilities.
The
CIBSE Commissioning Code: Lighting overview
treats commissioning as a managed process intended to realize design intent
at completion and inform users about operation.
These sources address commissioning rather than a universal procurement RACI,
but they reinforce the need to connect approval records to use and handover.

Before purchase, reconcile the fixture schedule, accepted drawings, sample
codes, technical exceptions, quantities, accessories, controls interfaces,
spares and delivery scope. Before installation, transfer mounting details,
coordination conditions and current drawings to the site team. At handover,
identify what the operator receives and who closes document gaps. Where a
revised construction requires supplier development, add the relevant prototype
and release gates to the matrix.

Use a release cover sheet when several documents form one decision package. It
should list every governing file and revision, unresolved conditions, the
authority that accepted them, and the exact downstream action allowed. The
buyer can then distinguish “approved for pricing,” “approved for sample,” and
“released for production.” The site team should receive the same status
vocabulary. If a later revision changes only one component, state whether the
earlier approvals remain valid for the unaffected scope instead of asking
recipients to infer it.

What happens when everyone comments but nobody can approve?

Use an illustrative lobby chandelier sample conflict to demonstrate escalation.
The example covers 1 custom chandelier in 1 hotel lobby at pre-production review.

The designer accepts the visible proportions with a finish adjustment. The
consultant requests revised technical evidence. The contractor records both
comments but is not authorized to accept the commercial change. The team has
comments, not a release. Appearance acceptance does not close the
technical request, and neither action authorizes the cost implication. The
correct decision is a full hold on production until the accountable release
authority is identified and receives one complete package.

The supplier reissues the drawing and evidence under a new revision; the
contractor adds the commercial effect; the designer and consultant record
their scoped responses. The named accountable role records the accepted
revision and conditions. The buyer verifies that the same revision appears in
the purchase order and production instruction. This is an illustrative example,
not a Kinglong project or a measured client result.

When should the lighting RACI be updated?

Update the lighting RACI when the procurement route, scope, project phase,
appointed party or approval authority changes, while retaining superseded
versions.
Also revise it when repeated escalations reveal that a row is too broad or an
evidence requirement is missing.

Review the matrix at design freeze, supplier appointment, mock-up or sample
release, purchase release, start of installation and handover planning. A
phase change often changes who is Responsible even when the Accountable
authority remains the same. Record the revision date, change reason, approver
and effective date so teams know which matrix governed each decision.

The matrix should remain short enough to use but specific enough to audit.
Archive obsolete versions; do not overwrite the record that explains an
earlier release. For adjacent questions about samples, compliance evidence and
procurement controls,
Review Kinglong Lighting’s supporting decorative-lighting procurement
guidance.

Frequently Asked Questions

Can one person be both Responsible and Accountable?

Yes, if the project appointment, authority and workload support it. The matrix
should still show both letters explicitly so the team can distinguish
preparation from the final decision. Avoid multiple Accountable roles on one
row. If different authorities must accept appearance, technical evidence or
cost, split the deliverable into separate decisions and record how they
combine into the final release.

Should the lighting supplier approve its own technical submission?

The supplier should prepare, internally check and authorize its submission for
issue, but project acceptance follows the contract and approval matrix.
Internal supplier approval confirms that the package is ready to submit. It
does not replace a consultant’s scoped review, an owner’s authorization or a
contractor’s formal release where those actions are assigned to other project
parties.

Does an approved sample authorize the full production release?

Only if the recorded approval and applicable contract make that release
explicit. Name the sample, revision, accepted attributes, conditions and
production effect. Visual acceptance of finish or proportion should not be
assumed to close technical comments, accept a commercial change or authorize
purchase. When those decisions remain open, mark the sample status as limited
and identify the next approval gate.

What if the contract conflicts with the RACI?

The contract and formal appointments govern. Stop relying on the conflicting
row and escalate it to authorized project representatives. Correct the matrix,
identify the effective revision and communicate it before the affected
approval proceeds. Preserve the old version with the decision record so
earlier actions remain traceable. The RACI is a control tool, not a
replacement for the agreement.