The File That Should Remember

A lighting event draws to a close, the hall empties, the technical equipment is struck. What remains often fits on a USB stick or in a folder in the cloud: a show file, known in the trade as a showfile. It reflects neither the size nor the configuration of the lighting rig it belongs to, nor the face of its creator. Yet it can hold the result of many weeks of work. It contains lighting moods, transitions, sequences, timings, effects and decisions that the audience does not perceive as programming, but as an integral part of the event itself.

Once this work has been saved, it can be copied, renamed, passed on and altered with ease. What is often not passed on, however, are the names of its authors, the circumstances of its creation and the limits of any agreed use.

The ZentrumNeueLichtkultur (ZNL) therefore raises a question that hides behind the technical, taken-for-granted nature of file management: why can highly developed lighting control systems map the most complex sequences, yet cannot reliably prove the origin or the stated context of use of that data? The ‘Showfile Seal’ initiative aims to close this gap. It is not addressed only to lighting programmers. It concerns theatres, promoters, production companies, lighting designers, art institutions, training establishments and manufacturers of control systems. Above all, though, it touches a fundamental cultural question: which work do we make visible, and which do we treat as a resource whose availability is taken for granted?

Between Design and Operation

Anyone who programs lighting does not content themselves with mechanically implementing a given plan. Of course such tasks exist: configuring addresses, connecting fixtures, calibrating luminaires, checking technical function. But the practical work often goes far beyond that. A lighting designer describes an effect, a dramaturgical idea or even a development over time. The person responsible for programming translates this into a structure that can be reproduced under real conditions and at the same time can be played live. They decide how transitions flow into one another, whether an effect suits the music, how movements articulate themselves in space and how the desired visual effect can be achieved or preserved even after a sudden intervention. Sometimes the decisive creative impulse arises precisely from this process.

Even so, lighting design, programming and lighting operation are not necessarily one and the same activity. At events these tasks may be taken on by one and the same person; in a large theatre they are handled by different members of staff. A lighting operator runs a performance, improvises within set limits and responds to musicians, actors or unexpected situations. Whoever then develops the performance further helps to write its practical history. A rigid opposition of ‘creative’ and ‘technical’ does not do sufficient justice to this professional reality. Timing is no less creative because it is measured in seconds. A logical dependency does not lose its dramaturgical character simply because it is executed in the form of a macro.

The showfile documents the results of this work. Whether this file, or parts of it, is protected by copyright as a work in a specific case is a separate legal question^2,3. The ZNL takes the view that the ‘showfile’ is to be regarded as a work. This thesis rests on a cultural-policy position and professional expertise; it is not a court decision that could be replaced by a technical marker. For precisely this reason the preparatory step is worthwhile: document before a legal dispute arises. A reliable history of creation and changes remains useful even if later legal assessments diverge.

When the Client Complains: Whose Programming Is Actually Running Here?

Imagine a fixed installation. A specialist sets up the control system, programs the installation, tests the sequences and hands the client a working state. A year later the complaint arrives: the programming is faulty. On site it turns out that a third party has made changes in the meantime. Without a secured handover state, the dispute easily stays at the level of assertions. Who changed something? When did it happen? And for which state did the original programmer actually take responsibility?

A seal could confirm a reference state here. It would identify neither the person who made a change nor the time of the change; a deviating hash value merely shows that something has changed. It could, however, reliably indicate whether the file in question still corresponds to a documented state. This is not a romantic view of the work’s authorship, but pragmatic quality assurance. The same logic helps technical support for lighting consoles and the transfer or handover of long-lived installations.

Another case arises on tour. A programmer leaves the production following a conflict. A few months later they see pictures of the performance, or attend it themselves, and gain the impression that the dramaturgy they programmed is being carried on unchanged. Perhaps this continued use was provided for by contract, perhaps not. What matters first of all is that a showfile without clear indications of origin is often in circulation as if it had no past. A seal could state who contributed to the original version, which use was registered and on which version the work was subsequently continued. This would not replace a contract and would not automatically lead to payment. But it would make it possible to move the discussion out of the realm of mere recollection.

The same applies to revivals. A production is budgeted and planned for a certain number of performances. After a break, the same file is to enable a new run. The file does not show whether an additional commission, a permission or a fee was intended for this. A documented production reference and a clearly defined scope of use could ensure that this question is asked in good time, before the revival and not only after the conflict.

The Institution and the People Within It

In municipal and national theatres, opera houses and other permanent institutions, showfiles are often created under a permanent employment contract. The venue may be entitled to dispose of their use, while it was individual employees who did the actual programming work. These two aspects are not identical. A meaningful seal must therefore go beyond merely entering a person’s name in a field. It should make it possible to identify an institution as the body entitled to use the file and, at the same time, to highlight the people involved and their respective roles.

This does not only protect the staff. The institution, too, benefits when handovers of responsibility after a change of personnel can be traced: who knows the original architecture? Which version was approved? Which changes were made in later revisions? In an ensemble house or in a long-maintained repertoire production, the version history is not personal property but part of the institutional memory. Technical documentation thus also becomes a task for the cultural organisation.

One must not, however, confuse roles with legal status. ‘Programmed by’, ‘Designed by’, ‘Operated by’, ‘Published by’ and ‘Authorised to use’ denote different facts or statements. A clear and comprehensible model is needed, without burdening every project with forms. The information itself can also give rise to controversy. The seal should make it possible to establish who made which declaration, and should not give the impression that a simple entry settles the entire legal position once and for all.

The Show Changes, and Is Allowed To

A lighting system is not a picture behind glass. At concerts the staging evolves over the course of weeks: an effect gains precision, a movement becomes more musical, a transition is shortened. A show is adapted to other halls and stages. The patch, the rig and the available equipment vary, while the dramaturgical core remains recognisable. Guest technicians make their own adjustments. At festivals, files are imported, structures merged and elements from earlier productions reused. The idea that there could be only a single, unchangeable original file does not reflect this lived practice.

The seal must therefore not be a lock. Its purpose is not to prevent every change after the first save. The original state must remain recognisable; every legitimate change receives a new seal that is linked to the original. Where several parties are involved, or where versions are merged, this can go beyond a simple linear chain. From a technical point of view, an origin structure would be required that can, where necessary, refer to several previous versions. In daily use, however, the way it works could remain simple: deliberately save a version, allow changes and then save a new version.

At this point a great temptation arises: why not ‘seal’ every cue, every preset and every effect library individually? Many programmers reuse their personal macros, scripts or sophisticated effect generators from one production to the next. Their origin would certainly be relevant. But a system that prescribes a documentation duty before every import is doomed to fail in the hectic reality of production. Time there is not a minor problem but a scarce operational resource. The individual sealing of modules should therefore at most be a later and optional extension. The overriding practical priority remains the simple and uncomplicated safeguarding of the entire showfile and its most important stages of development.

A Fingerprint Is Not Handwriting

How could this work? In its technical concept, the ZNL describes three steps: freezing, sealing and verification. First, a defined state of the file is fixed. On this basis, a digital fingerprint can be calculated using a cryptographic hash function such as SHA-256⁴. This fingerprint is linked to a data record that contains, among other things, information on the author, where applicable on the rights holder, the stated terms of use, a declaration on AI, version details and proof of date. If the file is checked at a later point, a new fingerprint can be compared with the stored value.

The wording sounds simple, but the practical implementation has pitfalls. Some lighting control systems change internal data when saving, without this having any artistic relevance. If the seal is shown as broken after every automatic save, the result is a warning system with no informational value. Manufacturers and developers must therefore clarify which data state is actually comparable and what counts as a relevant change. A SHA-256 value identifies a specific data state, but neither a person nor the time at which someone made changes. To obtain a reliably attributable declaration, suitable signatures are needed and, for proof of time, where possible a reliable timestamping service⁵. Offline working must not be ruled out in this context.

Two routes to implementation come into consideration in the current concept. A manufacturer-independent tool could initially be used externally: export the showfile, create a digital fingerprint and send a small companion file together with the showfile. In principle this route is conceivable for many lighting control systems, but there is a risk that the companion file gets lost. In the second approach, manufacturers build the seal directly into their lighting desks: they display it, check it on loading, generate new versions and preserve the information on import and export. Both approaches must be based on an open, jointly usable specification. An external proof should not lose all of its value when switching to an integrated solution.

The draft pages¹ published in October 2026 show, by way of illustration, user interfaces for grandMA3, ChamSys MagicQ, ETC Hog and Avolites Titan. These representations are simulations and do not correspond to functions already available from the manufacturers. Likewise, the interactive hash demonstration is not yet an operational infrastructure for secure signatures. The distinction between demonstration, specification, prototype and actually supported product must remain clearly recognisable to the public. Anyone who wants to build trust must describe the maturity of their own technology very precisely.

When the File Is Unchanged and the Show Fails Anyway

The digital fingerprint reflects only part of reality. A permanently installed system can suddenly behave unusually after a software update, even though nobody has changed the showfile. Compatibility problems between different software versions are a failure case in their own right. The exact version of the lighting console software, captured automatically at the time of sealing, must therefore be listed as a mandatory entry in the future test report. The manufacturer and the system type come on top of that. Manual capture would be error-prone and, given the already high production pressure, unnecessary.

It is important to draw the following distinction: the version under which a showfile was sealed is not necessarily the same as the one under which it last ran without fault. To reproduce a fault, it may be necessary to have, or to have defined, an approved test or transfer status in addition. Media servers, timecode, tracking systems, network components and automation systems can create further dependencies. Not all of these elements need necessarily be mandatory fields; for certain projects, however, an optional environment certificate can be decisive. The seal thus serves not only as a statement of origin but also becomes a tool for professional maintenance and fault-finding.

For safety-relevant applications the boundary must be especially clear. A seal can refer to a verified configuration state or to external acceptance documents. In itself it is neither a safety inspection nor an operating permit. If changes are made to the installation, a valid hash value does not automatically guarantee that all risks remain under control. The traceability of a file and the safety of a technical system remain two separate categories.

When Technology Becomes Cultural Memory

In the field of light art and long-term installations the problem sharpens further. A controller fails after several years, the luminaires are no longer available, an old file can no longer be opened on the new lighting desk. The installation is repaired technically, and sometimes the programming has to be completely rethought. What needs to be preserved here is not only a functioning technical system but an artistic expression with a very particular rhythm, light distribution and dramaturgical idea.

A documented original version can help to explain later interventions during restoration. A reconstructed file is not identical to the historical original; it can, however, deliberately refer to it. The same applies to theatre archives, in which productions are revived after years or even decades. Anyone who regards this data merely as a transient software configuration underestimates its documentary value. The showfile could be part of the archive of the work, together with its names, its context and its changes.

Educational institutions benefit too. Teachers provide the framework, students and trainees develop independently, and groups work together on shaping a performance. Some ideas then flow into professional productions. Appropriate documentation of contributions can help to acknowledge the work without pushing young people into constant self-assessment. The protection of personal data must be taken into account, especially in the case of minors and confidential projects. The use of a pseudonym or gradual visibility should be possible; a public register of all programming steps is precisely not the goal.

The AI Question Runs in Two Directions

Showfiles, too, are datasets that may be of interest to AI systems. They contain patterns: dramaturgical sequences, the logic of effects, response structures, temporal relationships. In the ZNL’s view, the question of whether and under what conditions they may be used for training, for evaluation or for generating new content must not be decided silently⁶. The Showfile Seal therefore provides machine-readable declarations for various purposes of use: generative learning, other forms of learning, use as a model, data exploration, manufacturer-related services and non-commercial research. For each area the statuses ‘not permitted’, ‘restricted’ and ‘permitted’ are provided; in the absence of express consent, the concept defaults to ‘not permitted’.

The initiative takes the following position: it is for the programmer to decide whether their own programming work may be used for AI purposes, even if the source file was created within an institution. This is first and foremost a normative demand and not a general statement about the current legal position. Particularly in teamwork, it must be clarified how the various declarations relate to one another and which third-party rights have to be taken into account. A permission of use granted by an institution and the declaration of a person who permits the use of their contribution for AI purposes are, in any case, not simply the same information.

Equally important: such a declaration is not technical copy protection. Anyone with access to a showfile can still attempt to misuse it. The seal certifies the declared will to protect the version in question and, where applicable, a reliable point of reference. Whether this reservation is valid and applicable in a specific legal context has to be examined independently⁷. Transparency must not be confused with complete control.

And the following question arises: what would happen if an AI had itself been involved in the programming? If a language model writes a macro, proposes effect logic or generates data structures, this changes the description of the creative process. An optional note that the creation was supported by an AI could prove useful. This would be something quite different from permission to use an existing showfile to train a third-party AI. These two cases must be documented separately. Here, too, there is no obligation to archive every command or to monitor every creative step. An understandable explanation of the process is more useful than a supposed precision that nobody can sustain in everyday work.

An Invitation to Manufacturers, Not an Accusation

The Showfile Seal will only have a meaningful effect if it is integrated into the control systems. Manufacturers such as MA Lighting, ChamSys, ETC and Avolites know their proprietary data formats, import processes and security mechanisms better than anyone else. This initiative is therefore based on dialogue: where can the metadata be integrated? How are they preserved when saving and exporting? Which interfaces are suitable for an external solution? Which integrity information is already available?

The European Cyber Resilience Act (CRA)⁸ can serve as a starting point for these discussions, since the protection of the integrity of digital products is becoming increasingly important in regulatory terms. It does not, however, require a special field for the identity of a showfile’s author, nor does it prescribe the ZNL Showfile Seal. It would be wrong to derive from the technical security requirements a direct legal obligation for manufacturers to implement this project. This bridge is an opportunity to develop an architecture together, not a legal claim.

Manufacturers could benefit from higher-quality support information, clearer handovers and a reduction in unresolvable legal disputes. At the same time, the storage format, maintainability, signing keys, offline use, data protection and backward compatibility would pose development challenges. An open, manufacturer-independent standard should take these questions seriously instead of hiding them behind a pretty logo. Not all manufacturers will be able to offer the same functions at the same time. The goal must be interoperability, not an obligation to identical user interfaces.

Not Defending the File, but Making the Work Inside It Visible

In the end the debate leads back to its starting point. The light of a performance is fleeting, its programming is not. It can be altered in operation, transferred to another stage, restored from an archive or reused in a new production. All of these processes are legitimately possible. It becomes problematic where the memory of the people, their contributions and the terms of transfer disappear along with the file.

A seal alone cannot resolve this contradiction. It can neither judge artistic quality, nor replace a contract clause, nor automatically establish a right. It can, however, create a linguistic and technical precondition that has been missing so far: a common and verifiable point of reference. Whoever records the state of affairs fixes responsibilities. Whoever ties their development to its origin honours the groundwork. Whoever explicitly documents approvals makes visible decisions that would otherwise vanish between emails, the tour bus and day-to-day production.

The decisive criterion will therefore not be whether it is possible to design a particularly complex seal. Rather, it is a matter of establishing whether it can be applied within a few seconds without disrupting live operation, and whether it remains understandable years later. In an industry where fractions of a second and highly precise control data matter, the documentation of human achievement should not fail precisely because a name, a date and a traceable history are missing.