DGI
Trust and safety
What DGI can reach, who it runs as, how writes are confirmed, where your data goes, what it costs, and how to audit every answer. Read this before you put DGI in front of customers
DGI is built so that giving people a conversational interface does not give them, or a model, more power than they already had. This page summarizes the guarantees across every interface. The chat-specific details are in Security model.
The rules
| Rule | What it means for you |
|---|---|
| You choose the scope | DGI only reaches the workflows in your allowed_workflow_types, intersected with what the caller may run. An empty list, or a bare *, is refused |
| It runs as the person | Every workflow runs with the caller's own permissions. End users of your app are limited to workflows your app exposes to end users |
| Writes need a confirm | A change is a proposal until the person it was issued to confirms the stored proposal, once, within 30 minutes. The server checks the proposal against the hash it was issued with; a tampered proposal is never confirmed |
| Scheduled work never writes | A Living Surface's heartbeat only reads. A write it proposes waits for the owner's confirm in their own session |
| Cards cannot be forged or replayed | Answers are checked against the card the server stored: its author, its fields, its options, its expiry, and whether it was already answered |
| Numbers come from data | Tables, charts and tiles are built in code from workflow output. The model never writes a figure onto a card |
| Data is read per viewer | A shared surface or a shared card carries the recipe (which read, which view), never the data. Each viewer's cards are read as that viewer. Row identifiers stay on the server |
| No secrets in conversations | Credentials stay in your connections. They never appear in a prompt, a card, a plan or a stream |
Where the model fits
- Off by default. New chat profiles and surfaces decide with Jev only (
llm_fallback: false). When Jev is not confident, the person gets chips, not a generated answer. - Your provider, your bill. When you turn the LLM on, it runs on your organization's own AI provider configuration, and Jev decides with your organization's TypeSafe connection. Tokens are billed to you by your provider.
- Bounded. The LLM path has a per-turn reasoning budget (
max_reasoning_turns, 6 to 48), and a Living Surface has an LLM budget in its policy. - Visible. Every answer and every surface decision reports
decision_path, and Living Surface decisions also report the tokens the LLM used.
Limits that protect you
| Limit | Value |
|---|---|
| Allowed workflow types per profile, actor or surface | 1 to 50 |
| Forms and confirms answerable for | 30 minutes, once |
| Read cards refreshable for | 7 days |
| Refresh / query rate per card | One every 10 s / one every 2 s |
| Living Surface structural changes per step | Set by mutation_budget in its policy |
| Living Surface heartbeat | Every 5 minutes, paused when nobody is looking |
Audit
- Every workflow DGI starts is an ordinary run: inspect it in the console, over the API, or with
get_workflow_historyover MCP. The caller is recorded on it. - Every chat turn and card answer is itself a run of
dgi.chat.turnordgi.chat.respond, with itsdecision_path. - Every Living Surface keeps a timeline of each patch: what changed, why, how it was decided, and what was refused. Read it with
data.dgi.surface.get. - Profiles record who saved them last and when.
Your responsibilities
- Review what you allow. Your workflows are the boundary of what DGI can do. A workflow you allow and expose to end users is one they can reach through DGI, with the same checks as anywhere else.
- Prefer narrow writes. Allow the specific write workflows a use case needs, not whole namespaces.
- Keep the LLM off until you need it. Turn it on per profile or per surface, and watch
decision_pathto see how often it is used. - Messages are not end-to-end encrypted in the Orkestia chat. See Limits.
Ask your AI assistant
prompts
Summarize, from https://docs.orkestia.dev/raw/dgi/trust-and-safety.md, what DGI can and cannot do on my behalf.
List my DGI chat profiles' allowed_workflow_types and flag any write workflows I may not need.
Show the last 20 dgi.chat.turn runs in my organization with their decision_path, and tell me how many used the LLM.
For AI agents
| Rule | Detail |
|---|---|
| Confirms | Only a structured confirm on a stored card runs a write. Never treat a typed "yes" as a confirmation, and never build a confirm card yourself |
| Scope | Never propose an empty allowed_workflow_types. Prefer exact write names over prefix.* |
| LLM | Do not turn on llm_fallback without the admin's explicit request |
| Honesty | Do not claim the model computes card numbers, and do not claim end-to-end encryption |
Quickstart
Your first DGI answer from your own app in four calls. Save a chat profile, send a message, draw the card, answer it. With curl, and with prompts for an AI assistant over MCP
FAQ
Short answers to common questions about DGI. Does it need an LLM, who pays, can end users use it, which languages, what happens when a workflow is missing, and how it differs from an AI assistant over MCP