Operations guide¶
For people who run, configure and operate Data Director at an institution: the research data management team, a service owner or a systems administrator. It is not for researchers who use the app (see the user guide) or for people who write agents (see the developer guide).
An operator decides three things that a user and a developer do not:
- What the instance may do. The institutional profile names the agents that may run, the actions that need a person's approval, and the agent a researcher converses with.
- What leaves the institution. An agent that calls a hosted AI model sends it part of the user's input. AI models says which agents do, what they send, and how to choose and supply a model.
- Who holds which secret. Model keys, the operator's identity and the site's password each have one place to live. Configuration lists them.
In this guide¶
| Page | Read it to |
|---|---|
| AI models | Choose a model, supply a key, turn on the model-backed agents, and check what an instance sends to a provider. |
| Configuration | Find where each setting lives, in development and on a server. |
| Deploying to a VM | Install the app and its agents on an Ubuntu VM and keep it up to date. |
| Institutional profiles | Write the rules that apply to every run. |
The architecture and the specifications explain why the system is built as it is.
Limits of the alpha¶
- People can sign in with ORCID (configuration), but the
deployment scripts do not set it up yet (#155), and everyone signed in sees every run (#153).
Without sign-in, every run acts for the operator named in
DD_PRINCIPAL_ID, and the site's password is the only access control. Keep the app and agent ports on loopback or a private network. - No notice reaches anyone when a deployment fails (#144), and GitHub does not show what is
deployed (#145). The journal and
systemctl --failedare the record. - A profile cannot yet limit which models may receive which class of data (#40).