Glossary
Terms as they appear in the product. Cross-references in italics point to other glossary entries.
| Term | Definition |
|---|---|
| Access request | A request from someone in a bridged Slack or Microsoft Teams channel who doesn’t yet have a Ronja account and wants to join your organization. Admins approve or decline it in the Inbox. |
| Admin | The role that runs day-to-day administration: people, settings, access groups, the data layer (connects sources, builds tables, schedules jobs), and content review. See the roles capability matrix. |
| Agent-visible fields | The only fields of a secret that Ronja may reference by name (for example a host or username). Sensitive values are never among them. |
| Allocation | A per-person credit cap for each billing period, set on the Control Center’s Rules tab by Admins with billing access: Credits per billing period, No limit, or Blocked. A personal exception overrides the role, which overrides the default for each person. It counts what the person runs, stops only their chats, and never stops an Admin unless it is Blocked. Separate from a weekly AI budget. |
| Allowed URLs | The list of hosts a secret or MCP server is permitted to reach — Ronja’s guardrail on where credentials can be used. |
| Answer | The titled, laid-out block a substantive reply arrives in, in Standard and Deep analysis modes: key figures across the top, charts beside the sentences that explain them, Caveats, How this was computed, Sources, and the follow-ups — Continue here chips and tangent buttons — at the foot. Ronja titles it; Answer is the heading when she gives it none. Short exchanges, Build mode, Saved Agent and automation output, Slack or Microsoft Teams replies, and a Standard or Deep analysis turn that closes with an inline app all come back as plain text instead — the app’s finding is the text above its frame. See Talking to Ronja. |
| API token | An admin-created credential for calling Ronja’s API. Shown exactly once at creation; can be limited to specific scopes or given full access within its role. See the API reference. |
| App | A published interactive application Ronja builds during explorations. It lives in a feature, has its own page you can open full-screen and send to a colleague, and is listed on the Apps page. Everyone who opens it sees it through the same one set of powers. Not an inline app. See Build an app and What’s the difference?. |
| Approve / Approve for session | The buttons on the in-chat approval strip when Ronja proposes a gated action. “Approve for session” skips re-asking for the same tools in this conversation; a legacy Pre-run approval gate always re-asks. A short list of actions asks every time — changing the organization policy, granting access to an Access Group, a Feature’s tables or a folder in Files, opening an Automation’s email trigger to any sender, creating a Ronja API credential, and the managed-database dev copies — and on a strip carrying one of those, Approve for session is not offered at all, only Approve and Reject. See Asking Ronja in a chat is not a way round it. |
| Approve & build | The button on a Build-mode plan. It is your go-ahead — clicking it starts the build without you typing anything — and it lets Ronja create, edit and delete resources in the feature the plan names without asking each time, for the rest of that conversation (deletions go to Trash). Withdrawable at any point; never covers sending email, deleting a whole feature or clearing a table, and never replaces admin review of shared changes. Beside it, Build, but ask me each time sends the same go-ahead without recording an approval, so every per-change check keeps firing. |
| Archive | Reversibly removing a resource from Ronja’s working view — the agent no longer sees it, but nothing is deleted. Distinct from Trash. |
| Chat composer | The message box, including Ask anything… on the home page. Sending your first message from Home starts a new exploration. |
| Automation | A trigger paired with an action: run a workflow or Saved Agent on a schedule, on an inbound email or webhook, when a watched table rebuilds, when a custom event is emitted, or when new mail arrives in a connected mailbox. See the automation triggers reference. |
| Awaiting approval | The status of a run that has stopped part-way through to ask a person to decide before it goes further. It is a Waiting run with a human on the other end: it stays there until an approver clicks Approve (the run carries on from where it stopped) or Reject (it fails), or until the request expires — 7 days by default, 14 at most. Decide it on the run page. See Monitor runs and traces. |
| Billing cycle | Your organization’s billing period. It runs anniversary-to-anniversary per organization, not necessarily by calendar month. |
| Billing page | The Super-Admin-only page showing the credit wallet, the Buy credits form, and purchase history. Not to be confused with the Usage page — see What’s the difference?. |
| Bridge | A connection between Ronja and one Slack or Microsoft Teams channel (or direct-message thread), letting your team talk to Ronja from chat. |
| Build access | Whether a person can use Build mode: on for everyone by default, and turned off per role or per person on the Control Center’s Rules tab. Super Admins always have it; User Read-Only members never do. |
| Build mode | The exploration mode in which Ronja designs and builds durable resources — tables, workflows, apps — writing a Plan first. Capability-gated per user. |
| Build (tables) | The step that turns a table’s inputs into queryable data. For the file push API, POST /build makes pushed files queryable. |
| Columns | The column-statistics view on a table (Field, Type, Rows, Missing, Cardinality, Examples). |
| Cancelled | What a workflow run a person cancelled reads in its automation’s run history, in the grey of a Skipped entry: not a failure, left out of the SUCCESS mini-stat, and nobody is notified. The workflow run itself reads Failed, its summary Cancelled by with the person’s name and how long it had run. Only a run on dedicated compute can be cancelled. See Cancel a run on dedicated compute. |
| Caveats | The short strip at the foot of an answer naming the limits of what it says — a month with no data, a currency that was not converted. Ronja writes it, and on screen it is not a warning that anything failed. One exception, and only outside the app: where the answer is sent on as plain text — Slack, Microsoft Teams, a mailbox, the Copy button — the strip also carries the line saying a chart couldn’t be drawn and was left out. See An answer looks wrong or unfinished. |
| Cleanup candidates | The Data map’s shortlist of tables worth considering for removal: nothing has queried them inside the window you chose, and nothing that reads them is still in use either. Based on recorded queries, so treat it as a shortlist to check rather than a verdict. |
| Codex | A searchable library of documents inside a feature — files, PDFs, images, or text you add so Ronja can find the right passage by meaning. Created by asking Ronja in Build mode; searched from the codex page or simply by asking her a question. See Codex. |
| Commit | Landing a draft onto the live version of a shared resource. Admins commit directly; others submit for review first. |
| Concurrency | The setting on a workflow or a Saved Agent deciding whether its own runs may overlap: Allow overlapping runs (the default) or Skip if a run is in progress, which makes it run one at a time and refuses a start that arrives while a run is still going. An automation has no such setting — it inherits whatever its action target carries, and a fire the target refuses is recorded in the automation’s run history as a Skipped run. A Table automation that is skipped runs once more shortly after the run in its way finishes, however many changes arrived meanwhile — unless its last three runs that actually ran were all such re-runs (a Skipped entry is not a run and doesn’t count), which is what an automation that changes a table it watches looks like; the entry then says it was not re-queued. No other trigger kind replays a refused fire. Elsewhere a refusal records no run at all: the caller is simply told which run is in the way. Both pages show the value read-only; you change it by asking Ronja. See Concurrency. |
| Connection | A configured connector instance attached to a feature, syncing an external system’s data into tables on a schedule. |
| Connector | An integration type (PostgreSQL, HubSpot, …). Ronja has 8 native sync connectors, 28 one-click OAuth services, 8 directly queryable database engines, and an agent-driven path for effectively any HTTP API. |
| Continue here | The strip of chips at the foot of an Answer offering the next question in the same conversation. Clicking one sends it as your next message, word for word as the chip reads. Contrast the dark branch buttons beside them, which fork a tangent instead. |
| Control Center | The admin page for governing AI spend, with three tabs: People (what each member can do and why), Rules (what each limit does, the monthly budget where there is one, and weekly budgets, allocations, build mode and model choice) and Spend response (spend steps and default models). See Control Center. |
| Credit extensions | The purchase-history table on the Billing page in an organization billed by invoice — every credit top-up your organization has bought. An organization that pays by card sees the same table as Receipts. |
| Credit pool | The organization’s credits for the current billing period, shared by the whole organization. The Control Center’s Spend response tab shows how much is used, and the spend steps fire on it. |
| Credits | Ronja’s metering unit — all usage is “metered in credits”. See Credits and AI spend. |
| Curate in chat | The way org Knowledge is corrected: there is no edit form — an admin tells Ronja what is wrong and she rewrites or retires the entry (“tell, don’t edit”). She no longer writes NEW entries; a new org-wide rule goes in the Organization policy, which you edit directly. |
| Daily AI safety limit | An organization-wide safeguard against an unexpected spike in AI use, such as a runaway agent or loop. Ronja sets a limit for the organization, and any Admin can set a lower one on the Control Center’s Rules tab (Credits per day, counted as on your bill); when today’s AI use reaches the lower of the two, AI pauses for everyone, automations’ Agents included, until 00:00 UTC. Workflows that don’t use AI keep running, and so does Ronja’s own background work, such as naming chats, which still counts. Not a billing problem, and separate from a weekly AI budget. See Daily AI safety limit. |
| Data dictionary | A table marked as the reference dictionary for a feature, linked to the data tables it describes. |
| Data map | Every table in your organization on one page: a graph of what feeds what, and a sortable list of what is still being read. Admins open it under Advanced in the sidebar; anyone can reach it from a table with Show in data map. See Data map. |
| Dead chain | Tables that feed each other and are all cleanup candidates — shown as one row on the Data map, with its members beneath, so raw → staging → mart is one removal decision rather than three. |
| Deep analysis | The rigorous, methodology-first exploration mode: Ronja designs the approach and maintains a Methodology document. Chosen on the start screen and fixed for the session. |
| Document | A formatted write-up Ronja authors in a conversation — a report or summary — saved as a file you can reopen, download as PDF or Word (.docx), or move into a shared folder. |
| Draft | Your private working copy of a shared resource (table, workflow, note, or app). The live version keeps serving everyone until the draft is committed. |
| Durable | The execution capability that lets a workflow remember the steps it has already finished. It can pause mid-run — waiting for a Saved Agent it handed work to, until a set time, or for a person to approve the next step — and pick up where it left off without redoing that work. A paused run shows the status Waiting, or Awaiting approval when it is a person it is waiting on. It is what every new workflow is — you do not ask for it. A workflow created before that became the norm may not be, and can be made durable by asking Ronja; the switch is one-way. |
| Edit with Ronja | The button on a published app’s page and its Details page, shown to the people who can change the app by asking Ronja (not to User Read-Only members). It opens a new Build-mode exploration with the app in the side panel and waits for you to say what to change; your change is a draft of the app until it is published, through review on a shared app unless you are an Admin or the feature’s maintainer. Greyed out, with the reason, when Build mode is off for your account. Unlike Update with Ronja, it is always there and starts nothing on its own. See Iterate. |
| Editorial policy | A per-note setting for who can suggest edits: “Admins only” or “Access Group members”. |
| Effort | The reasoning-effort level for a chat: Low, Medium, or High, on the pill above the message box. Selectable by everyone unless an admin has denied it for your role or for you; hidden while the organization is out of credits. A Saved Agent carries its own instead — see Reasoning effort. |
| Execution trace | The step-by-step timeline of a run: what it did, whether it is still running, and where the time went. See Monitor runs and traces. |
| Exploration | A conversation with Ronja — the core working surface. Private by default; shareable per person or access group. |
| Favorites | Pinned explorations and apps, shown at the top of the sidebar. Maximum 10 per type in each Space. |
| Feature | The central container in Ronja: a named bundle of tables, workflows, automations, notes, secrets, and apps that together deliver one outcome. See Features. |
| File outputs | The feature-hub tab listing files produced by workflow runs, grouped by the producing workflow. |
| Files (page) | The sidebar page where saved files live — chat saves, workflow outputs, and authored documents — browsable in folders. Your own saves stay private in My Files. See Files. |
| Folder | A container in Files that decides who can reach the files inside it; access flows down to its subfolders. Admins create top-level folders and manage their access. |
| Handover | Requesting a scope change for a feature — handing it from private to the organization. An admin approves; an Admin whose organization allows self-approval changes the scope directly instead, except through Hand over, which always waits for approval. |
| How this was computed | The collapsed section at the foot of an answer holding the method and the exact queries behind its numbers. Open it when you do not yet believe a figure — it is the closest place to check one without leaving the conversation. |
| Inbox | The admin review queue for pending handovers, proposals, edit drafts, moves, and access requests. It lives on the Shared features page — the Organization rules page holds settings, not the queue. Each feature also has its own Inbox: the waiting for review chip on the feature’s page opens the Inbox scoped to that feature, for an Admin or a maintainer of it. A review notification skips the queue and opens the item itself, whose page shows Waiting for review and Review; see Where approvals happen. Saved Agent and module rows are listed there but decided elsewhere. |
| Inline app | A small interactive app Ronja writes into one conversation in place of her written answer, marked Interactive in the answer column. It is not published: no feature, no page, no link, and it is deleted with the chat. It reads live data with the access of whoever is looking at it, so two colleagues can open the same one and see different things. Make it an App turns one into a published App. See Ask for an inline app. |
| Knowledge (note kind) | A feature-scoped reference note about that feature’s data — how a table behaves, what a metric really calculates. |
| Knowledge (organization) | The org-wide base Ronja consults in every conversation — terminology, business rules, KPI definitions. Browsed under Data & Knowledge → Knowledge, corrected via Curate in chat. Frozen: nothing new is added to it, and a new org-wide rule belongs in the Organization policy instead. |
| Lens | The Data map graph’s colour control: it paints every table with the answer to one question — Freshness, Usage, Cleanup, Health or Builds — under a legend that says what each colour means. None, the default, is the plain map. |
| Mailbox (connected) | An email account — your own, such as support@yourcompany.com — that Ronja reads incoming mail from and replies to in-thread as that address. Gmail and Outlook are both supported. Connected by an admin on the Mailboxes page by signing in to that provider as the mailbox itself — whichever account you sign in as becomes the connected mailbox, and the card shows which. An address with no inbox of its own can’t be connected: a Google Group has no inbox and no login, and a Microsoft shared mailbox has no password to sign in with — use a licensed user mailbox instead. One capability is Gmail-only: asking a colleague a question from this address and waiting for their reply (see Create a Saved Agent). The rest works on both, though a few things are shaped by what each provider offers — searching message bodies, and opening an attachment that is really a OneDrive link, are the ones worth knowing; Connect a mailbox says where. Not to be confused with email notifications or the routable address — see What’s the difference?. See Connect a mailbox. |
| Maintainer | Someone an Admin has put in charge of one organization-scoped feature — or a private feature’s former owner, who becomes one automatically when the feature is shared. A maintainer has full access to that feature, without holding the Admin role and only for that one feature: they see everything in it, create and edit everything inside it — tables, apps, workflows, notes, secrets, automations, Saved Agents, MCP servers, codexes and modules — and approve and commit colleagues’ proposals and drafts there, from the waiting for review chip on the feature’s page, the API or the CLI. What they see only through the grant they can use only inside that feature. They cannot change who can see the feature, move it, delete it or export it, and they cannot make anyone else a maintainer. An Admin grants it from the feature’s Access section — see Grant a maintainer and Scopes and sharing. |
| Manual-integration table | A table fed by files you push through the API instead of a connector. See the API reference. |
| MCP server | An external tool provider Ronja connects to as a client; its tools join Ronja’s toolbox. Created only through chat. |
| Methodology | The living research document of a Deep analysis session: goal, hypotheses, method, feasibility, and validation. |
| Model tier | A Saved Agent’s model class: Fast, Standard, or Mega — how big the model is. Paired with, but independent of, its reasoning effort. |
| Monthly budget | A limit an organization Ronja bills by invoice can have on its usage each billing period, counted as on the invoice without the platform fee. When it is used up, new chats and runs stop for everyone, admins included, until the next billing period or until an Admin raises it on the Control Center’s Rules tab; only Ronja can remove it. See Monthly budget. |
| Move request | A request to move resources between features. Your chosen items are seeds (locked in); auto-included dependencies are linked (can be excluded). |
| My Files | Your personal folder in Files — private to you. Files you save without naming a shared destination land here; administrators can still read them for governance. |
| Note | A document attached to a feature that teaches Ronja — kind Skill (a procedure) or Knowledge (reference facts). Written through chat. See Write notes. |
| Notification routing | The admin page under Governance where you choose which notifications your organization gets and where they go — the email addresses, and the Slack channels. Not the bell: this is where an admin decides who is told, for everyone. See Schedule an automation. |
| Notifications (the bell) | Your own feed of things Ronja needs you to see, at the bottom of the sidebar, with a count of the unread ones. Everyone has one and there is nothing to set up. A broken automation appears here whatever Notification routing says, and most of what Ronja emails you appears here too. Not all of it: some messages, including a request to approve a workflow run, arrive by email or Slack only. Clicking a notification opens what it is about — a request to review something opens the item waiting for review. |
| Organization | Your company’s Ronja account — the top-level container for all access groups, features, and members. |
| Organization policy | The organization’s standing rules, written by admins under Data & Knowledge → Organization policy and read at the start of every conversation and every automation. Capped at 20,000 characters. Where it disagrees with Your policy, it wins. See Policies. |
| Organization rules | The admin page under Governance → Organization rules that holds the organization’s settings: the self-approval rule, what Ronja may send by email, the email-trigger ingest prefix, the reporting timezone and currency, and whether Ronja may use web search. Reviews do not happen there (see Inbox), and it is not the Organization policy, which is written instructions Ronja reads. See Organization settings. |
| People property | A fact an Admin records about each person, such as Region or Job role. A property has values (North, South), and each person can have one value, several values or none, depending on the property (One value or Several values). Every member can see them; Ronja and apps use them. See People properties. |
| Personal memory | What Ronja recorded about you (role, preferences, working style), editable under Account → Memory and capped at 2,000 characters. She still reads it in your conversations but no longer adds to it — new standing preferences go in Your policy, which shows this text read-only under What Ronja remembers about you so you can copy across what is worth keeping. |
| Plan | The implementation plan Ronja writes and maintains during a Build mode session, shown in the build panel above the message box. |
| Policy | A short document of standing rules — how Ronja should work — read at the start of every conversation. There are two: Your policy and the Organization policy. Rules, not knowledge: a policy line points at the note or table that holds the detail. See Policies. |
| Proposal | A brand-new shared resource awaiting approval — “proposed as a new shared workflow”. Reviewed in the Inbox — a Saved Agent or module proposal is listed there but decided over the API. |
| Receipts | The purchase-history table on the Billing page in an organization that pays by card: every credit top-up, with a Receipt link for each card purchase. An organization billed by invoice sees it as Credit extensions. |
| Receiver URL | The public URL a webhook-triggered automation listens on. Treat it as a secret unless you add a signing secret. |
| Re-authorize | Refreshing an expired or revoked authorization (“Re-auth needed”) on a connection, integration, MCP server, or bridge. |
| Reasoning effort | A Saved Agent’s own thinking level — off, medium, or high — separate from its model tier: the tier is how big the model is, the effort is how hard it thinks before answering. Set by asking Ronja to package or edit the Agent, or over the API; the Agent’s page shows it read-only under Reasoning. It applies wherever the Agent runs, including the Chat with Agent panel on its page, and has no effect on the Fast tier, whose model does not reason. Unlike the chat Effort pill, it needs no per-user capability. |
| Reduced models | The cheaper model + effort that new chat turns switch to at a Switch chats to the reduced models step, protecting the remaining credit pool. A member’s own pick is kept. A person’s weekly budget or allocation never switches models. |
| Reporting currency | The currency your organization reports in, and how it writes numbers — set organization-wide by an admin on the Organization rules page, or over the API and the CLI. Unlike the reporting timezone, nothing freezes a copy: it applies live everywhere money is shown or built. The one exception is an app whose data genuinely is in another currency, which can say so with Amounts in this app are in (see Build a data app); the number format still follows the organization. Left unset, Ronja asks which currency to use rather than assuming one. |
| Reporting timezone | The timezone reports group days, weeks, and months in — separate from when a schedule fires. Set organization-wide by an admin on the Organization rules page, and carried individually by an automation, an app, a Derived table, a workflow, and a metric. On the last three it is fixed when the resource is created and does not follow a later change to the organization default. |
| Routable address | The private email address of an email-triggered automation — mail from allowlisted senders to this address fires the automation. |
| Run | One execution of a workflow or agent, with a status of Running, Waiting, Awaiting approval, Continued, Success, Warnings, or Failed. An automation’s run history adds statuses of its own, among them Skipped, Sender refused and Cancelled. |
| Runs (panel) | The exploration side panel listing every workflow and agent run spawned in this conversation, each with its execution trace. |
| Saved Agent | A reusable, callable agent — a saved prompt plus model tier, reasoning effort and tool grants — created and edited in chat, invocable from any conversation or automation. |
| Scope | Who can see a feature: Private (the creator and admins) or Organization (available across the organization — to access groups that attach it, and to any access group that shares all features). See the scopes reference. |
| Search | The find-anything modal (sidebar Search or ⌘K), covering everything you can already open in the Space you are in, grouped by kind. Inside a feature: the feature itself, its tables, workflows, notes, apps, Saved Agents, automations, MCP servers and secrets. Outside any feature: past chats — your own, the ones shared with you, and the chats in a project you belong to — matched on their titles, and a result opens that conversation. Also outside any feature: the organization’s managed databases, matched on their name and description and open to every member — Dev copies are left out. Admins additionally see the organization’s connected mailboxes, which nobody else does. Searching a tag name surfaces everything carrying that tag. |
| Secret | A stored credential record. Values are entered once and never displayed anywhere in the product — not even to admins. |
| Self-approval | An org policy deciding whether the admin who authored a request may approve it themselves — with any of their credentials: an API token counts as the Admin who created it, so it can’t approve that person’s work either. A token created long ago, or one whose creator has since left the organization, may no longer be recognized as that person’s; a deleted token instead makes a draft, proposal or move request it filed unapprovable by anyone while self-approval is disallowed, since no record of who filed it remains. Re-creating a token restores neither link — it’s a new credential. |
| Semantic search | Finding documents in a codex by meaning rather than by exact keywords, so a plain-language question surfaces the right passage however it’s worded. |
| Setup | The welcome screen with a task composer, editable starting ideas, and Explore first; reopened from the sidebar Setup button when shown. |
| Signing secret | An optional HMAC secret for a webhook-triggered automation, so only signed requests can fire it. Shown once at creation. |
| Skill (note kind) | A note that teaches Ronja a task or procedure, loaded automatically when a relevant request comes up. |
| Skipped | An entry in an automation’s run history recording a fire that ran nothing, or that the daily AI safety limit or the monthly budget stopped: the workflow or Saved Agent it points at is set to Skip if a run is in progress under Concurrency, one of that resource’s runs was still going, and this fire was refused. It is also recorded when you turn off, change or delete an automation while Ronja is waiting a minute to retry a workflow it couldn’t start, and when a queued catch-up re-run finds every table it watched deleted before it could run — which needs the automation to have been pointed at other tables first, since Ronja refuses to delete a table while one watches it; that last row names no blocking run and needs nothing done. Neutral, never a failure: a refused fire’s row names the blocking run, is left out of the SUCCESS mini-stat, and doesn’t count towards a run of failures. A Table automation refused this way runs once more shortly after the run in its way finishes, however many changes arrived meanwhile — unless its last three runs that actually ran were all such re-runs, when the row says it was not re-queued instead; no other trigger kind replays a refused fire. A fire the daily AI safety limit paused, whether its Saved Agent was stopped or its workflow failed on a refused AI step, is recorded the same way, labelled Paused — daily AI safety limit; it names no blocking run and is not run again later, on any trigger. A fire the monthly budget stopped is recorded the same way, labelled Paused — monthly budget used, and is not run again later either. Automations only — a workflow or Saved Agent whose start is refused records no run at all. See A run that was Skipped. |
| Soft limit | The credit-balance level at which Ronja warns admins and reduces model cost — without blocking work. When credits fully run out, runs are blocked until more are added. |
| Sources | The line at the foot of an answer naming every table it drew on, with its row count and when it was last updated — taken as the answer landed rather than from an earlier look. A table nobody has refreshed in a week is badged stale; one whose last build failed is badged build failed; one whose updates keep failing while it answers with its earlier data is badged not updating; one an upstream rebuild has invalidated is badged needs rebuild. A broken build carries a perfectly fresh timestamp, which is why the badge exists and the date alone is not enough. A table you don’t have access to is still named, without the figures. On a computer, hovering a source shows what that table is in one line, and the reason a failed build failed. |
| Space | A container for a body of work inside one organization: features, access groups, chats, files, tags, projects, managed databases and mailboxes each belong to exactly one, and every list shows the Space you are in. You are in a Space if an admin ticked you on its page, or if the Space includes everyone — Main always does, and admins are in every Space. Every organization starts with Main alone and most stay that way, in which case none of this is visible. Access groups work inside their Space: nothing shared with one reaches somebody who is not in its Space, while anything shared with you by name — a chat, a project, a feature you maintain — reaches you from any Space. Admin pages (the trash, the audit log, activity, usage) stay organization-wide; Users & Access follows the Space you are in, so its rows are that Space’s people and its columns that Space’s access groups. See Spaces. |
| Spend steps | Rules on the Control Center’s Spend response tab that fire at a percentage of the credit pool: Email a warning (to the people chosen in Notification routing), Warn members in chat, and Switch chats to the reduced models (see Reduced models). They never apply to a person’s weekly budget. |
| Standard (mode) | The default exploration mode for everyday analysis — ask questions, explore data, get answers. |
| Standard model set | The default model + effort for Analyst chats and for Build & deep analysis chats, used unless a member picks their own or a reduced-models step has fired. |
| Station | A screen or shared computer that shows one or more apps with nobody signed in, set up by an Admin on the Stations page. It reaches only the apps it was given, and what it does is recorded as the station, never as a person. Its link is its only credential. See Set up a station. |
| Structural dependents | Resources with typed references to another resource; they block deleting or archiving it until untangled. Free-text mentions (“content dependents”) merely dangle. |
| Submit for review | The drafter’s explicit hand-off that makes a draft reviewable — an admin can only approve after it. |
| Super Admin | The org owner role: everything an Admin can do, plus promoting admins, buying credits, registering login domains, and deleting the organization. |
| Sync | One import run of a connection. Verbs on the connection page: Sync now, Stop sync, Reset. |
| Sync schedule | When a connection syncs: Interval (every N hours) or Cron — mutually exclusive, minimum once per hour. |
| Table | The data primitive. Kinds: Foundation, Integration, Derived, and Dynamic — see the table types reference. |
| Tag | A shared, organization-wide colored label you attach to resources to group related work across features. Reused from one catalog everyone sees; filters the Shared features view and surfaces in search. See Organize with tags. |
| Tangent | A private branch forked from an exploration to try something without disturbing the main thread; fold findings back with “Summarize & return”. Offered under an Answer as a dark branch button — not to be confused with the Continue here chips beside it, which stay in the thread. See Tangents. |
| Trash | The 30-day recovery area for deleted items. Restore within 30 days, or an admin can delete permanently. |
| Untangle | “Untangle in exploration →” — an agent-assisted session that rewrites a resource’s dependents so it can be archived or deleted. |
| Investigate with Ronja | The button on a failing automation, workflow, or table build banner that opens a Build-mode exploration already diagnosing that failure. Requires Build mode access. |
| Up next | The single queued prompt waiting to run when Ronja finishes her current turn. |
| Update available | The chip on a published app’s page, shown to the people who can make a draft of it (not to User Read-Only members), when Ronja has changed how apps are built since the app was built, or the app still carries something Ronja no longer uses. These are recommended updates: optional, and the app keeps working without them. Its explanation starts Recommended, not required: the app keeps working as it is. and lists them. An app styled by hand, which taking them would restyle, gets no chip for that: its Details page offers the rework instead. Its Update with Ronja button opens a Build-mode exploration that updates the app as a draft, previews it and works through what to check; you check and publish the draft, and nothing changes in the app until you do. See App updates. |
| Usage page | The credit-usage breakdown (page heading “Usage & billing”) — what drove consumption this cycle, by source, user, model, and mode. |
| User | The everyday role: explore data, ask Ronja, upload files, create private features. |
| User Read-Only | The view-only role — sees shared content and the member directory, and can ask Ronja questions and run analyses in their own chats, or in a chat shared with them with Full access, including over files they attach, and have Ronja make documents and files into their own My Files, but cannot create or change anything shared. The default role for new invitees. |
| View / Full access | The two exploration share modes: View (read the conversation) and Full access (can also prompt). The owner always has full access. |
| Wallet | Your organization’s credit balance (“Total available credits”) — credits added minus credits used. |
| Watched tables | The tables a Table-triggered automation monitors; it fires when any of them finishes rebuilding. |
| Weekly AI budget | A cap on how many credits one person can spend in their chats with Ronja each week, set by any Admin on the Control Center’s Rules tab: a default for each person, per access group (a person gets the highest of their groups), or as a personal exception, which wins. Each person gets their own amount; it isn’t a shared pool. It resets every Monday at 00:00 UTC, never switches models and, unlike an allocation, applies to Admins too. See Set weekly AI budgets. |
| Withdraw | Cancelling your own pending request, draft, or proposal before it’s decided. |
| Workflow | A named, reusable, parameterized Python job Ronja writes for you — run it manually, from explorations, or via automations. See Create a workflow. |
| Access Group | A team’s grouping: members are added to access groups, and access groups decide which features those members can reach. An access group belongs to one Space and works inside it — its “everyone is a member” means everyone in that Space, and what it shares reaches nobody outside it. See Access Groups. |
| Your policy | Your own standing rules, reached from the account menu, read in every conversation you have and nobody else’s. Capped at 10,000 characters, edited directly — and Ronja can add a rule herself when you state a lasting preference, with an Undo on the card. See Policies. |