The Special Case as a Stress Test for the Standard

What exactly is a standard?

At first glance, the question seems simple. In practice, however, it often leads to discussions and misunderstandings. A standard is frequently understood as something fixed: a catalogue solution, a repeatable detail, or a system that has already been fully developed and only needs to be applied.

In my daily work, I encounter a more nuanced reality.

A standard is not necessarily a finished solution for every possible situation. It can also be a system logic: a reliable framework within which new tasks can be solved efficiently, safely and in a controlled manner.

This is where the interesting space between standard and special case begins.

A special case is not automatically something entirely new. Often, it is a deviation from a familiar situation. The decisive question is therefore not only: Is there already a finished solution for this? The more relevant question is: Is there an established system whose logic is robust enough to absorb this new situation?

This way of thinking is strongly shaped by efficiency, pragmatism and lightness. It becomes particularly relevant where textile building envelopes have to be planned, manufactured and installed under significant time pressure.

Three Projects, One Common Pattern

In recent years, we had the opportunity to realise several remarkable structures for the Nova Fundaziun Origen. Three projects illustrate this topic particularly well: the Gelateria Mulegns, the open-air stage in Lantsch/Lenz and the open-air stage on the Julier Pass.

At first glance, these were very different tasks. On closer inspection, however, they shared striking similarities.

All three projects had an extremely tight schedule. Planning, production and installation had to be completed within only a few weeks. All three projects were based on a timber structure. And in all three cases, the weather-protective or translucent layer was to be created using a membrane.

At the same time, none of these situations could be solved by simply applying a fully finished standard solution.

The Gelateria Mulegns was built as a visitor centre and for the opening ceremony of the White Tower in Mulegns. The membrane had to form a sealed envelope with a high degree of transparency. The building envelope was based on a façade system that had already been used by Bieri for many years. For this project, however, a material was used for which only limited experience was available. The total membrane surface was approximately 280 m². From order placement to opening, just over four weeks passed. The preliminary feasibility study was carried out within roughly one week.

For the 1524 open-air performances marking the 500th anniversary of the Free State of the Three Leagues, a timber open-air stage was built in Lantsch/Lenz. We created a roof membrane of approximately 630 m² using tent construction principles. The membrane served as weather protection and as a translucent rooflight. Here too, the total lead time from order placement to commissioning was around four weeks.

For the open-air performance “Hannibal” on the Julier Pass, another temporary timber stage was built and covered with a textile roof membrane. In this case, the membrane surface amounted to just over 1,040 m². The time from order placement to commissioning was around six weeks. The feasibility phase lasted only about two weeks; in essence, a few conversations were sufficient to clarify the basic viability of the project.

This raises an obvious question: How can this work? How is it possible to move from order placement to a fully installed building envelope or roof within only a few weeks?

Speed Does Not Start with the Project

First of all, it should be said that projects like these are not everyday situations. They are exceptions. Yet precisely for this reason, they show very clearly what becomes possible when systems, processes and people work well together.

The technical solution alone is not enough. What is needed is a well-organised process chain. Design, work preparation, material procurement, production, logistics and installation all have to interact closely. The people involved need to be competent, able to make decisions quickly and aware of the consequences of those decisions.

There is another aspect as well: such projects do not take place in an empty workshop. They are inserted into an already running production and installation process, alongside other ongoing projects and orders. Materials must be available. Subcontractors must be able to respond. Internal interfaces must function reliably.

Speed, therefore, does not begin with the project itself. It is the result of experience, prepared systems and well-established workflows.

However, speed is only one part of the story. The other part is the ability to work beyond the current standard without losing the safety and logic of the standard.

Case 1: A Façade System Becomes a Building Envelope

For the Gelateria Mulegns, we used a façade system that had originally been developed for vertical, flat façade surfaces. The system was already known and proven from previous projects. Rectangular surfaces could be solved reliably, and polygonal surfaces had also become possible.

For the Gelateria, however, the system had to be developed further. It was no longer only a question of a vertical façade. Façade and roof had to be conceived and built as one continuous envelope.

Put simply, an eaves edge and a ridge edge were added to the existing system. This allowed the façade system to be transferred into a more spatial context without abandoning its underlying logic.

The decisive step was not to invent a completely new system. The decisive step was to extend an existing system precisely enough for it to take on a new task.

Case 2: A Tent System Is Mounted Differently

For the open-air stage in Lantsch/Lenz, a different principle was used. Here, a standard festival tent system was repurposed.

Normally, such a system is used for classic tent structures with portal frames. In this project, however, an on-top mounting system was developed for a timber structure. In its behaviour, it was closer to a mullion-and-transom system in timber or aluminium, while still retaining the tensioning logic of the festival tent system.

The system itself was therefore not fundamentally changed. The textile logic remained the same: membrane, keder, profile and tensioning. What changed were the drilling pattern, the fixing situation and the eaves tensioning. In this context, a roof originally associated with an 18-degree inclination was adapted to a zero-degree roof. As a result, eaves and ridge could be executed in a comparable way.

Again, the actual achievement was not a spectacular reinvention. It was the precise transfer of a known logic to an unfamiliar construction situation.

Case 3: The Hybrid Solution

For the open-air stage on the Julier Pass, it initially seemed obvious to reuse the solution developed for Lantsch/Lenz. The basic principle was known and had already worked.

During the development of the project, however, it became clear that using the tent profiles would have resulted in a construction that was too material-intensive. Instead, a much flatter façade profile was used. The ridge was solved in a way similar to standard extension tents, while the tensioning was taken from another façade system.

The resulting solution was hybrid. It followed the basic idea of the Lantsch/Lenz stage, but used different profiles and adapted the ridge and eaves details to the specific situation.

This example shows particularly well that standardisation does not necessarily mean using the same component again and again. Standardisation can also mean maintaining a recognisable system logic while individual components are exchanged, combined or adapted to suit the situation.

Not the Theoretically Best Solution, but the Realisable One

In projects like these, the system decision is rarely the theoretically perfect solution. It is the most robust solution under real conditions.

When only a few weeks are available for planning, production and installation, it is not sensible to start from zero. Established systems are used because they already provide a basic level of planning security. Their materials, joining principles, installation steps and risks are known.

At the same time, it is clear that the existing standard does not cover everything. Targeted development is necessary. But this development must not be arbitrary. It has to remain within the logic of the system.

This is a very pragmatic way of working. It does not pursue innovation for its own sake. It is functional, purposeful and directed towards implementation. Nevertheless, it must not be understood as purely technical. Aesthetics, proportion, detail quality and the architectural effect of the finished structure remain central criteria.

Project Pressure as a Driver of System Development

In an ideal world, new systems are created through dedicated development assignments, long testing phases and carefully structured product strategies.

In the reality of project-based work, this is often different.

System development frequently takes place under project pressure. A specific project creates a specific requirement. Time is limited. The solution has to work. At the same time, it must not overload the company’s processes and must be manufacturable and installable with the resources available.

This may sound unromantic, but it is an important reality for many companies that have to deliver demanding solutions in project business.

For this reason, it is essential that such developments are not treated merely as one-off improvisations. Every project-specific adaptation should be examined to see whether it extends the existing system. A special case can become a new standard element. An exception can become a building block for future projects.

The Limits of Project-Driven Development

There is, however, a critical side to this method.

Developing only what is needed for a specific project is highly efficient. It avoids unnecessary complexity, reduces development time and keeps the focus on what is actually required. But this also means that the development remains object-specific. It responds to the requirements, constraints and performance needs of one particular structure.

As a result, such a development does not automatically create a generally valid standard.

Important parameters may still remain undefined: minimum and maximum dimensions, permissible loads, limits of geometry, material combinations, tolerances, installation conditions or long-term performance criteria. The system may have proven itself in one specific case, but that does not mean it is fully qualified for every future application.

If another structure is to be realised using a system developed in this way, it must therefore remain within the same requirement and performance range as the original development basis. If this is not the case, both the object and the system have to be reviewed.

This distinction is important. A project-driven adaptation can be a valuable extension of an existing system, but it is not yet the same as a completed standard. It may be a prototype, a project-specific variant or a first step towards a broader system solution.

If such a solution proves useful repeatedly and begins to establish itself, it may make sense to complete the system development in a more systematic way. This means defining its limits, documenting its parameters, testing its performance range and making it accessible as a reliable standard for future projects.

In this sense, project pressure can initiate system development. But only deliberate consolidation turns it into a true standard.

A System Is More Than a Finished Solution

Systems are often understood as closed, complete solutions. Either the task fits the system, or it does not.

I believe this view is too narrow.

A good system is not only an off-the-shelf product. It is a kit of parts with an internal logic. This logic defines how forces are transferred, how components are joined, how tolerances are absorbed, how installation processes work and where adaptations are possible.

If this logic is strong enough, the system can respond to new situations. It can be extended, combined or adapted without becoming arbitrary.

Sometimes, certain elements are missing from a system. The task is then to develop these elements in such a way that they integrate seamlessly into the existing logic. This is a key competence: not simply inventing something new, but intelligently developing an existing system further.

Lightness Is the Result of Hard Work

From the outside, good textile solutions often appear simple. A membrane spans across a structure. The detail is slender. The envelope looks light. The construction appears self-evident.

But this self-evidence is deceptive.

When something looks good and simple, it is usually the result of substantial development work. Poor development work, on the other hand, becomes visible immediately: in overloaded details, unclear force flows, difficult installation, unnecessary material use or solutions that only work on paper.

Good standards do not make complexity disappear by ignoring it. They make complexity manageable.

Perhaps this is the real difference between a rigid standard and a genuine system logic. A rigid standard only works where the task fits exactly. A system logic can also work where the task deviates — provided the further development is precise, disciplined and based on an understanding of the whole.

The special case is its stress test, but only systematic consolidation turns the result into a standard.