Kristen Pol Explains How Drupal’s Context Control Center Governs AI Context

Drupal teams evaluating Context Control Center (CCC) can manage reusable AI context as governed Drupal content, with capabilities such as moderation, revisions, translation, scheduling and scopes shaping what published material is available to an agent. That gives teams more control over the context supplied to a language model, but it does not determine how the model will respond.

Kristen Pol, a maintainer of Context Control Center, told The DropTimes that this distinction is central to how the project should be evaluated. CCC remains in beta, and Pol recommends using it for testing and feedback rather than production deployment, while relying on deterministic controls where legal, accessibility, safety or policy requirements must be enforced.

TDT[1]: What recurring problems motivated the central management of reusable context items rather than keeping that context within individual agent configurations?

Kristen Pol: Agent prompts can work adequately when a site has one agent and a small set of static instructions. The difficulty grows when the same policy, terminology, design-system guidance or site knowledge has to be duplicated across multiple agents.

CCC treats that reusable material as governed Drupal content. It can have ownership, moderation, revisions, translations, scheduling and scopes independently of any particular agent. At runtime, CCC determines which published context items are relevant to a request.

The benefit is both editorial and technical. Organisations can maintain shared context in one place while agents receive a bounded, task-appropriate subset. CCC manages context supplied to agents; it does not replace the agents’ underlying system-prompt configuration.

TDT[2]: How does CCC support prompt injection and tool-based retrieval alongside system prompts, RAG, vector search and Drupal’s existing structured-content tools?

Kristen Pol: CCC supports two complementary patterns. With push-based injection, selected context is appended to an agent’s system prompt. With pull-based retrieval, an agent can request context through CCC’s Context Tools.

The system prompt still defines the agent’s broader identity and behaviour. CCC supplies reusable, site-specific knowledge and instructions. It does not itself provide vector search or function as a general semantic RAG system, although it can be used alongside those approaches.

Automatic injection is useful when the context is bounded and predictably relevant, such as editorial policy, terminology or design-system guidance. Tool-based retrieval makes more sense when the material is larger or only occasionally needed.

You May Like

Article

JSON:API Views 8.x-1.2 Improves Route Performance and Cache Handling

Article

JSON:API Views 8.x-1.2 Improves Route Performance and Cache Handling

CCC is not necessary everywhere. A site with one agent and a few stable instructions may be better served by keeping those instructions directly in the agent configuration rather than adding another management layer.

TDT[3]: What comparative evaluation, if any, has been conducted with and without CCC, and what evidence currently supports claims that governed context improves AI output?

Kristen Pol: We do not have a formal published benchmark comparing CCC across models, providers and tasks. Claims around improving accuracy, relevance or consistency therefore should not be interpreted as a universal measured result.

The main demonstrations of improved output have been through Canvas AI, including demos shown in the Driesnotes in Vienna and Chicago. Without the additional context, page generation tended to be generic and made poor use of available components. With the appropriate context, the generated pages were more relevant, stayed on brand and used the design system as expected.

That is useful qualitative evidence, but it is different from a controlled benchmark. Teams evaluating CCC should compare it against their own baseline using representative tasks and consistent inputs. They should also test cases where additional context is irrelevant or contradictory, because adding context does not automatically make an LLM response better.

TDT[4]: What is the strongest publicly discussable testing or implementation of CCC so far, and what has that work contributed to the project?

Kristen Pol: CCC is still in beta, and that is important: nobody should be using it in production at this stage.

Testing and feedback have come from several groups. Community members have been trying to integrate with CCC, the UX team and development team have been testing it, and Drupal Easy has been working with it while creating Drupal AI training.

That feedback has continually gone back into the roadmap and the implementation. It is one of the main reasons 1.0 has not been released yet. The project is still using this beta period to learn where workflows, integrations and developer experience need improvement.

We therefore do not have a production case study that we should present as proof of real-world impact. The evidence at this stage comes from demonstrations, integration work and structured feedback during development.

TDT[5]: Which Beta 3 capabilities can teams meaningfully evaluate today, which areas remain less predictable or experimental, and what should teams understand about the project’s current stability?

Kristen Pol: CCC remains in beta. Drupal’s release guidance treats beta releases as pre-stable software that is not yet ready for production use, while noting that individual contributed projects may vary in their release practices. For CCC specifically, APIs and configuration may still change between releases, and our current recommendation is to use the beta for evaluation, testing and feedback rather than production deployment.

Beta 3 allows teams to work with the core CCC concepts and workflows, including creating and governing context items, controlling publication state and revisions, applying scopes, configuring inclusion and exclusion, and working with item and token limits.

Some areas are inherently less predictable. Conditional subcontext, for example, involves an LLM in deciding which child context is relevant, so teams should not expect the same determinism as they would from ordinary Drupal configuration. Optional integrations also have their own maturity and dependency considerations. The Document Loader integration was still experimental in the Beta 3 release, although its status changed later on the 1.0.x development branch.

Before 1.0, some compatibility and support expectations also remained unsettled. These include stable API commitments, migration paths for integrators, the final behaviour of optional or experimental integrations, and documented upgrade and support expectations for a stable release. Feedback from community integrators, the UX and development teams, Drupal Easy and others continues to shape that work.

The purpose of evaluating Beta 3 is therefore to identify where the workflows and integrations work well, where they need improvement, and what still needs to stabilise before 1.0.

TDT[6]: Conditional subcontext allows an AI model to decide whether a child context item is relevant. How reliable is that process, what happens when provider selection fails, and how should teams handle context that must not be omitted?

Kristen Pol: Conditional subcontext is different from the deterministic parts of CCC because an LLM is involved in deciding whether a particular child context is relevant to the task. Teams therefore should not expect those decisions to be perfectly reproducible across different models, providers, model versions or separate requests.

In Beta 3, conditional children for a parent are skipped if no provider or model is configured, if the provider does not support chat, if the per-request conditional-parent cap has been reached, if the provider call throws an exception, or if the response cannot be decoded as a JSON array of child IDs. Malformed output or a non-list JSON structure is treated as a failure. If the response is a valid JSON array but contains a non-scalar entry, all conditional children for that parent are skipped.

A valid empty array, [], is not treated as a failure; it means the model selected no conditional children. Unknown child IDs in an otherwise valid array are ignored, while recognised IDs may still be included.

Required children do not depend on that AI relevance-selection step when their parent has been selected. That does not, however, mean they are guaranteed to survive the later token-rendering stage.

For that reason, information that must always be supplied—such as mandatory legal, safety or policy guidance—should not be configured as conditional context. And, used sparingly, global context items can be configured.

There is still an important limitation. Token limits can affect what is ultimately rendered, and successfully instructing the LLM does not guarantee that the model will follow it. Context remains guidance to the model, not deterministic enforcement.

One related behaviour has changed on later 1.0.x: in Beta 3, disabling conditional AI selection caused conditional children to be included without an AI call, while later 1.0.x excludes those children from normal selection.

TDT[7]: How do CCC’s permissions work for published context, and what should developers keep in mind when AI workflows involve information with different access requirements?

Kristen Pol: Two permission areas are useful to distinguish.

One controls who can view published context items. Those permissions matter when context is injected into an agent request or returned through Context Tools.

The other controls who can use the CCC interface to create or edit context items.

When designing an AI workflow, teams also need to think about the permissions around the underlying information represented by that context. Giving someone permission to receive a published CCC context item does not automatically resolve the access requirements of every piece of Drupal content or data that the workflow may interact with.

Sensitive information therefore needs to be handled deliberately. Developers should continue to use Drupal’s normal access controls for protected content and test AI workflows with the permissions of the users who will actually invoke them.

CCC can help determine which governed context should be made available to an AI interaction, but it should not be treated as a replacement for the application’s underlying authorisation model.

TDT[8]: Given that context injection is guidance rather than deterministic enforcement, how should teams approach legal, accessibility, safety or other requirements that the model must follow?

Kristen Pol: The context items supplied to an LLM are suggestions in the same sense that prompts are suggestions. The resulting response remains non-deterministic, just as with any other LLM interaction.

CCC can make important policy information more consistently available. Global items, always-included items and required subcontext can improve the reliability of delivery, while moderation, revisions and scheduling provide governance over the material itself.

None of those mechanisms proves that the model noticed, interpreted or followed the requirement correctly.

If a requirement cannot tolerate probabilistic compliance, enforcement has to happen elsewhere. Depending on the use case, that may mean conventional Drupal access controls, deterministic business rules, structured output validation, guardrails, audit mechanisms or human approval.

Those controls sit at different points in the workflow and address different risks. Access control—including Drupal permissions, entity access and workflow visibility—determines who can see or change content and which data an AI workflow is allowed to access. It can prevent unauthorised exposure, but it does not prove that the model followed a policy in its response.

Deterministic business rules apply fixed logic before or after the model runs—for example, blocking an action, rejecting invalid input or requiring a particular moderation state. They enforce site policy in code regardless of what the LLM suggests.

Output validation and guardrails focus on the model’s response. They can check structure, required fields, blocked patterns or policy rules before generated output is stored, published or acted on. Guardrails may themselves be deterministic or may use additional model-based checks, but their role is to evaluate output rather than supply context.

Human approval provides a final gate where a person can accept, edit or reject AI-generated results before they take effect, particularly for high-stakes content or actions.

Audit mechanisms such as logging, usage tracking and revision history do not enforce compliance by themselves. They record what happened so teams can investigate failures and improve controls elsewhere.

CCC’s role is upstream of these mechanisms: it makes governed context available to the model. The other controls are what enforce access, validate output or require sign-off when probabilistic model behaviour is not enough.

TDT[9]: What can CCC’s usage tracking tell teams today, and what can it not establish about whether the model actually used or followed the selected context?

Kristen Pol: In Beta 3, usage tracking stores identifiers and operational metadata rather than the content supplied to the model. A usage record can include the context item ID, agent ID, runner ID, route path or paths, tool plugin IDs, and an optional related entity type and ID, along with created and changed timestamps.

It does not persist rendered context text, context item content or prompt bodies.

That information can help teams see which context items are being selected, which agents are involved, where those agents run, which tools are associated with requests, and whether particular entities are involved. It can be useful for identifying context that is rarely selected, context that may be appearing more broadly than expected, and patterns in how CCC is being used during testing.

Optional debug logging is separate from usage tracking and is disabled by default. When enabled, CCC writes selection and rendering diagnostics to Drupal’s standard log. Those entries do not contain the full rendered context, but they may include truncated task text of up to 100 characters and, when conditional-subcontext parsing fails, a truncated provider-response snippet of up to 200 characters. The settings interface warns that debug logs may therefore contain fragments of user prompts or agent task descriptions. Renderer diagnostics record item IDs and token-limit events rather than context content.

What neither usage records nor debug logs can tell teams is whether the LLM actually paid attention to a selected context item or followed the instruction contained in it.

The fact that CCC selected and supplied an item establishes that the context was made available to the model. It does not establish compliance, answer quality or causality. Full prompt and context content may still be sent to the configured AI provider as part of the normal model request, but that sits outside CCC’s usage-tracking records.

Evaluating whether context changed or improved the result therefore requires examining the resulting outputs and applying appropriate evaluation criteria, whether through automated checks, human review or both.

Integration with ai_observability is planned for after 1.0. That may replace much of CCC’s current usage-tracking functionality, although we have not yet decided whether usage tracking will disappear entirely or retain a more contained role. Migration and compatibility details are also not yet settled.

TDT[10]: CCC is being developed within the Drupal AI Initiative, where LLM-assisted development is accepted. What review and provenance practices apply to AI-assisted contributions, and what kinds of problems do you find yourself correcting?

Kristen Pol: Because CCC is being developed as part of the AI Initiative, we accept and even welcome LLM-assisted and LLM-generated issues and code.

Drupal’s policy on the use of AI when contributing makes contributors responsible for what they submit. They are expected to understand and verify AI-assisted work, including its logic, dependencies and security implications, and significant use of AI must be disclosed.

At the project level, the ai_context merge-request template includes controls for disclosing how AI was used in a contribution, alongside review and testing checks. That provides an explicit review and disclosure step for contributions to CCC.

Separately, I have my own additional review practice as the main maintainer doing the final reviews and merges. I run code through an additional LLM review as well as reviewing it manually myself. I try to use different models as a cross-check. If I create something with one model, for example, I may review it with another and go back and forth before doing the final human review. For more complex issues, I may cross-check with multiple models.

With LLM-generated code, a lot of the changes I end up requesting are around developer experience rather than basic accuracy: reducing unnecessary helper methods, reusing code, improving naming, simplifying an implementation or refactoring it into something easier to maintain.

That said, sometimes the model simply does the wrong thing, and I have to correct it. AI assistance does not remove the need for contributors and maintainers to understand, review and take responsibility for the final code. That principle is also reflected in Dries Buytaert’s discussion, “Never submit code you don’t understand.”