Configure CLAiRE's building blocks.

CLAiRE separates what the system should do (agents, skills, ontologies) from when it should do it (flows) and under what conditions (guardrails, evidence). Every concept below is configured declaratively — usually JSON stored against the tenant — so the same appliance can serve very different quality processes.

Agents

An agent is the reasoning unit. It has a goal, a model binding, a toolbox (a curated set of skills), and a guardrail policy. Agents are addressed by stable id and can be invoked from a flow node, from the chat surface, or directly from a GraphQL mutation.

Typical agent configuration:

• id / name / description — stable identifier and human label.
• model — provider, model name, and per-tenant model alias (e.g. mapping to a BYO-LLM endpoint on-prem).
• system prompt — persona, scope, and behavioural rules. Reference your ontology by name; the platform will reject prompts that name fields that don't exist.
• skills — the allowed toolbox for this agent. An agent cannot call a skill that isn't in its toolbox.
• guardrails — named guardrail policy (see below) that governs input filtering, tool constraints, and output post-filtering.
• memory — optional reference to a memory store (vector, episodic, or hybrid) for grounding.

Skills

A skill is a composable capability an agent can invoke. Skills wrap tool calls (database query, document generation, external system call), prompt fragments, or procedure references — always with a strict input/output contract so an agent can't accidentally feed bad arguments or trust an unstructured response.

Configure a skill with:

• id / name / description.
• input schema — JSON Schema describing the call arguments.
• output schema — what the skill returns; the platform validates the response before handing it back to the agent.
• handler — the implementation: a built-in tool, a GraphQL query/mutation, an MCP server endpoint, or a procedure call.
• permissions — what roles, classifications, and scopes are required to invoke this skill on the user's behalf.
• side-effect classification — read, write, or external. Influences guardrail behaviour (e.g. write skills must be inside an approved flow node).

Flows

A flow is a directed graph of nodes and transitions that orchestrates work across a record's lifecycle. Each node is either an agent invocation, a human approval, a system action, or a wait/condition. Transitions are guarded by predicates on the record or on the previous node's output.

A flow definition typically contains:

• recordType — the ontology entity the flow operates on.
• states — the named lifecycle states (e.g. draft, under-review, approved, closed).
• nodes — each with a type (agent, human, system, wait), a binding to the actor (agent id, role, or system action), and pre/post hooks.
• transitions — from-state, to-state, guard predicate, and an optional SLA.
• esign — per-transition flag requiring an e-signature step-up at SSO before the transition can commit.

Flows are first-class records: every transition writes an evidence entry into the audit chain (see below).

Ontologies

An ontology is the shared vocabulary that grounds every AI call. It describes the record types CLAiRE manages, the fields on each record, the controlled values fields can take, and the relationships between records. Without an ontology, prompts hallucinate field names; with one, CLAiRE rejects hallucinated references before they touch your data.

Each ontology entity has:

• recordType — the canonical name (e.g. capa, complaint, change-request).
• fields — name, type, classification tier (Public, Internal, Confidential, Secret, Regulated), and whether the field is PII.
• controlled values — enumerations and reference lists, optionally tied to a regulatory taxonomy (e.g. MedDRA, GMP categories).
• relationships — how this record links to others (CAPA ↔ complaint, deviation ↔ investigation).
• synonyms — user-facing aliases the AI may use when generating answers.

Guardrails

A guardrail policy wraps every AI call in four layers of enforcement:

• Input filter — rejects prompts containing prompt-injection markers, PII the user is not cleared to send, or out-of-scope requests.
• Tool constraints — the agent can only call skills explicitly in its toolbox. Side-effecting skills require an approving flow node.
• Data redaction — sensitive fields are replaced with safe tokens before any model sees them; tokens are reversed only inside the user's boundary.
• Output post-filter — final response is scanned for leaked classifications, fabricated record references, and policy violations before being returned.

A policy is configured with a name, the four layer rule sets, and a routing table mapping outcomes to one of allow, escalate, or block.

Evidence & Audit

Every action in CLAiRE — agent invocation, flow transition, record edit, login, e-signature — appends an entry to a tamper-evident, hash-chained audit log. Configure:

• retention — per record type, per classification tier.
• classification — default classification for the log entries themselves.
• signing — per-tenant key used to sign each block of the chain; optional notarisation to an external timestamp service.
• export — targets the chain is replicated to (S3 / Azure Blob with object-lock, downstream SIEM).

Tenants & Environments

Every CLAiRE deployment is multi-tenant. Each tenant gets its own database (in cloud) or maps to its own backing store (on-prem). Tenant configuration controls:

• identity provider — SAML / OIDC / Azure B2C connection details (see SSO endpoints).
• session timeout — per-tenant cookie max-age, honoured by the session middleware.
• model endpoints — cloud LLM or BYO-LLM URLs and keys.
• storage — document store, vector store, and audit-chain export targets.
• feature flags — which appliances (mAIGRATE, ATR, APQR, …) are enabled.