--- title: "ADR-119: Where the backend modules live — Administration, for now" manual: "TYPO3 LLM Extension" version: "0.35" permalink: "https://docs.typo3.org/permalink/netresearch/nr-llm:adr-119@0.35" source: "Adr/Adr119BackendModulePlacement.rst" modified: "2026-09-16T22:09:16+00:00" --- # ADR-119: Where the backend modules live — Administration, for now - *Status:* Accepted (its placement decision was overturned; the section now exists and the four pre-settled answers below have been applied) - *Date:* 2026-07-28 - *Amended:* 2026-08-22 by [ADR-183](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-183@0.35) - *Authors:* Netresearch DTT GmbH ## Context nr_llm registers a parent module `nrllm` with fourteen submodules — overview, providers, models, configurations, tasks, snippets, use-case packs, setup wizard, skills, tools, MCP servers, playground, agent runs and analytics — under TYPO3's **Administration** section. `grep -c "'parent' => 'nrllm'" Configuration/Backend/Modules.php` answers fourteen, and is the count to re-derive rather than trust this sentence. A fifteenth nr_llm module, `nrllm_aitasks`, is parented to `web` on purpose ([ADR-131](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-131@0.35)) because the menu hides a child whose parent's access check fails. It is not a submodule of this tree and must not be folded into the number by a later reader correcting it. The question raised: should this become its own top-level section, a sibling of Content, Media, Sites, Administration and System, and should it be called "LLM" or "AI"? Two arguments were made against a section and both turned out to be worthless, which is why they are recorded here rather than quietly dropped: **"They are all admin-only modules, and Administration is the section for admin-only modules."** Access level is not the grouping principle. In the core, `site` holds `site_configuration` (`access => admin`) next to `link-management` (`access => user`), and `system` is `systemMaintainer` — stricter than admin, not the same. Sections mix access levels, so this explains nothing. **"A move is expensive."** It is — the `nrllm` route and its bookmarks, the `setShortcutContext` calls, the docheader submodule dropdown, the module identifier spread across the documentation and its backend screenshots, and `t3_cowriter`'s `position => ['after' => 'nrllm']` anchor. This record originally counted them: two calls, 33 references in 20 files, roughly 17 screenshots. Every one of those has since grown. The figures are dropped rather than maintained, because cost answers "what does it take", not "what is right". The two must not be confused. ### What the sections actually are The core's own definitions (`cms-core/Configuration/Backend/Modules.php`) group by **subject**: content is where writing happens, media where files are worked with, site where sites are configured, system the installation itself. Administration is where the instance is administered. The core also, in v14, added `integrations` — `parent => 'admin'`, `dependsOnSubmodules`, `showSubmoduleOverview` — which is structurally the same shape as `nrllm`. That is the core's own answer for a cohesive group of admin-facing extension modules: a container under Administration, not a new top-level section. ### The argument that actually decides it Everything above points at Administration — as long as nr_llm's modules stay a place where a capability is *configured and inspected* rather than a place where work is done. They do not stay that, and the reason is not the editor action API. That API (see the roadmap) surfaces AI actions inside the consuming extension's UI, on the record the editor is already working on, so it argues *for* leaving nr_llm where it is: an editor would never open an nr_llm module. But a consumer's UI can only ever show data in that consumer's context. An editor also needs **cross-consumer** answers about themselves: - what is my budget, and how much of it have I used? - which tools am I allowed to use? - which skills apply to me? - what did I run, across every consuming extension? and a lead editor needs the same for their editors, or for a group. None of that is expressible in a consumer's UI, because it is by definition not about one consumer. It is editorial self-service, and it has no home today: the analytics module aggregates instance-wide and is admin-only, no per-user history exists, and per-user budgets have no user-facing view at all. Once those surfaces exist, nr_llm's module tree is no longer an administration toolset, and the subject argument flips: AI becomes a place where work happens, on a par with Content and Media. ## Decision **Keep the modules under Administration for now. Do not treat this as settled.** The cross-consumer editor surfaces do not exist yet, and building a top-level section for users who cannot yet be served by it would be premature. Nothing about the current placement blocks them. ## Revisit Reopen this the moment the first cross-consumer editor surface is planned — a personal usage-and-budget view, a personal run history, or a lead-editor view over a group. That is the trigger; not a count of modules, not a preference about menus. When it is reopened, these are settled in advance: - **The section is called "AI", not "LLM".** It would hold tasks, skills, tools, agent runs and analytics — not just language models. Integrators look for AI. - **The identifier is vendor-scoped** (`netresearch_ai`), never a bare `ai`. Module identifiers merge last-package-wins, so a generic top-level identifier is a shared namespace with no owner: the label and icon would depend on package load order, and removing the owning extension would strip the routes of any foreign submodules parented to it. - **Fourteen flat entries do not move as they are.** They read as a dumping ground at any level. Group them by subject first — setup (provider, model, configuration), authoring (tasks, skills, snippets), operation (tools, playground, runs, analytics) — and let the section hold three or four entries. - **Old routes keep working.** Keep the submodule identifiers and explicit paths, repoint `setShortcutContext` from `nrllm` to `nrllm_overview`, and give that module `'aliases' => ['nrllm']` so existing bookmarks resolve — valid only once `nrllm` is no longer a registered identifier, since an alias is shadowed by a real module of the same name. ## Consequences - No code changes. The placement, identifiers, routes and documentation stay as they are. - The discoverability problem is real and remains: TYPO3's module menu renders two levels, and nr_llm's fourteen submodules sit at the third, so they are invisible from the main menu. That is worth fixing on its own terms — by strengthening the Overview as the hub, or by grouping the fourteen — and does not require the top level. - If the editor surfaces are built without reopening this ADR, they will land in an admin-only section where their users cannot reach them. The revisit trigger exists to prevent exactly that.