Configuring the ORIA Reasoner

Audience: ARPIA administrators. End users should refer to How to Use the ORIA Reasoner.

ORIA Reasoner does not work out of the box. Before any user can run a session, an administrator must configure a Model Group for it. If this is left unset, ORIA Reasoner — and the model picker inside a session — is disabled.

Setup Checklist

1–3. Model Group and File Object Store

1. Go to ARPIA / AI Governance / Configuration.
2. Under Global AI Configuration, confirm AI is enabled for the work-area (Enable AI in this work-area = Yes).
3. Under Manage Model Groups, create the group of LLMs you want available (e.g., openai/gpt-5.5).
4. Back in Global AI Configuration, under Assistant Model Groups, set:
   • ORIA Reasoner — Model Group (required) — restricts ORIA Reasoner to this group's models, in order. If left unset, ORIA Reasoner is disabled. [CONFIRMAR: exact field label in the current build]
   • ORIA Reasoner — file object store (required for uploads) — the object-store bucket where files uploaded during an exploration are saved, so the file-reader can fetch them. Leaving this as "None" disables document uploads. [CONFIRMAR: exact field label in the current build]
5. Click Save Configuration.

Model Groups are per-assistant, not global. The same screen also sets the Oria (Workshop & SPA) — Model Group, a separate and equally required setting for Oria inside Workshop objects and the SPA builder. Configuring one does not configure the other. A work-area where the Workbench works and the Reasoner doesn't is almost always this.

Model order matters. The group defines both which models are available and the order in which they're offered. Put the model you want as the working default first.

4. Institutional Memory (Cerebro)

Institutional Memory is on by default in every Reasoner session, scoped to every domain the user's profile can access. It is not an opt-in feature you enable per user — it's a default you are choosing to leave in place.

Two administrator responsibilities follow from that:

• Work-area enablement. Cerebro must be enabled for the work-area separately from the Reasoner's Model Group.
• Domain scopes. Users need read_only on the domains they will query, and read_write on any domain they will save to.

Domain access is granted, never revoked. There is no action to remove a user from a domain or to change an existing scope (read_only → read_write). Both require an administrator, and the direction of travel is one-way in practice. Grant deliberately.

Scratch and test domains are visible in the user-facing picker. They appear alongside authoritative domains with no visual distinction. Expire or retire test domains rather than leaving them in circulation.

Full behavior, including save consent and the edit window, is documented in How to Use Institutional Memory (Cerebro) in the ORIA Reasoner.

5. Permission-Gated Tool Categories

Three of the five tool categories in the Session Tools dialog are granted per profile. Until granted, users see an empty tab — expected behavior, not an error.

Internet Tools and Artifact Tools are not permission-gated. Any user with Reasoner access can enable them.

Capabilities Available Without a Grant

Two Artifact Tools provision or execute rather than visualize, and are available to any Reasoner user by default:

Neither writes to your ontology without a governed Ontology Action, and Oria Machine requires human approval to act. But both create durable state outside the session, and neither is gated the way Ontology Actions, MCP Collections, and Connected Apps are.

Worth deciding explicitly whether that matches your governance posture, particularly if your change-management process treats database provisioning as a controlled activity. If it doesn't, the control point is profile-level Reasoner access itself, not the tool picker.

Troubleshooting

Related

• How to Use the ORIA Reasoner — end-user guide
• How to Use Institutional Memory (Cerebro) in the ORIA Reasoner
• AI Governance — Configuration
• Understanding ARPIA's Permission System