A performance-based streetlight specification states the project outcomes and verification evidence an agency needs. A prescriptive specification states required product attributes, components, or construction details. For municipal streetlight procurement by cities and transportation agencies, a hybrid can be useful when measurable outcomes and documented constraints both apply.
This distinction matters because a streetlight is evaluated in a real setting, not in isolation. Road geometry, mounting arrangement, background conditions, controls, maintenance practices, and local requirements can all affect what an agency needs to document and verify. The right structure helps a procurement team explain the need, compare submittals consistently, and avoid treating a product data point as proof that a complete lighting design is suitable.
Key takeaways
- Use a performance-based streetlight specification to describe the results the project must demonstrate and the evidence required to demonstrate them.
- Use a prescriptive lighting spec for narrowly justified interfaces, maintainability needs, environmental conditions, or installation constraints.
- A hybrid specification can separate outcome requirements from non-negotiable project constraints.
- Define the calculation, documentation, review, and field-acceptance path when the solicitation is written, not after bids arrive.
- Confirm the current standard edition, exact product configuration, contract terms, and jurisdictional requirements before making a procurement decision.
How a performance-based streetlight specification changes procurement
A performance-based streetlight specification starts with what the agency needs the lighting installation to accomplish and how that result will be evaluated. It does not simply list a preferred housing, optic, or product family. The specification may identify the relevant lighting criteria, the calculation area or measurement locations, the project assumptions, the documents a proposer must provide, and the acceptance process.
That approach does not remove engineering judgment. It makes the required judgment visible. A roadway or public-space project may need different criteria because its geometry, ambient conditions, uses, and governing requirements differ. A performance requirement is useful only when it is specific enough to be tested against the project conditions.
Define the required result before the product attributes
Start with the project conditions: roadway type, lanes, intersections or crossings, pole locations, mounting constraints, nearby uses, operating schedule, maintenance responsibilities, and applicable agency rules. Then identify which outcomes the design must support and what evidence will be used to review them.
For example, an agency may require a lighting calculation for the actual layout rather than a generic luminaire summary. That is a meaningful distinction. The Federal Highway Administration’s archived report on midblock crosswalk lighting explains that luminaire selection and placement, mounting height, background conditions, and vertical illuminance affect the evaluation of that specific application. It is not a universal streetlight template, but it demonstrates why geometry belongs in the evidence package rather than being assumed from a headline fixture value. See the FHWA lighting-design report for its scope and limitations.
The specification should name the result in a way the agency can assess. Depending on the project, that might mean a documented calculation, a defined review area, a stated operating condition, or a field acceptance procedure. It should not copy a number from an unrelated project or present a general article as a substitute for a current, applicable design standard.
In practice, a performance specification for roadway lighting should identify the project outcome, evaluation method, and evidence needed for review. It should also state the assumptions that make the evidence meaningful, such as the layout being evaluated and the operating condition under consideration. Without those boundaries, two submittals may appear comparable while relying on different inputs.
Specify how the result will be demonstrated
A performance requirement without a proof path invites inconsistent submittals. A practical solicitation tells bidders what they must submit, who evaluates it, and what makes the evidence complete. Typical evidence may include project-specific calculations, drawings, photometric files where relevant, a bill of materials, control-system information where applicable, and model-specific technical documents.
The evaluation method should also distinguish between a design assumption and an acceptance requirement. A calculation may be appropriate before award; a field check may be appropriate after installation; and a warranty or listing question may require a current contractual or listing document. Those are different kinds of evidence and should not be collapsed into one generic “compliance” statement.
Consensus guidance also needs careful handling. The Illuminating Engineering Society standards program describes an ANSI-accredited consensus process, but a public overview page does not establish a project criterion or prove that a luminaire complies. Identify the current, applicable edition in the procurement documents and have the responsible agency or qualified professional determine how it applies.
What belongs in a prescriptive lighting specification?
A prescriptive lighting spec identifies a required attribute, component, configuration, or process. Prescriptive language can be appropriate when an agency has a documented reason to protect an existing interface, installation condition, operations workflow, maintenance practice, or procurement constraint.
The question is not whether prescriptive requirements are inherently good or bad. The question is whether each one is tied to a real project need and can be reviewed fairly. A requirement that is essential for a pole interface, a control architecture, an environmental exposure, or safe maintenance access may be necessary. A requirement carried forward only because it appeared in an older template deserves a second look.
Appropriate uses for justified constraints
Prescriptive requirements are often most useful when they define a boundary that an outcome calculation cannot capture by itself. A project may need a specific physical interface to work with existing infrastructure. It may need a defined documentation format for asset records. It may have a maintenance workflow that requires a particular access or replacement approach. It may have an installation condition that must be addressed before a luminaire is evaluated.
Write the reason alongside the requirement during internal planning, even if the final solicitation uses a more concise form. That discipline helps reviewers distinguish a necessary constraint from an inherited preference. It also helps the team decide whether an alternate can meet the same need.
Prescriptive language should not imply product certification, lifetime, ingress protection, warranty coverage, domestic-content eligibility, or other model-specific facts unless the solicitation requires current evidence for the exact configuration. A general explainer or category page cannot establish those facts.
Risks of over-prescribing
Over-prescribing can make the evaluation focus on a list of attributes rather than the project outcome. It can also create ambiguity when a listed attribute conflicts with a calculation, a drawing, or a current standard. This is a procurement-design risk, not a conclusion about any particular manufacturer or bid.
Before keeping a prescriptive item, ask three questions: What project problem does it solve? What evidence shows that an alternate would not solve it? Who will verify it? If the team cannot answer those questions, consider whether the requirement belongs in an internal preference list rather than a mandatory streetlight specification.
When a hybrid specification is the practical choice
A public-infrastructure procurement can use a hybrid structure when measurable outcomes and justified constraints both need to be addressed. The key is to keep the two categories separate.
Separate outcomes from non-negotiable constraints
One section can state the required results and evidence: project-specific calculations, stated assumptions, and acceptance steps. Another can state justified constraints: compatibility, installation conditions, records, maintainability, or approved controls interfaces. This separation makes it easier for a bidder to understand what must be achieved and what must be provided.
It also helps reviewers avoid an all-or-nothing conversation. A proposed product might meet a physical constraint but lack sufficient design evidence. Another may supply calculations but omit required documentation. A clear hybrid structure lets the agency identify the issue precisely.
Build a submittal and verification matrix
A simple matrix can make the solicitation easier to administer. Use columns for the requirement, the project-specific metric or constraint, the submitted evidence, the responsible reviewer, and the acceptance step. The matrix is an editorial planning tool, not a substitute for an agency form or a contract review.
| Requirement type | What to define | Example evidence | Review question |
|---|---|---|---|
| Design outcome | Project area, conditions, and evaluation method | Calculation and drawing set | Does the evidence use the stated project assumptions? |
| Physical or system constraint | Documented interface or installation need | Model-specific documentation | Does the proposed configuration address the stated constraint? |
| Documentation | Required revision, format, and model identification | Submittal package | Is the record current and complete for the offered configuration? |
| Acceptance | Inspection or field-check process | Commissioning or acceptance record | Was the agreed process completed under the contract? |
The matrix does not establish technical requirements by itself. The responsible agency, procurement team, and qualified design professionals still determine the criteria, evidence, and approval authority for the project.
For municipal streetlight procurement, the team can assign each matrix item to the party best positioned to address it. An agency may define the project need and acceptance authority; a qualified design professional may review the design basis where engaged; a bidder may supply the requested evidence; and an installer may provide closeout records under the contract. Those roles vary by jurisdiction and delivery method, so the solicitation should state the project-specific responsibilities rather than assume a universal workflow.
How to evaluate streetlight submittals
Submittal review should follow the structure of the specification. Start with the project assumptions, then review the evidence against the requirement. Avoid using a luminaire’s maximum output, a family-page statement, or a generalized marketing claim as a proxy for the proposed configuration in the actual layout.
Verify the lighting design in its actual geometry
Geometry is part of the design. The FHWA crosswalk report is useful here because it shows that changing the luminaire placement or mounting height can change the evaluated result in a defined application. It does not set a universal value for streets, intersections, or public spaces. Instead, it supports the broader procurement lesson: require evidence that matches the project geometry and the relevant visual task.
When reviewing a calculation, check the stated layout, mounting assumptions, calculation area, operating condition, and any limits defined in the solicitation. If a condition changes during design or construction, determine whether the evidence needs to be updated. That is more defensible than relying on a product label alone.
For readers who need foundational terminology, LEOTEK’s lighting measurement guide explains watts, lumens, and lux. Those terms are useful inputs, but lumens alone do not determine the lighting result at a particular roadway location.
Confirm model-specific documentation and project assumptions
Ask for the exact model and configuration proposed, with current documents that match it. Confirm the document date or revision where available. Keep listing, warranty, installation, electrical, controls, procurement, and contract questions in the evidence category that can answer them; do not infer them from a lighting calculation.
Distribution is another example. A distribution label can help describe how light is directed, but it does not by itself prove suitability for a layout. LEOTEK’s overview of IES light distribution types is suitable further reading; the project still needs applicable criteria and project-specific review.
A procurement checklist for municipal and agency teams
Before issuing a luminaire solicitation, use this checklist to organize streetlight specification requirements and test whether they can be evaluated as written:
- Document project conditions. Identify the location, geometry, operating context, existing infrastructure, maintenance responsibilities, and applicable local or agency requirements.
- State the outcomes. Define what the design must demonstrate and the method used to evaluate it. Avoid importing targets from an unrelated application.
- Limit prescriptive constraints. Retain only the interfaces, installation conditions, service needs, or records that have a documented project purpose.
- Name the evidence. Require the calculations, drawings, photometric information, model identification, and current documents needed for each review decision.
- Assign reviewers. Clarify who evaluates design evidence, documentation, contract compliance, and field acceptance.
- Plan for changes. State when a revised layout, mounting condition, or offered configuration requires updated evidence.
- Define handover. Specify the records, documents, and acceptance materials the owner needs at closeout.
This checklist is not engineering, legal, or procurement advice. It is a way to organize questions before the responsible agency and qualified professionals finalize the solicitation.
For general category orientation, see outdoor lighting applications. Use current, model-specific records rather than this category page to validate a proposed product’s specifications or compliance status.
FAQs
What is the difference between a prescriptive and performance-based streetlight specification?
A prescriptive specification states the required attributes or configuration. A performance-based specification states the required outcome and how it will be verified. A hybrid can do both when the prescriptive items have a documented project purpose.
When should a municipality use prescriptive requirements for luminaires?
Use them when a specific interface, installation condition, maintenance need, or documented project constraint must be met. The agency should be able to explain the purpose and review method for each mandatory requirement.
What performance evidence should a roadway-lighting submittal include?
The evidence should match the solicitation and project. It may include a project-specific calculation, drawings, stated assumptions, model identification, and current documentation. The responsible agency determines the required evidence and review process.
Can a streetlight specification use both performance and prescriptive requirements?
Yes. A hybrid structure can state measurable outcomes separately from justified constraints. Keeping those sections separate makes submittals and review decisions easier to understand.
How should an agency verify a proposed lighting design before award and at acceptance?
Define the evidence, reviewer, and decision point in advance. Review project-specific design documentation before award, then use the contract’s defined inspection or acceptance process after installation. Current standards and jurisdictional requirements govern the final approach.
Choose a specification structure that can be verified
A performance-based streetlight specification focuses the procurement on outcomes and proof. A prescriptive lighting spec protects the constraints the project genuinely needs. A hybrid can bring both together when every requirement has a clear purpose, matching evidence, and a defined reviewer.
Once the team has defined its criteria, it can review LEOTEK technical documents for current product specifications and verify the applicable model, revision, and project requirements before making a procurement decision.
References
- Federal Highway Administration, Informational Report on Lighting Design for Midblock Crosswalks, FHWA-HRT-08-053, 2008; accessed July 26, 2026.
- Illuminating Engineering Society, Standards; accessed July 26, 2026.
- LEOTEK, Applications for Outdoor Lighting; accessed July 26, 2026.
- LEOTEK, Watts to Lumens; accessed July 26, 2026.
- LEOTEK, IESNA Light Distribution Types I, II, III, IV and V; accessed July 26, 2026.
- LEOTEK, Resources and Documents; accessed July 26, 2026.
