Two matching addresses call for a question before a change
You see address 101 in two rows of a lighting sheet. Before correcting one, check the universe and what each column identifies: the fixture number is not necessarily its address. Keep that distinction alongside the documented mode and channels.
This guide proposes trialling a text assistant to prepare a discrepancy list before programming. You will use fictional documents and a manual reference. AI will not connect to the console, assign new addresses or decide that equipment works correctly. We have not run the pilot or measured results.
Prepare the documentation that defines your patch
Here, a patch sheet means the documented list of fixtures, universes, addresses and modes. Lightkey explains that the profile must match the model and that fixture and software modes must agree. It also asks for the manufacturer’s DMX chart and advises against generating it with AI.
QLC+ 4 documentation distinguishes mode, universe, address and channels; it warns of overlaps when replacing fixtures whose channels do not match. These sources describe their software: they neither certify your rig nor show that an assistant can review it without errors.
Work from an authorised copy of the list and identified extracts from the actual manual where relevant. If a mode is missing or versions conflict, prepare a question for the responsible person; do not fill the gap because another fixture has a similar name.
- Identifier: retain the number or name your team uses. Keep that label separate from the DMX address.
- Universe and address: preserve both fields and the original notation. Do not translate numbering between software or interfaces without a documented mapping.
- Model, mode and channels: link each value to its source and version. Do not infer a channel layout from the fixture’s appearance.
- Document status: distinguish plans from readings checked by the technician. An exported sheet alone does not establish the physical configuration.
The case: a harmless match, an overlap and an unknown mode
Everything below is invented: fixtures, modes, documents and notes. This is not a patch to import or use at an event. P1 is a planning list, version 1, containing the five table rows. In this exercise, U1 and U2 identify different universes. M6, M4 and M8 are fictional mode names, not manufacturer profiles.
The ranges are supplied in P1 as exercise data. AI must neither calculate nor fill missing ones. N1, a technician’s note linked to row 15, says “mode M8”; it supplies neither channels nor a range. No decision resolves its disagreement with P1. There are no physical readings for the other rows either.
| Fixture ID | Universe / address | Declared mode and channels | Range supplied in P1 |
|---|---|---|---|
| 11 | U1 / 101 | M6 · 6 channels | 101–106 |
| 12 | U1 / 105 | M6 · 6 channels | 105–110 |
| 13 | U2 / 101 | M6 · 6 channels | 101–106 |
| 14 | U1 / 121 | Mode and channels not supplied | Not supplied |
| 15 | U1 / 141 | M4 · 4 channels | 141–144 |
What the review list should flag
Manually written reference: “P1 rows 11 and 12: within U1, the supplied ranges share 105 and 106. Review with the responsible person; do not change addresses.” This is a documented match requiring checks, not a diagnosis of an observed fault. There is no evidence attributing physical behaviour to it.
“Rows 11 and 13 share an address number, but P1 places them in U1 and U2; that match across different universes does not constitute the same documented overlap.” Do not turn this limited conclusion into “rig correct”: actual configuration and other checks remain outside it.
“Row 14: mode, channels and range need confirmation; request documentation.” “Row 15: P1 declares M4 and N1 says M8; ask the technician which value has been checked and which version needs updating.” Do not erase P1, mark M8 as confirmed or extend the range intuitively. Retain both sources until resolved.
An instruction for preparing questions without touching the console
Paste only fictional P1 and N1 alongside this instruction. If you trial Claude, its documentation warns of potentially incorrect or context-inconsistent replies and advises allowing it to acknowledge uncertainty. The instruction below is a proposed trial, with no guarantee of compliance.
“Review only these fictional documents. Preserve ID, universe, address, mode, channels, supplied range and source in separate fields. Compare only explicit ranges within the same universe; do not invent or recalculate ranges. Return documented discrepancies with rows and quotations, missing information and a specific question for each point. Distinguish planning from physical verification. Do not decide which conflicting source is correct. Do not generate profiles, DMX charts, commands, a new patch or import files. Do not control equipment or declare the rig validated.”
Check the output against the reference above and the original documents. If it mixes U1 and U2, treats the ID as the address, fills row 14’s mode or resolves row 15 on its own, retain the failure and correct the process before using the draft. Physical checks, programming, electrical safety and rigging belong to responsible professionals and fall outside this exercise.
Compare with a spreadsheet before requesting integration
For numerical matches, start by comparing with manual review and checks in your software or a spreadsheet. Reserve the AI experiment for organising notes and explaining document conflicts. A table and shared procedure may be enough.
In a copy of the case, change only U2 to U1 in row 13: its supplied ranges now match row 11 within the same universe. Then restore the original and remove only row 12’s range: comparison of its channels must remain unresolved, without reconstructing the range from M6. These are proposed review checks, not results from an executed trial.
- Count omitted documented discrepancies, false alarms across universes, invented data and conflicts closed without a source.
- Record technician preparation, cross-checking and corrections; compare with the complete manual procedure. Do not measure only how quickly text appears.
- Agree which errors require discarding a draft. Do not import assistant outputs or use the pilot as technical acceptance of an installation.
A defined development scope: document review with technical decisions retained
The manual trial means copying fictional data and reviewing text. Automation would require checking permissions, export formats, identifiers, versions and responsibilities. Do not assume connectivity with Lightkey, QLC+, your console or inventory.
With Adaris, you could assess an internal tool gathering authorised lists and notes, retaining their sources and preparing outstanding questions for technician approval. Feasibility, accepted inputs, acceptance criteria and a quote would need agreement. Adaris develops custom software and AI integrations case by case; this proposal is not an existing lighting product.
Use fictional trial data. Before using real plans, inventories or commercial documents, check permissions and appropriate access, use and retention conditions. To discuss the case, describe the workflow without customer data or private files. Commercial support is in Spanish.
Related services
Sources
Do the patch and team notes tell different stories?
Describe how you prepare the documents and who resolves discrepancies. We can assess a defined internal review; commercial support is in Spanish.