CASPER
Try it / Sign in

How it is built

How CASPER is built

CASPER is a platform of several layers. A request passes through each of them, and the rules of the first layer apply to everything below it. This page describes the design in plain words.

How a request is handled

How a request is handled Five steps. You sign in. CASPER works out who you are and which projects you belong to. It finds evidence only in what you may read. It uses tools with a confirmation for any change. It gives an answer in which each claim shows its source. 1. Sign in Your university or CASPER account 2. Who you are Your role and your projects 3. Find evidence Only in what you may read 4. Use tools A confirmation for any change 5. Cited answer Each claim shows its source How a request is handled Five steps. You sign in. CASPER works out who you are and which projects you belong to. It finds evidence only in what you may read. It uses tools with a confirmation for any change. It gives an answer in which each claim shows its source. 1 Sign in Your university or CASPER account 2 Who you are Your role and your projects 3 Find evidence Only in what you may read 4 Use tools A confirmation for any change 5 Cited answer Each claim shows its source

The layers

  1. Access and policyEvery request carries who is asking and for which project. Sign-in uses the university account, or a CASPER account for collaborators without one. Roles and project membership decide what can be read and which tools can be used. This is decided in code before any model is asked, from the verified identity, never from anything said in a conversation. Each answer and action is recorded.
  2. OrchestrationA router decides what kind of request it is (a knowledge question, a data question, an operations check, code or a support request) and hands it to the right specialist assistant. Skills tell an assistant how a team likes a task done.
  3. KnowledgeTeams choose what CASPER may read. Sources are synced on a schedule, checked for credentials, labelled with their project and the level of access they need, and split into passages. Retrieval combines several methods, results are merged and re-ranked, and the answer is written only from the best evidence, with each citation checked.
  4. ToolsTools are small services built by CamCEAD on the open Model Context Protocol (MCP), a standard that lets an AI assistant call tools in a controlled way. They read, inspect or prepare work. Anything that would change a system needs an administrator and an explicit confirmation, and the checks run again when the tool runs.
  5. ModelsCASPER does not depend on one model. A router chooses a model lane for each request by the task and by how sensitive the project is. Commercial models, for example Claude from Anthropic, handle the hardest work such as long documents and careful reasoning, and only for projects that allow it. Open models, hosted and managed by CamCEAD on research computing, do routine work such as analysing questions, indexing documents, reviewing answers and turning recordings into text.
  6. OperationsA fixed set of reference questions with known answers is run automatically, and every change to a model, a tool or a setting is measured against it before it is adopted. Monitoring watches the other layers, so that a regression is found by evidence and not by a user reporting it first.

Governance

Project separation

The knowledge of different projects is kept apart, and the separation is enforced in the search, the tool services, the assistants and the pages. An administrator can manage only their own projects.

Access only narrows

A person's rights are worked out once for each request and can only be narrowed as the request moves inward, never widened.

Documents are data

Text found in a document or in a tool result is treated as data, never as an instruction, so a document cannot talk CASPER out of its rules.

Human control

Changes to a system need an administrator and an explicit confirmation. Shared knowledge from a personal collection needs the owner's consent first.

Records

Answers and actions are recorded, including which documents and tools an answer used, so that they can be reviewed. Changes to a project's knowledge are logged.

Testing

New models, tools and settings are measured against reference questions before they are adopted. The wording of each tool is scored, and a person decides whether to adopt any clearer wording.

Privacy

  • Models are not trained on user conversations.
  • When a commercial model is used, it receives only the text needed for that answer.
  • A project that needs extra care can be marked local-only. Every question about it is then answered entirely on hardware we run ourselves.
  • When CASPER's tools are used from a person's own AI client, CASPER sees only what the client sends in a tool call: the tool name, its arguments and who the person is. It cannot read the rest of the conversation or the person's other connected services.
  • Public and private are kept strictly apart. This website is public. Project material, tools and assistants are available only after signing in, and only to the people who belong to the project.
  • Assistants on public websites answer only from pages that anyone can read, and limit what each visitor can ask.
  • These public pages read no database, call no model, set no cookie and use no analytics, external fonts or external scripts.

Where it runs

CASPER runs on research computing provided through IRIS. The open models are hosted and managed by CamCEAD on that research computing. Technical documentation for registered members is available after signing in.

Try it

CASPER is available to authorised users, in beta.

Try it / Sign in Questions and answers