fidzu : Drupal

AI is changing how people find your content. Score your Drupal platform's AI readiness across five areas in five minutes.

17 Aug 2026 1:07pm GMT

Last week's AI releases put a familiar question back into view: who controls the technology that digital systems depend on? On 10 August 2026, Meta released Muse Glimmer, a 30-billion-parameter model optimised for local agent workflows, with its weights under the Apache 2.0 licence. Mark Zuckerberg, Meta founder and CEO, argued in an essay published the same day that superintelligence should be broadly distributed rather than concentrated in a small number of hands. On 14 August, Alibaba Group's Qwen team released Qwen3.8-27B, another downloadable model with weights under Apache 2.0.

There is a catch in calling all of this "open AI." Downloadable weights under an open-source licence do not by themselves establish that an entire AI system is open source. Under the Open Source Initiative's Open Source AI Definition, the preferred form for modification also requires sufficiently detailed information about the data used to train the system, the complete source code used to train and run it, and the model parameters. Even so, downloadable weights can expand practical deployment choices by allowing organisations to run and adapt models on infrastructure they control rather than relying solely on a vendor-hosted service.

Drupal is relevant here not because a content management system and an AI model are equivalent, but because the project has spent 25 years working within open-source principles. Drupal marked its 25th anniversary on 15 January 2026, and the Drupal Association's Open Web Manifesto describes the open web through principles including freedom, decentralisation, participation, choice, privacy and security. The comparison should remain limited: a content management system, model weights, training data, source code and computing infrastructure are different layers with different licensing and governance problems. The shared principle is practical: leave organisations room to choose infrastructure, modify systems, and avoid unnecessary dependence on a single provider.

The larger question is whether those principles are becoming easier to recognise beyond software-development communities. AI is forcing organisations to consider what happens when a technology provider changes terms, raises prices, closes a service or simply stops fitting their needs. Drupal cannot answer AI's licensing, computing, data-governance or portability questions, and open source does not guarantee independence. What Drupal can offer is a 25-year example of why choice, modification and exit matter when digital infrastructure becomes important enough to depend on.

As AI becomes another dependency inside websites and digital services, that old open-web argument has a new place to land. The question is no longer only what an AI model can do, but how much control remains with the people and organisations that build on it.

Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.

This issue of Editor's Pick was written and curated by Kazima Abbas.

17 Aug 2026 10:16am GMT

If AI can generate an application from a description, is software still worth anything?

I have lived with a version of that question longer than most.

I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.

Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.

Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.

Free code changes what customers pay for

Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.

We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.

Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.

As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.

Dependability becomes the product

Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.

Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.

As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.

Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.

Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.

Either way, more software companies will have to answer the same question: if the code is abundant, what are customers really paying you for?

17 Aug 2026 9:35am GMT

Drupal 11: Migrating From Jadu Into LocalGov Drupal: Part 2

This is the second article in a series of articles looking at migrating from Jadu into a LocalGov Drupal (LGD) site for Central Bedfordshire. In the first article we looked at the Jadu API and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.

In the last article I mentioned something about the Jadu API that caused me a lot of headaches. The API contains most of the information for a page, but critically, the Jadu API contains no information about the path of a page. There is basically no way to get the URL of a page in Jadu from the XML API.

I'm quire sure that this makes creating anything useful in the API a real pain since referring back to the site needs to be done with manually placed links, but it's clearly like this by design. I couldn't find any documentation on why it is like this, but it almost feels like vendor lock-in. Please correct me if I'm wrong here.

If you migrate a page from one system to another then it is highly important that you maintain the URL structure of the site. If you change the URL of a page then you need to add in a step that adds a redirect from the old system to the new so that all of your search engine results, the existing links from other sites, and any user bookmarks that have been created work correctly. This is critical to get right for a public facing council site like this.

Since I was migrating into a LGD site, it made sense to use the Drupal path auto system and LGD path management plugins to manage the paths on the Drupal site. We therefore needed to know the existing Jadu URLs so that we could create these redirects.

To get the URLs during the migration caused quite a bit of experimentation, but I did solve the issue with a solution that had a high success rate.

philipnorton42 Sun, 08/16/2026 - 19:06

16 Aug 2026 6:06pm GMT

Webform is the most popular module for building forms in Drupal. You can use it for a simple contact form or for a long form with conditional logic, file uploads, and email alerts. Either way, you build the whole thing from the admin interface without writing code.

In the video above, you will learn how to build a form with Webform in Drupal CMS. You will create a Customer form, add conditional logic, send a confirmation email, split the form into pages, view submissions, and embed the form on a Drupal Canvas page.

16 Aug 2026 2:59pm GMT

Imagen

Imagen

Carlos

Ospina

·

Technical Account Manager / Drupal Advisor

16 Aug 2026 12:48am GMT

Thirty Years of Palantir demet Fri, 08/14/2026 - 11:42

What three decades has taught us about what lasts

Thirty years ago last month, between my sophomore and junior years of college, I started a company called Palantir Internet Services, later known as Palantir.net. I had been building personal websites for nearly two years at that point and was captivated by this revolutionary new medium that allowed anyone, anywhere, to publish something that anyone else in the world could read.

While the internet touches nearly every part of our lives today, in the summer of 1996 it was still seen by many as a novelty. There were only about 250,000 websites on the web, and while Amazon and eBay had already launched, Google, Facebook, and Wikipedia were still years away.

That fall, I met Tiffany Farriss, and together we built Palantir into a company that developed websites for clients of all shapes and sizes. As college students, we were featured in a news story on CNN and profiled in a front-page Chicago Sun-Times article. Our first paying clients were colleges and universities, and then for several years we partnered with Chicago design firms who were making the transition from print to the web.

During that time, we built and deployed several versions of our own in-house content management platform, eventually deprecating it in 2007 in favor of the newly released Drupal 5. Putting our energy into contributing to an open source project not only brought us new business opportunities but also introduced us to a community we are proud to still be part of today.

Along the way we grew into a full-service digital consultancy, bringing our strategy, design, build, and support services to public sector agencies, higher education institutions, nonprofits, and healthcare organizations whose needs are genuinely complex and whose work has a profound impact on others.

Only a handful of companies in our industry have been around as long as we have. Over the years, we've watched it go through several transformations: the dot-com bubble of the late 1990s, the rise of "Web 2.0" and social media in the mid-2000s, and the emergence of smartphones and the mobile web in the late 2000s.

Today, we are in the middle of one of the web's biggest transformations yet, as generative AI has fundamentally disrupted the traditional ways that online content is both created and consumed. The business models that built the web are no longer sufficient for an environment increasingly dominated by bot traffic and bot-created content. As more money has flowed into generative AI, we've seen less of it invested in other forms of online infrastructure, and that shift has affected us and many others in our industry.

At the same time, these tools have already demonstrated their usefulness for automating manual and labor-intensive work, from code review to content audits. We believe that when used thoughtfully, generative AI can improve the online experience and make vital information more accessible to more people.

And that's why, in an era of slop and enshittification, we feel it's more important than ever to recommit to our mission and vision. Palantir exists to help others discover, create, and share knowledge, and to strengthen humanity through the work that we do and the way that we do it.

We may not be able to predict the future, but 30 years of experience gives us a lot of perspective on where things have been and where they might go next. Technology keeps changing, but it's people who decide where to put their time and attention. That's the choice we've made so far, and it's the one we will continue to make.

14 Aug 2026 4:42pm GMT

I know this blog post's title implies losing my (programming) skills, and I will gladly address my feelings about how agentic coding has caused my problem-solving and coding to atrophy from lack of use. The main focus of this post is about losing, specifically deleting, my overly verbose and complicated skills and AGENTS.md files.

I was inspired to write this post after recently switching to the latest OpenAI GPT 5.6 models with Codex and OpenCode as my harnesses for Drupal development. In a previous post, I discussed that one approach to working with AI is to accept that every beginning and end of a session is like onboarding and offboarding a new team member. To help onboard an AI, we need to provide documentation, guidance, and workflows, typically implemented as AGENTS.md and agent skills.

AGENTS.md and agent skills are instructions added to your context to nudge the AI in the right direction. After switching to a more intelligent frontier model, I began to suspect I needed to rethink my assumptions about what the AI was capable of and how much initial context was required for the AI to succeed at a task. So I removed all my assumptions, deleted my AGENTS.md and skills directory, and started fresh.

Losing my agent skills

I had a hunch that some of my installed agent skills were costing me extra tokens and not adding enough value when I read a Reddit thread about "are you guys still using the superpowers skill?" Superpowers nudges coding agents to adopt a pragmatic workflow that includes brainstorming, specs, plans, tests, and review....Read More

14 Aug 2026 2:41pm GMT

Questions, story leads, and feedback on future Drupal coverage are on the agenda for contributors and community members joining the monthly meeting.

14 Aug 2026 9:39am GMT

Members still weighing their choice can read The DropTimes' interviews with seven candidates to compare their priorities before casting a ballot.

14 Aug 2026 7:29am GMT

Today we are talking about Open Source sustainability, becoming your own content creation machine, and how drupal influenced some of that with guest Jeff Geerling. We'll also cover AI Metering as our module of the week.

For show notes visit: https://www.talkingDrupal.com/565

Topics

• Jeff's Timekeeping Icebreaker
• Jeff's Drupal Origin Story
• From Drupal to Hardware Tinkering
• Staying Motivated on YouTube
• What Conferences Are Really About
• DrupalCon Memories and Community
• Why Jeff Moved to Hugo
• PSA Tornado Warning Detour
• Keeping Up with Drupal CMS
• PHP Perception Shift
• Fast Drupal Setup
• COVID Streaming Boom
• Picking Video Projects
• Decommissioning Builds
• YouTube Algorithm Risk
• Vintage Time Server
• Creator Starter Tips
• Supporting Maintainers
• Books and Crohns
• Local Control Trends
• AI Workflow Boundaries
• Timing Obsession
• Kind Drupal Culture

Guests

Jeff Geerling - jeffgeerling.com geerlingguy

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan Mike Anello - drupaleasy.com ultimike JD Flynn - dorficus

MOTW Correspondent

Mike Anello - drupaleasy.com ultimike

• Brief description:
  • AI Metering module - helps keep track of your users' AI token usage on the site. Includes cost estimation, token limits, and local LLM fallback options.
• Module name/project name:
  • AI Metering
• Brief history
  • How old: created in June 1 2026 by Jérôme Tchania (codeitwisely)
  • Versions available: 1.0.1
• Maintainership
  • Actively maintained - yes
  • Co-maintained by Carlos Ospina (camoa)
  • Security coverage - yes
  • Test coverage - yes
  • Documentation - yes
  • Number of open issues: 9 open issues, 4 of which are bugs against the current branch
• Usage stats:
  • Sites: 78
• Module features and usage
  • Obtains token costs for all modules from LiteLLM
  • Can be configured to send email when the token limit is being approached.
  • Per user and per role reports.
  • LLM fallback to Ollama

13 Aug 2026 6:00pm GMT

Open-source software still depends on infrastructure and human maintenance that carry real costs. Farriss argues that institutions should plan for those costs before contracts are awarded.

13 Aug 2026 3:13pm GMT

The most dangerous moment in a Drupal-to-headless migration is the one where everything looks fine. The content exported. The article titles are all there. Then an editor opens a launch-ready page and half the images are missing, the "related articles" block is pointing at a press release from 2019, and one product's category is now, somehow, a staff bio. Nothing errored. Nothing turned red. The references just quietly stopped meaning what they used to mean. That is the trap, and it lives in taxonomy, media, and entity references specifically because Drupal stitches your content together with numbers instead of names. Drupal is a house where everything is labeled by drawer, not by name Picture a house where nobody wrote what anything is. Instead, every object has a little tag: see drawer 47 . The cookbook says "pairs with drawer 112." The remote says "belongs to shelf 9." It works…

Read the rest at Replatform Radar

13 Aug 2026 2:00pm GMT

Traditional content staging servers have had their day. At DrupalCon Chicago 2026, Tag1's Peta Hoyes and Ray Stuart (presenting for Fabian Franz) made that case and showed exactly what replaces them. Their session, Workspaces is Revolutionizing Drupal Core: Unlock True Enterprise Content Management in Drupal, covered the core architecture, live demos, and a Q&A with the room.

We have expanded and organized the questions from that session into a standalone reference on how Workspaces works for enterprise content teams.

Getting Started: What Workspaces Is and How to Turn It On

Q. What is Workspaces?

A. Workspaces is enterprise content staging built into Drupal core. It lets a privileged user preview a large set of changes exactly as a site visitor will see them, then publish the whole set at the click of a button. Instead of maintaining a separate staging site, each workspace is an isolated set of staged changes that layers on top of your live site. You stage, collaborate, and publish without touching production until you are ready.

Workspaces has been stable in Drupal core since version 10.3 (June 2024) and ships with every Drupal 11 installation. It is no longer experimental. It is core infrastructure, and it is free and open source.

Q. How do you get started?

A. Core Workspaces turns on with a single command that most Drupal teams already know:

drush en workspaces

For enterprise use, you also want Workspaces Extra (WSE), which installs the same way most contributed modules do:

composer require drupal/wse

That is a low barrier to entry for enterprise capability out of the box.

Q. What does WSE (Workspaces Extra) add on top of core?

A. If core workspaces are content branches, WSE is closer to the full deployment pipeline you already have for code. WSE adds scheduled publishing, preview links for external stakeholders, rollback of an entire published workspace, access control, menu staging, task monitoring, and the ability to move content between workspaces when needed. WSE Config stages configuration changes alongside content, and WSE Theme lets you preview an entirely different theme staged in a workspace.

Q. I already know git. How should I think about Workspaces?

A. If you understand feature branches, you already understand Workspaces. The mental model maps almost exactly:

• Your Drupal site is the repository.
• A workspace is a branch.
• Live is the main branch.
• Saving content is a commit.
• Previewing a workspace is your working copy.
• Publishing is a merge.

The workflow is the same one developers take for granted: create a branch for your campaign, make your changes, preview the complete state, get approval, then publish. Content teams simply have not had this tooling until now. As the session put it, if your dev team would not ship code without branches, why would your content team ship content without workspaces?

The Core Problem: Why Enterprise Teams Still Struggle with Content Management

Q. What do we mean by true enterprise content management?

A. For a CMS to truly meet enterprise requirements, it needs to provide tools for both creating content and managing the end-to-end governance of that content. Content governance covers everything from procedures to technology that a complex organization needs to make sure its content meets its standards for brand, legal compliance, and accessibility. There can be a lot of content stakeholders with diverse concerns. Strong content governance is what stops all of that from devolving into chaos.

Drupal has been working toward this in core for a long time: granular user roles, workflows, content moderation in Drupal 8. With Workspaces in core, Drupal has closed another major governance gap. Content staging and review in the CMS.

Q. Why is content staging and review in context more important than ever?

Modern enterprise websites are composable. Content comes from multiple systems, dynamically laid out in the CMS, with edits and updates automatically propagating across the site. The governance of large-scale changes (adding new products, migrating a department, launching a campaign) needs to happen in the context of the overall site, with all the pieces of the puzzle present. Until Workspaces, Drupal hasn't had a clean solution for that.

Q. What about the impact on the people who need to manage content?

A. External staging sites mean content managers work in two or more places. And what most content managers do not love is remembering which autogenerated subdomain from a git branch ID is the one they are supposed to be updating. Workspaces keeps everything inside a single Drupal installation.

The Reality of Modern Drupal: Complexity Behind the Scenes

Q. What happens when you need to stage more than one set of updates at a time?

A. More staging usually means more problems. With traditional staging servers, each parallel workstream typically means another environment, another subdomain, another database sync, and another deployment pipeline to track. Workspaces eliminates that. Each workspace is isolated, teams can work in parallel, and there is no artificial limit on concurrent campaigns or content initiatives. Tag1 has tested workspaces with more than a thousand entities changed in a single workspace.

Q. If changes are happening on live while I work in a workspace, can I pull those changes in?

A. Think of a workspace as a shallow copy. Only the changes you explicitly make are tracked in the workspace. If someone modifies different content directly on live, those changes are not in your workspace and will not be overridden when you publish. Your workspace only ever contains what you put there. The one edge case is the same entity being modified in both places, which Workspaces intentionally prevents (see the collaboration section below).

Governance and Control: Who Sees What, and When?

Q. How do you deal with permissions for users who should not see work happening in workspaces?

A. Each workspace is isolated with granular permissions. Design, content, legal, and translation teams can work in parallel workspaces without visibility into each other's work unless it is deliberately shared.

Q. Can previews be shared with external reviewers, including anonymous users, and how does that work with permissions?

A. Yes. WSE preview links handle this. Create a dedicated role with preview access, assign it to the reviewer, and share the link. The reviewer does not need a full Drupal account, so this works for anonymous users too. The workflow is straightforward: prepare the role, generate the preview link, share it.

Infrastructure and Performance: Will This Break What Already Works?

Q. If I have a CDN or Varnish cache, will Workspaces need anything extra?

A. No. There are no changes to your anonymous content delivery. The active workspace is live 100 percent of the time for anonymous users, so the workspace system is invisible to them. The same caching setup that works for your anonymous visitors keeps working. The only thing to confirm is that your configuration is appropriate for the content editors using the site, which is standard practice.

Q. How about performance?

A. This is the most important architectural property of Workspaces. When the active workspace is live, which it is 100 percent of the time for anonymous users, the workspace system is invisible, and your production site performs exactly as if Workspaces did not exist. That has been true since the architecture was first built in the Content Preview System (CPS) in 2014, and it is why Workspaces has run on some of the highest-traffic sites in the world for over a decade. Inside a workspace there is some overhead, but that is editorial traffic, a tiny fraction of your total load. Editors get a full-site preview, and visitors get full production speed.

Content Safety and Security

Q. If public files are uploaded inside a workspace, are they accessible to users who know the URL?

A. Yes. File entities in Drupal aren't revisionable, so the Workspaces module can't scope a file to a workspace the way it scopes nodes. The moment a file is uploaded to public://, it's written to the default live storage in sites/default/files and served directly by the web server, with no Drupal access check in the request path.

So even when the node or media entity that references the file lives only in an unpublished workspace, the file itself is already on disk and reachable at its direct URL by anyone who has or guesses it. Publishing state doesn't gate it. Public means public, and only the obscurity of the filename keeps it from being found.

If the file needs to stay private until publish, use a private:// file field, which routes downloads through Drupal so access checks apply, or a module like File Unpublish, which keeps public files of unpublished media entities inaccessible until the entity is published.

Configuration Management: The Gray Area Teams Care About

Q. How does WSE Config interact with Drupal's configuration export/import system?

A. Once a workspace is published, whatever is live is what you would export, the same as always. For sites that manage configuration directly on the site rather than exporting it to code, this is largely a non-issue. For sites with strict configuration management workflows, WSE Config is still maturing (the session described it as almost production ready), so test it in a non-production environment before you rely on it in production.

Collaboration and Conflict Management

Q. What happens when two people edit the same content in different workspaces?

A. They cannot, and that is deliberate. Once an entity is modified in a workspace, it is tracked there, and another editor cannot modify it in a different workspace. This is a feature, not a limitation. Automatic merging of structured content fields, entity references, and media relationships leads to data corruption, and every system that has attempted it has run into fundamental issues.

Workspaces takes the same approach as a well-run development team: coordinate through communication. Shared workspaces let teams collaborate, content ownership keeps responsibilities clear, and WSE lets you move content between workspaces when needed. If content is locked, discarding the change frees it again. The absence of automatic merging is a safety guarantee: your workspace will never contain content you did not put there.

Q. How does Workspaces handle deleted content?

A. Deleting content in a workspace is a special case, because the content needs to disappear from your workspace preview while staying visible on the live site until you publish. Workspaces solves this with the Trash module. Within the workspace, deleted content drops out of listings, views, and search results, but on the live site it remains visible until publish. Content deleted in a workspace stays recoverable until you publish, and this integration also removes an older constraint so that any entity type can participate in workspaces, not just those with a publication status.

Content Moderation and Workflows

Q. How does Workspaces work with content moderation and Drupal's workflows?

A. Workspaces integrates with Drupal's core Workflows module. You can move an entire workspace through workflow states such as draft, review, approved, and published, so the whole collection of changes moves through the approval process as a unit. Your legal team reviews the complete workspace, your content manager approves the entire set, and when it reaches the publish state the whole workspace deploys atomically. The Content Moderation and Workspaces integration is nearly complete, with one remaining issue to resolve in core, and the simplified content workflow initiative will make the two work together for more complex scenarios where different entities need different approval paths.

Ecosystem and Future Considerations

Q. Does it work with Canvas?

A. Yes. Workspaces is compatible with Canvas. The implementation differs, because Workspaces aligns with the Layout Builder approach rather than Canvas's own, but the two work together.

Q. Why is Workspaces a good fit for AI content generation?

A. Workspaces gives AI content generation the boundary it needs. AI content tools are scaling quickly, and Drupal's AI module integrates dozens of providers with automators that can bulk-populate fields, generate summaries, and translate content. But AI is non-deterministic: it can hallucinate and produce errors. Workspaces provides the natural safety architecture. Think of a workspace like a pure function: everything inside is safe and reversible with no side effects. An AI agent can generate content, edit fields, and populate entire sections inside a workspace, and nothing touches live until a human reviews the changes and publishes. The workspace diff makes that review straightforward. The result is governed automation, where AI helps and humans stay in control.

Q. What is on the roadmap?

A. The architecture is sound, and the remaining work is about closing the last gaps and proving the system in the wild. Content Moderation and Workspaces are nearly integrated, with one issue left in core. WSE Config, which stages configuration changes alongside content, is almost production ready. WSE Theme lets you preview an entirely different theme staged in a workspace. What the system needs most now is real-world testing: try it with your contrib modules, test it with your custom entity types, and report bugs when you find them. Every production deployment proves the architecture.

Workspaces is stable, it is in core, and it is the right architecture for content governance at scale, including AI content generation.

13 Aug 2026 12:00am GMT

Every Drupal or Backdrop site sooner or later needs a safe copy to experiment on - plenty of us still build one by hand and live with the quiet fear that the copy touches production, and plenty more click a dev-environment button inside somebody else's walled garden. On a BOA server the whole workflow is delegated: one Ægir task clones the site from a fresh backup, and the copy arrives with the handbrake pulled - cron off, HTTPS off, files in its own store - then dev-prefixed names mark the copies as dev sites with their own larger limits, a dev alias flips PHP errors and caching into dev mode on that hostname alone, allow-lists and HTTP auth lock the copy down, extra clones Migrate onto updated codebases for staging, and a rename promotes the winner when it earns the crown - while to the rest of the stack the sandbox is a site like any other, nightly backups and edge protections included. Capabilities, not an enforced workflow - the safe route is the easy one, never the only one.

12 Aug 2026 7:20pm GMT

Eight additional Drupal GovCon respondents focus on the controls, human decisions, and content structures that keep digital systems usable when automation and changing discovery meet production reality.

12 Aug 2026 4:53pm GMT