Book a Demo Talk to Sales

Curiosity Studio · Enterprise-native

Built for the people who run it.
Not added later.

Audit, monitoring, model cost, access control, sign in, backups and failover are part of Studio. They run on your servers, in the same install, with nothing else to buy or wire up.

Book a DemoTrust Center
One Studio, four kinds of control Curiosity Studio on your servers, with four groups of built in controls around it: observe (audit trail, metrics and uptime, LLM usage), protect (access groups, single sign on, encryption), recover (backups, failover, integrity checks) and change (change history, approval, policies). YOUR SERVERSCuriosity StudioOBSERVEAudit trailMetrics and uptimeLLM usageOBSERVEAudit trailMetrics and uptimeLLM usagePROTECTAccess groupsSingle sign onEncryptionPROTECTAccess groupsSingle sign onEncryptionRECOVERBackupsFailoverIntegrity checksRECOVERBackupsFailoverIntegrity checksCHANGEChange historyApprovalPoliciesCHANGEChange historyApprovalPolicies
One Studio, four kinds of control Curiosity Studio on your servers, with four groups of built in controls: observe, protect, recover and change. YOUR SERVERSCuriosity StudioOBSERVEAudit trailMetrics and uptimeLLM usageOBSERVEAudit trailMetrics and uptimeLLM usagePROTECTAccess groupsSingle sign onEncryptionPROTECTAccess groupsSingle sign onEncryptionRECOVERBackupsFailoverIntegrity checksRECOVERBackupsFailoverIntegrity checksCHANGEChange historyApprovalPoliciesCHANGEChange historyApprovalPolicies

05 · All in the Studio you run

Runs on Your servers Audit Chained, per event type Sign in Entra ID, Okta, SAML 2.0 Failover In seconds

Audit trail

Who did what, and proof that nobody changed the record

Sign ins, searches, views, downloads, changes, code runs, prompts to the assistant and every read of a secret. Pick a step to stop the drawing and read it.

An audit trail whose entries are chained On the left, the kinds of event being recorded: sign ins, searches, views, downloads and changes on, prompts off. On the right, a day’s audit file: one line per event with time, user and action. Each line is linked to the one before it, and a check walks the chain and finds it intact. RECORDSign insSearchesViewsDownloadsChangesPromptsAND PER NODE TYPEAUDIT-2026-11-02.JSONL08:59:12a.weberSigned in09:02:40a.weberSearched “bracket crack”09:03:05a.weberViewed NCR-223109:03:31a.weberDownloaded SB-27-114.pdf09:11:18j.itoChanged field Status09:14:52adminRead secret ERP keyCHAIN INTACT · 6 OF 6
An audit trail whose entries are chained The kinds of event being recorded, then a day’s audit file, one line per event. Each line is linked to the one before it, and a check finds the chain intact. RECORDSign insSearchesViewsDownloadsChangesPromptsTODAY’S AUDIT FILE08:59:12a.weberSigned in09:02:40a.weberSearched “bracket crack”09:03:05a.weberViewed NCR-223109:03:31a.weberDownloaded SB-27-114.pdf09:11:18j.itoChanged field Status09:14:52adminRead secret ERP keyCHAIN INTACT · 6 OF 6
  1. 01

    Choose what to record

    Turn on each kind of event, and each node type, one by one. The choice travels with your configuration.

  2. 02

    Every action, as it happens

    Who did what, to which record, and when. One line per event, in a new file every day.

  3. 03

    Each entry is chained to the last

    Every line carries a hash of the one before it, so changing any line breaks the chain from there on.

  4. 04

    Check the file

    The admin pages walk the chain and say whether the file is intact. Search, filter and download it there too.

Monitoring

See how it runs, now and over the year

Live metrics, a health check, a year of uptime and planned maintenance, in the admin pages. Live activity and the chats in progress stream as they happen.

Live metrics, health and uptime A chart of memory in use, sampled every second, with the newest sample marked. A health check for memory, disk and readiness, all passing. Thirty days of uptime for search, chat and indexing, with one planned maintenance window that users were told about. MEMORY IN USE · LAST HOURLIVE/HEALTHMEMORYDISKREADYUPTIME · LAST 30 DAYSSearchChatIndexingPLANNED · SATURDAY 22:00 · USERS TOLD
Live metrics, health and uptime Memory in use, sampled every second. A health check, passing. Twenty days of uptime for three services, with one planned maintenance window. MEMORY · LAST HOURMEMORYDISKREADYUPTIME · 20 DAYSSearchChatIndexingPLANNED · USERS TOLD
  1. 01

    Sampled every second

    Memory, queues, searches, indexing, the access checks: hundreds of metrics, kept for 30 days.

  2. 02

    A health check for your load balancer

    One address answers whether memory, disk and the graph are ready.

  3. 03

    A year of uptime

    Each service, in five minute buckets, for twelve months.

  4. 04

    Plan the maintenance, tell the users

    Set a window in the admin pages and Studio tells people before it starts.

LLM usage

Know what every model call cost, and cap it

Every call Studio makes to a model is recorded and priced. Spend is broken down by model, person and purpose.

LLM cost by model and by user, with a quota Twelve days of model cost, stacked by provider, with the total. Beside it, this hour’s use for four people against a cap. One of them reaches the cap and the next request is refused. COST PER DAY, BY MODELTOTAL 1,284.60TODAY 54.20ANTHROPICOPENAIMISTRALTHIS HOUR, PER USERCAPa.weberj.itom.silvaOVER THE HOURLY CAP · REFUSEDk.osei
LLM cost by model and by user, with a quota Twelve days of model cost, stacked by provider. Below, this hour’s use for four people against a cap; one reaches it and is refused. COST PER DAYTOTAL 1,284.60ANTHROPICOPENAIMISTRALTHIS HOUR, PER USERa.weberj.itom.silvaOVER THE HOURLY CAP · REFUSEDk.osei
  1. 01

    Every call is recorded

    Tokens in and out, cached tokens, time taken and errors, for every model call Studio makes.

  2. 02

    Priced from your own table

    Cost comes from a price per model that you keep, with its history, so old days keep their old prices.

  3. 03

    By model, by user, by purpose

    See which assistant, which team and which model the spend comes from.

  4. 04

    A quota stops a runaway

    Cap each user’s searches, messages and chat cost per hour. Past the cap, the request is refused.

Performance

Profile the live server from your browser

When something is slow, capture what the server is doing without logging in to it, and read it on the spot.

A CPU profile captured from the browser Four ways to capture: a CPU sample, a trace, allocations and a memory dump. A thirty second sample finishes, and a flame graph of a search request shows that counting facets takes most of the time. CPU SAMPLETRACEALLOCATIONSMEMORY DUMPSAMPLING 30 SSEARCH REQUEST · FLAME GRAPHRequestSearchRenderParseAccess checkFacetsJSONRead nodesCountCountGroup by typeCOUNT · 41% OF THE TIME
A CPU profile captured from the browser A CPU sample is captured from the admin pages, and a flame graph of a search request shows that counting facets takes most of the time. CPUTRACEALLOCATIONSDUMPSEARCH REQUESTRequestSearchRenderParseAccess checkFacetsJSONReadCountCountGroup by typeCOUNT · 41%
  1. 01

    Capture it from the browser

    A CPU sample, a trace, an allocation report or a memory dump, started from the admin pages on the live server.

  2. 02

    See where the time went

    Each bar is a step and its width is the time spent in it. Download the file for your own tools.

  3. 03

    Find the step to fix

    The widest bar at the top is where the time goes. Here, counting facets.

Usage analytics

Active users, sessions, searches, clicks, chats and records viewed, per day and per person. Counts only: nobody can read from it which record a person opened.

Running queries

Every query in flight, with how long each of its steps took. Cancel one that runs away.

Tuning without a restart

Change the runtime settings while Studio runs, and cap how much of the CPU indexing may take.

Captured when it matters

Open a window and Studio records an allocation profile by itself when garbage collection pauses run long.

Start up, step by step

A timeline of the last start and the ones before it, so a slow start shows where it spent its time.

Endpoints and tools

Calls, timings and errors for each code endpoint and AI tool, with the exceptions they raised.

Access control

Each person sees what they may, down to a field

Restrict a node type, a single field, an endpoint, an AI tool or an assistant to an access group. Search, the assistants and the generated tools all respect it.

One search, filtered for two people An engineer and a supplier search for the same words. The engineer, in the quality and engineering groups, sees five records with their prices. The supplier, in an external group, sees three, with the price field hidden, and two records are not shown. Asked why the supplier cannot see one of them, the admin pages answer that it is restricted to the quality group. bracket A320SEARCHENGINEERQUALITYENGINEERINGNCR-2231 Bracket crack1,240SB-27-114 Service bulletin380WO-88213 Work order380ECO-512 Change order380SN-0771 Supplier notice380SUPPLIEREXTERNALSB-27-114 Service bulletinWO-88213 Work orderSN-0771 Supplier notice2 RECORDS NOT SHOWNWHY NOT NCR-2231?Restricted to Quality
One search, filtered for two people An engineer sees five records with prices. A supplier sees three, with prices hidden. The admin pages say why one record is kept from the supplier. bracket A320ENGINEERQUALITYENGINEERINGNCR-22311,240SB-27-114380WO-88213380ECO-512380SN-0771380SUPPLIEREXTERNALSB-27-114WO-88213SN-07712 RECORDS NOT SHOWNWHY NOT NCR-2231?Restricted to Quality
  1. 01

    One search, two people

    An engineer and an outside supplier type the same words.

  2. 02

    Groups come with the sign in

    Each person’s groups are known before the search runs, from your identity provider or set by hand.

  3. 03

    Every record is checked

    The results are filtered record by record as they are built, so counts and filters match what each person may see.

  4. 04

    Down to a single field

    A field can be restricted on its own. The supplier sees the part, not the price.

  5. 05

    Ask why

    For any person and any record, the admin pages say which rule lets them see it, or keeps them out.

Identity

Your sign in, your roles, your keys

Studio uses the identity provider you already run, and keeps administrators to the least they need.

Single sign on

Microsoft Entra ID, Google, Okta, Auth0, AWS Cognito, OneLogin and SAML 2.0, or the headers your proxy sets. Company and department can come across with the sign in.

Roles you can split

Administrators, read only administrators and guests, plus ten narrower roles: manage users, run queries, manage models, publish trainings and more.

An admin write lock

Make every administrator read only. Unlocking takes a one time code from the server’s disk, lasts eight hours at most, and is written to the audit trail.

Sessions and passwords

Session lifetimes, a minimum password length and password expiry, stricter for administrators by default. Passwords are stored as salted PBKDF2 hashes.

Tokens with one purpose

An API token is scoped to one use, such as the library, a single endpoint or the MCP server. Every token is listed and can be revoked.

Secrets and encryption

Secrets are never sent to a browser, and every read is audited. Data at rest is encrypted under a key you hold; Studio will not start with the wrong one.

High availability

A server fails. Studio keeps answering.

Run read only replicas, or a cluster that picks a new primary by itself. Hand the primary over for maintenance from the admin pages, with no downtime.

A cluster electing a new primary Browsers send requests to node 1, the primary, and nodes 2 and 3 follow it. Node 1 becomes unreachable. Nodes 2 and 3 elect node 2 as the new primary within seconds, browsers send their requests to it, and node 3 follows it. BROWSERSNode 1PRIMARYNode 1UNREACHABLENode 2REPLICANode 2PRIMARYNode 3REPLICAELECTED IN SECONDS · NO RESTART
A cluster electing a new primary Node 1 is the primary and nodes 2 and 3 follow it. Node 1 goes down, node 2 is elected, and browsers follow it. BROWSERSNode 1PRIMARYNode 1UNREACHABLENode 2REPLICANode 2PRIMARYNode 3REPLICAELECTED IN SECONDS · NO RESTART
  1. 01

    Replicas follow the primary

    Every change on the primary streams to the replicas, which answer reads of their own.

  2. 02

    The primary goes down

    A machine fails, or loses its network.

  3. 03

    A new primary in seconds

    With three or more nodes, the others notice and elect a new primary. Nobody restarts anything.

  4. 04

    Browsers follow

    Studio tells browsers where the primary is now, and the remaining replica follows it.

Recovery

Back up, restore, start again

The routine work of keeping a system safe, scheduled inside it.

Backups on a schedule

Incremental backups run as a scheduled task, every night by default, keeping as many as you set.

Restore from the admin pages

Pick a backup and Studio restores from it on the next start.

Your configuration as files

Export the whole configuration: schemas, endpoints, AI tools, agents, indexes, access groups. Import it into another Studio, with a diff first.

Integrity checks

Have Studio check the graph and its files when it starts, before anyone uses it.

Updates you control

Update Studio from the admin pages, or switch that off and roll out releases yourself.

Retention

Keep chats for a day, a year or for good, set per assistant. Old connector runs and sandbox sessions are cleared on a schedule.

Change control

Every change tracked. Nothing from the assistant without you.

Studio’s configuration is code, and it keeps a record of every change to it: who made it, what it was before and what it is now.

Every change tracked, the assistant’s waiting for approval An admin saves an endpoint, and the change history records it with who made it and the code before and after. With a Git repository connected, the change is also a commit, pushed to your Git server. The admin assistant stages a change of its own as a diff; an admin approves it, and the history shows it as drafted by the assistant and approved by that admin. STAGED BY SUDO-++APPROVESTAGED BY SUDO-++APPROVEDSUDOENDPOINT EDITORSAVEDCHANGE HISTORYAI tool find-partSUDO · APPROVED BY A.WEBEREndpoint partsA.WEBER · 09:14Schema PartJ.ITO · 08:51Index settingsADMIN · YESTERDAYGIT · COMMIT A41C9E2 · PUSHED
Every change tracked, the assistant’s waiting for approval An admin saves an endpoint, and the change history records it with who made it and the code before and after. With a Git repository connected, the change is also a commit, pushed to your Git server. The admin assistant stages a change of its own as a diff; an admin approves it, and the history shows it as drafted by the assistant and approved by that admin. STAGED BY SUDO-++APPROVESTAGED BY SUDO-++APPROVEDSUDOENDPOINT EDITORSAVEDCHANGE HISTORYAI tool find-partSUDO · APPROVED BY A.WEBEREndpoint partsA.WEBER · 09:14Schema PartJ.ITO · 08:51Index settingsADMIN · YESTERDAYGIT · COMMIT A41C9E2 · PUSHED
  1. 01

    An admin saves a change

    An endpoint, an AI tool, an agent, a schema or a scheduled task, in the admin pages or through the API.

  2. 02

    Who, what and when, kept

    The change is recorded with the code before and after it, so you can see what changed and put an old version back.

  3. 03

    In your Git repository too

    Connect a repository and every configuration change is also a commit, pushed to your Git server.

  4. 04

    Sudo proposes a change

    The admin assistant edits a copy and stages a diff. Nothing is applied yet.

  5. 05

    You approve it

    Read the diff, edit it if you like, and approve. The history says Sudo drafted it and who approved it.

Change tracking

How Studio keeps track of changes

The same record, read from wherever you need it: the editor, a timeline for the whole Studio, your audit trail or your own Git server.

A history beside every editor

Code editors have a History button next to Save. It lists every saved version with who saved it, and what you typed in this browser since. See what each one changed, and put one back as one undoable edit.

One timeline for the whole Studio

The change history page shows every change to endpoints, AI tools, agents, skills, prompts, tasks and indexes, by day and hour, each with its diff. Filter it by date, by person, or by a word in the name or the code.

Deletions keep their last version

When a definition is deleted, its last code stays in the history with who deleted it, so it can be read and recreated.

Drafted by Sudo, approved by a person

A change the admin assistant drafted is marked as his in the history, with the administrator who approved it.

Commits in your Git repository

Connect a repository and every configuration change is written out as files and committed with who made it, then pushed to your Git server if you name one.

Saves that cannot collide

An editor saves against the version it opened. If someone changed it in the meantime, you get a merge view of both versions instead of overwriting theirs. Configuration changes also go to the audit trail when it is on.

AI governance

AI that stays inside your rules

The controls around the models are yours to set, and the models can run where your data does.

Chat policies

A keyword list, including one against prompt injection, and a safety classifier that runs on your own server. Block a message before it reaches the model, or flag it after.

An assistant that asks first

Sudo, the admin assistant, works on a copy and waits for your approval. A second review can sit between him and you.

Your choice of model

Anthropic, OpenAI, Mistral, AWS Bedrock and more, or a model on your own hardware through any OpenAI compatible endpoint.

Air gapped if you need it

Licenses are checked offline. Usage and error reports to Curiosity can be switched off, and outbound traffic can go through your proxy.

Your certificates

Serve Studio over HTTPS with your own certificate, the certificate store, or Let’s Encrypt.

In your people’s language

The interface is translated into 20 languages besides English.

FAQ

Questions about running Studio

Do these features cost extra?

They are part of Studio, not separate products. Some, such as the audit trail, single sign on beyond Google and Microsoft, and backups, depend on your plan; the pricing page and our team can tell you which.

Can I send Studio’s audit trail to our SIEM?

The audit trail is written as daily files with one JSON line per event, which a log shipper can read like any other file. You can also download it from the admin pages.

How do we know the audit trail was not edited?

Each line carries a hash of the one before it. The admin pages walk the chain and say whether a file is intact, so an edited or deleted line shows.

Does Studio send alerts by email or to chat?

Not today. Administrators get notices inside Studio, and the health check and metrics are there for your own monitoring to watch.

What happens if the primary server fails?

With three or more nodes in cluster mode, the others elect a new primary within seconds and browsers follow it. With a fixed primary and replicas, the replicas keep answering reads while the primary is down.

Can we see who changed something, and undo it?

Yes. Every change to code is kept with who made it and the version before, on a timeline in the admin pages and beside each editor, where you can put an earlier version back. Other configuration changes go to the audit trail when it is on, and to your Git repository if you connect one.

Can we limit what one person spends on models?

Yes. Set hourly caps per user on searches, chat messages and chat cost. A request past the cap is refused until the hour is over.

Your data. Your infrastructure.

Run it like the rest of your systems.
On your servers.

Book a Demo Talk to Sales