1. Start with the question the file must answer
Write down whether the file is being considered for a layout study, comparison, tender submission, internal review or other project decision. It is not a universal quality badge and it does not answer every product question. Name the intended application, mounting arrangement and decision owner so that a later file request has a clear purpose.
2. Confirm the product identity
Ask for the exact model identifier, product family, revision and configuration represented by the file. Record relevant options that could change the optical result, including optic, light source, control state, mounting and any stated accessory. If the proposed order differs from the file’s identity, make that mismatch an explicit question. Do not infer equivalence from a similar appearance, product image or neighbouring model.
3. Preserve the file and source trail
Save the received filename, issue date if shown, source organisation, request date and any accompanying statement. Ask whether the sender can identify how the data was generated and whether a revision supersedes it. Keep the original transmission with the project record. A renamed file without provenance is much harder to review than one attached to its source and configuration.
4. Check the import, then check the meaning
Open the file in the intended design workflow and note any import warning, missing field or unusual display. Importing is not validation of a project result. Compare the visible model name and available metadata with the written proposal, then ask the preparer to explain a discrepancy. Use site geometry, mounting and criteria from the solar-design brief rather than treating the photometric file as a complete site design.
5. Keep photometry separate from other evidence
A photometric file does not by itself establish product availability, construction, environmental suitability, document scope, destination acceptance or commercial terms. Ask for each requirement separately and keep it tied to the exact model and configuration. Use the quality and documents page to check named models and stated document scope alongside your project record.
6. Ask what a project study assumes
If the file is used in a lighting study, request the geometry, mounting layout, maintenance assumptions, control state, selected criteria, software version and revision history. Identify every input supplied by the buyer and every input chosen by the preparer. This makes the result reviewable and avoids presenting an output as a promise outside its stated conditions.
7. Know the format context
The Illuminating Engineering Society lighting library provides lighting-related standards and resources. It does not authenticate a particular file, approve a product or confirm that a file meets a project requirement. Ask the project reviewer which file format and evidence are required for the intended workflow.
Limits and next step
Ask which IES or LDT files and calculation services are available for the exact candidate configuration. Confirm the required lighting level and project approval process separately. Record missing evidence and have the project reviewer decide whether the supplied information is sufficient.
Make the request traceable.
Tell us the model or application under review, intended site use and the file or evidence question. Attach source files only through the channel agreed for the enquiry.