## Why this roadmap exists At DrupalCon Rotterdam at the end of September we want to show a single Drupal site where AI Search, AI content review, AI translation, an editor-facing chat, observability and guardrails all work together on real, multilingual content. Rather than describing these features one by one, we let people see them working together on one site, and we let anyone launch that site for themselves in a few seconds on Drupal Forge. Most of these features already work today. The gap is almost never the core capability. The gap is that we have not yet shipped the recipes and demo configurations that make them work end to end, with results we are happy to show, on one realistic site. That is the work this roadmap describes. The goal is to deliver as much of this as possible for Rotterdam. Each area below states briefly what that means for that area. Where an area is uncertain, the lead decides, in alignment with the product lead. This issue is the highest level issue for Inside AI. It sets out what each area has to deliver and it links to one meta issue per area. It does not replace the area backlogs, it points at them. ## The demo is the proving ground The demo is not a separate effort from shipping features. The recipes and configurations that make a feature work in the demo are largely the same ones that make it adoptable on a real project, so building the demo is how shippability becomes visible. Every area on this roadmap therefore has a demo obligation as well as a code obligation. The demo rests on three foundations. **Content.** A multilingual content corpus with enough depth that the AI has something meaningful to search, review and translate. The corpus lives separately from the recipe, so content can be updated independently of configuration. **Theme.** A polished, realistic university theme. If the site does not look credible on first load, nobody arrives at the AI features in a receptive frame of mind. **Recipes.** One curated recipe per capability, all of which install together cleanly as part of the Drupal AI starter template and all of which work against the same corpus. ## Why a university The demo site is a research university. Higher education is Drupal's home turf, the content is naturally deep and distributed across courses, staff, research and news, so multi-hop questions arise naturally, and a university is a plausible multilingual case with published writing guidelines that give content review something real to score against. A university also resembles every one of Drupal's main audiences at once. It is an education institution, it carries the public accountability and compliance pressure of government, it runs programmes like a non-governmental organisation and it operates administrative functions like a company, so all of these audiences can relate to it easily. ## How to use this issue **One meta issue per area.** Each area lead creates one meta issue in the project where their work lives, and adds a single comment to this issue registering the link. Leads can edit their own comments, so keeping that registration current is the lead's own responsibility. The table at the end of this description stays the canonical index and is maintained by the product lead. **Agreeing the scope of your area.** The descriptions below set the direction, not the backlog. Each lead aligns the exact scope of their area directly with Christoph Breidert. I will hold a short meeting with each area to agree its backlog, so please get in touch rather than working from this description alone. **Getting your recipe into the demo.** Artem Dmitriiev supports every area in getting its recipe into the demo and installing cleanly alongside the others. If your capability works but is not yet packaged or not yet installing with the rest of the starter template, that is the help to ask for. **Definition of delivered.** An area counts as delivered for Rotterdam when all six of the following hold. 1. A recipe exists in the Drupal AI starter template and installs cleanly alongside the other recipes. 2. It ships sensible defaults, so nothing has to be configured by hand after installation. 3. It works against the multilingual demo corpus, with output good enough to present without apology. 4. The area lead has prepared one Demo page explaining what to try and how to verify it, and has handed that text to the demo team so it can be added to the demo content corpus. 5. Module and patch versions are pinned, so the installation is reproducible. 6. It runs inside the AI credit budget available to a launched Drupal Forge instance. **Handing work into the sprints.** Leads prepare and groom the issues in their own backlog. The delivery managers, Arian Raeesi and Vidit Anjaria, plan those issues into the sprints. Issues that touch architecture go through joint grooming with the technical leads, Marcus Johansson and Artem Dmitriiev. **On what belongs in public.** This roadmap commits to capabilities and acceptance criteria, and it stays public so that contribution is visible and creditable. Specific scenarios reserved for the DrupalCon keynote are managed separately and are not described here. If you are unsure whether one of your issues belongs in public, align with Christoph Breidert before you write it. ## Roadmap items ### 1. Demo content and site **Leads** Aidan Foster and Christoph Breidert **Delivered** The university corpus exists in the demo content recipe as reviewable source files, separated from configuration. The site structure is Home, Demo, Courses, Staff, News and a small set of standard pages. The Demo section carries one page per area, prepared by that area's lead and added to the corpus by the demo team, explaining what to try and how to verify it. The whole site installs from the starter template as a single Drupal Forge template launch, with no signup form in front of it. **Demo scenario** A visitor arrives at a university site that looks like a real university site, reaches the Demo section from the home page, and can work through every AI capability without external instructions. **Dependencies** Theme, asset strategy and multilingual configuration, all listed under cross-cutting foundations. ### 2. AI Search **Leads** Abhisek Mazumdar and Laurens Van Damme **Delivered** AI Answers configured against the corpus, returning a grounded summary with inline citations, the ranked sources beneath it, and suggested follow-up questions. The transition from a search result into a conversational continuation is seamless and carries context across, in the way modern web search now behaves. No floating chat widget anywhere on the site. **Demo scenario** A prospective postgraduate student asks which researcher works on tidal energy. The answer identifies the research area, the person who teaches it and the related courses, with citations. The visitor then continues in chat mode to ask whether that person also teaches undergraduate courses, without repeating context. ### 3. AI Content Review **Lead** Open **Delivered** Content review runs against fixed, published criteria derived from real university writing guidelines held in the context control centre. A reviewer can see which pages fail, see the specific finding on the page, see a suggested fix and apply it. Scoring is reproducible across runs on the same content. **Demo scenario** Several pages inside the Demo section carry deliberate, visible writing problems. The reviewer opens the review tab on one of them, sees it failing the reading level and tone criteria, reads the suggested corrections and applies them. **Dependencies** The context control centre, which holds the guidelines that content is reviewed against. ### 4. AI Translation **Leads** Sven Decabooter and Valery Lourie **Delivered** The corpus is translated from the source language into the agreed target languages, at a quality worth presenting. Translation can be triggered and reviewed from the editing interface. Search and answers work in every configured language. **Demo scenario** An editor translates a course page and a staff profile, reviews the result, and a visitor then asks the same question in a second language and receives a grounded answer citing the translated pages. **Dependencies** Multilingual configuration of the corpus, listed under cross-cutting foundations. Target languages to be confirmed. ### 5. AI Chatbot **Lead** Open **Delivered** Two things, in this order. First, the conversational continuation of AI Search described in item 2, delivered jointly with that area. Second, an editor-facing chat in the sidebar that can act on the page being edited, for example changing a title or revising a body field, with the available tools determined by the editor's permissions on that specific node. **Demo scenario** An editor opens the sidebar chat on a course page and asks for the title to be changed. The change is applied. A user without permission to edit that node asks the same thing and is told the tool is not available. **Dependencies** Page element annotation, so that fields are exposed to the chat interface according to the current user's role. This is on the AI roadmap but is not finished. Note that the scope of this area changed after the July blog post. There is no floating chat widget on the public site, and the public conversational experience is delivered through AI Search instead. ### 6. AI Context **Lead** Kristen Pol **Delivered** The context control centre installs with sensible defaults and holds real site information, including the university writing guidelines used by content review. Every AI feature on the site draws its site context from here rather than from its own configuration. **Demo scenario** A visitor to the Demo section is shown where the brand and writing guidelines live, changes one, runs a content review against the same page again and sees the result change. **Dependencies** None blocking. Note that AI Content Review depends on this area, so it should land early. ### 7. Security and guardrails **Lead** Open **Delivered** Guardrails packaged into the demo with sensible defaults, covering at minimum prompt safety and personally identifiable information, referred to below as PII. The Demo section documents how to deliberately trigger a guardrail and what the user sees when it fires. Usage metrics are visible. **Demo scenario** A visitor follows the documented steps to send a prompt that a guardrail blocks, sees the block, and then finds the corresponding record in the observability backend. Sample content containing fictional personal data demonstrates the PII guardrail. **Dependencies** Sample content carrying fictional PII, coordinated with the Demo area. Configuration is currently harder than it should be, and simplifying it is part of this area's work. ### 8. Observability **Lead** Open **Delivered** An OpenTelemetry backend, meaning a standard telemetry collection and viewing service, reachable from the launched demo instance, receiving the AI telemetry export. The Demo section explains how to generate AI activity and where to observe it. **Demo scenario** A visitor runs a search, a content review and a blocked prompt, then opens the telemetry backend and follows each of those three actions through it. **Dependencies** A freshly launched instance starts with no history. That is acceptable, and the Demo page should state it plainly and guide the visitor to generate activity first rather than presenting an empty view without explanation. ### 9. Canvas AI **Lead** Akhil Babu **Delivered** Landing pages in the demo are built with Canvas, and a recipe installs the AI capability for those pages so that chat-driven editing works on them within the credit budget of a launched instance. **Demo scenario** A visitor opens a landing page in Canvas, asks for a section to be changed, sees clear progress feedback while the work runs, and sees the result applied. **Dependencies** Feasibility inside the available AI credit budget per instance, and the amount of prototype code still to be made production ready. Whether Canvas AI is in the Rotterdam demo is this lead's decision, and the decision date is in the schedule section. ### 10. Image alt text and classification **Lead** Open **Delivered** This capability already exists as a single recipe. What is missing is a lead to bring it into the demo and take responsibility for it. Uploading an image to the media library generates alt text and a classification automatically, which the editor can accept or amend, and the media library supports natural language search over the resulting descriptions. **Demo scenario** A visitor uploads an image and receives usable alt text and a classification without leaving the media library, then finds an existing image by describing it in plain language rather than by filename. **Dependencies** Enough images in the corpus that a search has plausible alternatives to reject, without putting large binary files into the recipe. See the asset strategy under cross-cutting foundations. ### 11. Title and summary suggestions **Lead** Open **Delivered** This capability also already exists and needs a lead. Editors receive title and summary suggestions on the content types used in the demo, configured and documented as part of the demo. ### 12. Editor integrations **Lead** Open **Delivered** The AI capabilities available inside the rich text editor are configured and documented for the demo content types, so that the everyday editing experience shows AI assistance in place rather than only in dedicated screens. ### 13. AI form validation **Lead** Open **Delivered** At least one form in the demo validates submitted content against configured policy using AI, with a clear message to the person submitting. ### Not planned for Rotterdam AI-powered bulk content updates were the fifth partner priority and are not planned yet. The natural home for them is alongside content review, because once you can review a large body of content with AI, helping AI act on what it found is the obvious next step. They are deliberately left out of this roadmap. ## Cross-cutting foundations These block every area and none of them belongs to a feature lead. Each needs an owner. | Foundation | What is needed | Owner | | --- | --- | --- | | Theme | A polished, realistic university theme, including logo, hero imagery and card layouts for courses and staff | Open | | Asset strategy | Images and video available to the demo without large binary files sitting in the recipe, so that the repository stays fast to clone. Video hosted remotely so it can be updated without a new release | Open | | Reproducible installation | Module and patch versions pinned across all recipes so that the starter template installs reliably and repeatedly | Open | | AI credit budget | Enough AI credit per launched instance for a visitor to work through the Demo section, including Canvas AI if it is included | Open | | Multilingual configuration | Source and target languages configured, and the corpus structured so translations are part of it rather than bolted on | Open | ## Schedule | Date | Milestone | | --- | --- | | To confirm | Corpus scope agreed, meaning the number of courses, staff profiles, news items and languages | | To confirm | Decision on whether Canvas AI is in the Rotterdam demo | | To confirm | Corpus freeze, after which content changes need a good reason, so that theming has a stable base | | To confirm | Feature freeze, after which no new capability enters the demo | | To confirm | Demo presentable end to end, rehearsal window opens | | End of September | DrupalCon Rotterdam | ## Areas still looking for a lead AI Content Review, AI Chatbot, Security and guardrails and Observability are all open, as are the four items covering AI helpers and most of the cross-cutting foundations. A name beside an area does not mean you cannot join it. We are looking for strong teams rather than single owners, so contributing to an area that already has a lead is as real an opportunity as taking on one that is open. There is no application process. A lead prepares issues and keeps a backlog in good shape, and taking on that responsibility is what makes you a lead. If an area interests you, say so in the #ai-initiative channel on Drupal Slack or contact Christoph Breidert directly, and begin. ## Index of area meta issues Leads register their meta issue by commenting on this issue. This table is the canonical index and is kept current by the product lead. | Area | Lead | Meta issue | | --- | --- | --- | | Demo content and site | Aidan Foster, Christoph Breidert | | | AI Search | Abhisek Mazumdar, Laurens Van Damme | | | AI Content Review | Open | | | AI Translation | Sven Decabooter, Valery Lourie | | | AI Chatbot | Open | | | AI Context | Kristen Pol | | | Security and guardrails | Open | | | Observability | Open | | | Canvas AI | Akhil Babu | | | Image alt text and classification | Open | | | Title and summary suggestions | Open | | | Editor integrations | Open | | | AI form validation | Open | |