## Problem / Motivation Outside-in agents need to understand how a Drupal site actually produces public and operational outcomes before they act. Today, that site-specific truth often lives across routes, aliases, entity routes, bundles, fields, workflows, Views, Pathauto, Canvas pages, menus, custom routes, code signals, and runtime validation. Without that context, agents can make plausible but wrong decisions, such as: - creating a static page where an existing route, alias, View, Canvas page, or entity route already owns the surface; - creating the wrong bundle for a listing or detail route; - creating content that does not appear publicly because it misses bundle, status, field, filter, workflow, or alias rules; - assuming a menu item owns a route; - missing Pathauto/entity canonical URL behavior; - missing taxonomy archive behavior; - ignoring custom route/controller ownership; - treating Drupal-required fields as the only fields that matter; - overlooking code signals, unsupported filters, access logic, uninspected rendering layers, or duplicate path claims. Drupal already contains a large amount of this information. The missing piece is a Drupal-native source/generator that compiles those implementation signals into scoped, reviewable, provenance-backed context that agents can safely consume. This issue proposes an optional CCC context source/generator that builds a route-aware surface map of a Drupal site, then turns supported surfaces into structured site behavior contracts. A site behavior contract is a structured, provenance-backed description of how a Drupal surface works: what responds to a path, what content or configuration powers it, what actions affect it, what agents should not assume, and how the outcome can be validated. ## Why CCC is the right home CCC is the right home because generated site architecture context needs governance, not just generation. These contracts should be reviewed, revised, scoped, selected, and audited like other AI context. They need publication state, revision history, subcontext/progressive disclosure, scope matching, audience/persona targeting, usage tracking, and future programmatic/MCP access. The Site Architecture source should therefore feed CCC, not bypass it. Drupal generates the contracts; CCC governs and selects them; MCP/programmatic access can expose them; agents consume them. ## Proposed resolution Add an optional submodule, tentatively: `ai_context_site_architecture` The submodule should generate a route-aware surface registry and site behavior contracts from common Drupal site architecture signals. Each generated contract should have: - stable contract ID; - schema version; - human-readable markdown projection; - structured JSON payload; - path or path pattern; - effective responder; - semantic surface type; - content source; - alias owner, collection owner, rendering owner, navigation owner, where known; - action owners; - negative contracts; - validation checks; - confidence; - known unknowns; - provenance; - scope/audience tags; - generated timestamp and source hash for supported sources. Generated contracts should be written as unpublished CCC context drafts by default. Published context remains human-governed. AI disclosure: AI was used to help research and plan the above in partnership with a human directing, guiding, and evaluating the work.