DrupalCon Rotterdam Speakers Test Proof, Trust, and Maintainability Beyond the Demo

A technology demonstration establishes that something can work under the conditions in front of an audience. It does not by itself show that the system will report failures accurately, remain maintainable, produce trustworthy answers, control its costs, or survive after responsibility moves away from the people who built it.

Speakers across DrupalCon Rotterdam and its AI Dev Summit are concentrating on that second problem. Their sessions cover observable AI workflows, deployable Drupal AI capabilities, answer systems that can acknowledge uncertainty, evidence behind generative-search claims, HTMX, modern video architecture, and the less visible ownership required to keep an open-source community functioning.

Their subjects differ, but the practical test is similar: what evidence exists after the technology appears to work?

Shibin Devadas Kakanat gives that question a deliberately uncomfortable starting point in FlowDrop in Production: Observable, Async, Cost-Controlled Agentic Workflows for Drupal at the AI Dev Summit on 28 September. He plans to begin with a real production run in which a design tool was asked to make a colour darker, reported success, and returned a different colour.

The mistake became useful because the workflow contained enough observability and record keeping to investigate what had happened. Shibin argues that those capabilities have to be designed into an AI workflow rather than attached after an incident, because a final “success” state says little about which input, model call, deterministic step, or handoff produced an incorrect result.

His broader point is that production AI workflows are often made up largely of deterministic operations with a smaller number of model calls. Queues, time limits, and human approval points allow longer-running work to leave the normal request cycle and pause when a consequential action requires review. Cost becomes another observability problem: something to measure at individual stages rather than discuss only as a general characteristic of AI.

Shibin said the workflows run on the Drupal site without a hosted control plane and are represented as configuration that can be stored in Git. He is particularly looking forward to comparing implementation notes during the summit's discussions of guardrails, context, ECA with agents, AI-native infrastructure, and the afternoon topic tables.

Niels Aers and Christoph Breidert approach proof through product readiness in Drupal AI Product Update: From Foundation to Agentic Workflows. Niels wants agencies and implementation teams to distinguish what they can use now from work that still requires further engineering.

Niels said more than 30 companies have contributed to the initiative over the past year. The session will look at how AI Recipes connect with governance components including Guardrails, Observability, and the Context Control Center, rather than presenting each feature as an isolated addition.

Content Reviews and semantic search are among the editor-facing examples. Niels also wants attendees to understand which capabilities can be installed comparatively quickly and which still demand significant engineering, allowing agencies to scope work without describing the entire Drupal AI stack as equally turnkey.

Ulla Koho and Tomi Mikola begin one step earlier in Nobody Asked for a CMS: From Content Management to Answer Delivery in the Age of AI. Their argument is that organisations normally begin with a problem they need solved rather than a desire to own a content management system.

Their four examples include needs for a dependable source of truth, a prototype credible enough for sceptics to test, a way to identify the right answer from a very large set of possibilities, and information a student can trust at 03:00. The session uses those cases to ask what a project requires before anybody chooses the tooling.

One production example is an answer service spanning seven university systems and three languages. Ulla and Tomi said the feature its client values most was not in the original brief: the service records questions it cannot answer, evaluates its answers against real user questions, and identifies source information that has become stale.

That feedback loop makes uncertainty useful. An unanswered phrase can become a content brief or expose a service gap, while a system capable of saying “I don't know” can be more trustworthy than one designed to provide an answer every time. For Ulla and Tomi, trust therefore depends heavily on source quality, ownership, and freshness rather than on the model alone.

From SEO to GEO: What Changes, What Doesn’t gives Wouter De Bruycker a different evidence problem. His concern is not a shortage of advice about visibility in generative systems but the amount of advice being repeated with more certainty than its supporting evidence warrants.

Wouter plans to separate what is currently known from assumptions that have gained authority through repetition. He will compare generative search with conventional SEO, identify overlap, and examine where the available evidence supports a material change rather than treating every new acronym as a reason to replace an existing search strategy.

The practical takeaway is an evidence test: which techniques appear to affect visibility, which remain speculative, and which established technical and content practices still matter. Wouter also said the session will not be used to pitch a GEO product or tool.

Architecture rather than search evidence is the focus for Ruturaj Chaubey and Vighnesh Sadagopal in From Ajax API to HTMX: Evolving Drupal Interactions. They will examine HTMX as an emerging approach in Drupal 11.3 for developers who have encountered JavaScript coupling, wrapper ID problems, custom callback overhead, and other friction around Drupal's Ajax API.

Ruturaj does not want HTMX presented as a newer library that should automatically replace an existing approach. The session instead compares how hypermedia-driven interactions fit Drupal's render arrays, routing, caching, and server-rendered responses, while identifying situations where the existing Ajax API continues to work well.

Dynamic forms, filtering, partial-page updates, debugging, progressive enhancement, performance, and incremental adoption are among the tradeoffs the speakers plan to cover. Maintainability therefore becomes a choice about architecture rather than a claim that the newest option is inherently better.

David Pacassi Torrico asks a similar architecture question about video in Modern Video in Drupal: AV1, Responsive Sources, CDN Providers, and a Better Contrib Architecture. His starting point is whether configuring video could become as systematic as configuring image styles.

David's session draws on three contributed modules developed with support from Helga. Reusable video styles, responsive sources, and provider plugins are intended to work together while editorial management remains in Drupal and specialist services handle encoding and delivery where appropriate.

AV1, fallback strategies, native HTML video, embedded players, caching, and asynchronous processing are among the implementation questions. David also intends to distinguish what the current architecture solves from what remains unfinished and to use attendee edge cases as a test of whether the work generalises beyond the projects that originally produced it.

Nikita Aswani brings the final maintainability question back to people in From Passion to Pressure: Rethinking Sustainability in Open Source Communities. Her concern is what remains hidden when a meetup, camp, or community looks successful from the outside.

Nikita said pressure can increase because a community is succeeding rather than because it has failed. Her session is not intended as another volunteer-recruitment presentation or a universal set of management tips. Instead, she wants organisers to recognise when apparent momentum still depends on the same small group carrying the difficult or recurring work.

Ownership, handoff, and letting go are therefore central to the session. Asking for more volunteers does not necessarily change who owns essential responsibilities, and Nikita wants attendees to notice whether work is genuinely being transferred or whether new people are being added around an unchanged core.

That makes community sustainability another version of the same test applied elsewhere in these sessions. A system can report success while producing the wrong colour, an answer engine can sound confident while its source material is stale, a newer interaction model can create different maintenance costs, and a busy community can remain structurally fragile.

The demo is therefore not the end of the evidence. Drupal teams still have to know how a system failed, what information supported an answer, what remains difficult to maintain, what a metric actually represents, and who will still understand or own the work after the first successful implementation.