Reopen ADR-119: a management surface makes the backend section question due

[CybotTM]

ADR-169 section 6 recommends reopening ADR-119. Accepting ADR-169 deliberately did not do that, and this issue is where it goes instead.

Why it is not part of the accepting change

ADR-119 pre-settles four answers for exactly this trigger: the section is called "AI", the identifier is netresearch_ai and never a bare ai, the flat entries are grouped by subject first, and old routes keep working through kept identifiers plus 'aliases' => ['nrllm'].

Applying those creates a new top-level backend section shared with nr_ai_search, nr_repurpose and the cowriter. That is a decision about three other products' backend UI, and it should not arrive as a side effect of retiring a permission grant in this repository. ADR-119's own status already reads Accepted (deferred — the placement is not finally settled, see Revisit), so nothing is misrepresented by leaving it until the question is put properly.

What has actually changed since ADR-119 was written

Two things, both verified rather than recalled:

• The count. ADR-119 described twelve submodules. Fourteen are parented to nrllm today, and a fifteenth nr_llm module — nrllm_aitasks — sits outside the tree under parent => 'web'. That correction landed in docs(adr): correct three stale counts and anchor the ones that carry an argument #808; the record now says fourteen and names nrllm_aitasks as explicitly not part of the number.
• The constraint that put it there. The module menu drops every top-level module whose own access check fails, so a child of the admin-only nrllm would be invisible to non-admins (ADR-131). A management surface has the same constraint. Without reopening ADR-119 it becomes the second flat web-parented module, and ADR-119's "twelve flat entries do not move as they are" arrives by accretion rather than by decision.

Has the trigger fired?

Not yet, by ADR-131's own account. Its trigger is "the first cross-consumer editor surface — a personal usage-and-budget view, a personal run history, or a lead-editor view over a group". nrllm_aitasks ships an actor-scoped run viewport, but ADR-131 states that "'Own runs' for editors is mostly the approver's view" and that agent runs "are currently started from admin surfaces". A personal run history is what that surface will become, not what it is.

So the honest position is: the trigger has not fired, and the next surface fires it. This issue exists so that surface does not ship first and settle the question by accident.

What closing it needs

A decision on whether the section is created, taken with the three sibling extensions in view rather than for nr_llm alone — and if yes, the :Status: and :Amended: edits on ADR-119 plus the four pre-settled answers applied.

Split out of #768 when ADR-169 was accepted. Ref ADR-119, ADR-131, ADR-169.

Assisted by claude-code:claude-opus-5 — Session

[CybotTM]

Maintainer input on the open decision, recorded here so it does not live only in a chat log: yes in principle to creating the section, and a question on the name — does "LLM" fit better than "AI"?

Answer: no, and the section stays "AI". ADR-119's four pre-settled answers are unchanged.

Why "LLM" is the worse fit

ADR-119 asked the same question ("should it be called 'LLM' or 'AI'?") and settled on "AI" with two reasons. One of them does not hold up:

Integrators look for AI.

That aims at the wrong audience. Per ADR-131 the section exists for editor-facing modules — the admin-only tree is fine where it is, under Administration. So the label is read by editors, not by integrators. Which happens to argue the same way: "LLM" is a developer's term, "AI" is the one an editor recognises.

The reason that does hold up is accuracy, and it is stronger than ADR-119 puts it. Of the four products that would share the section:

• cowriter — "AI-powered content creation in CKEditor"
• nr_repurpose — "Turn a webpage or PDF into a podcast, a diagram and an Instagram story" — audio and image generation, not language models
• nr_ai_search — hybrid retrieval, BM25 keyword search fused with bge-m3 embeddings via RRF. Embeddings are not an LLM.
• nr_llm — the only one the narrower name actually fits

A section called "LLM" holding a product called AI Search that uses no LLM would not merely be unfashionable, it would be wrong. "AI" is the accurate superset here, not the vaguer choice.

What is still missing before this closes

Two things, unchanged by the name being settled.

The trigger has still not fired. ADR-131 names it as the first cross-consumer editor surface — a personal usage-and-budget view, a personal run history, or a lead-editor view over a group. nrllm_aitasks remains the approver's view, with agent runs started from admin surfaces. The next surface fires it, and this issue exists so that surface does not settle the placement by accident.

Three other products have not been asked. The decision changes the backend UI of nr_ai_search, nr_repurpose and the cowriter. One product's maintainer leaning yes is input, not the decision.

Verification note

Module tree re-checked against main at adf57dce rather than recalled: nrllm is parent => 'tools', access => 'admin', with fourteen children all access => 'admin', and nrllm_aitasks the single parent => 'web', access => 'user' entry. That matches what this issue and #808 record.

The product descriptions above come from the GitHub repository metadata for t3x-nr-repurpose and t3x-cowriter. For nr_ai_search I could not verify the repository name — it does not exist at netresearch/t3x-nr-ai-search on GitHub and appears to live on GitLab; its retrieval design is quoted from working notes, not from the repository.

Assisted by claude-code:claude-opus-5 — Session