CLAIV

Platform

How CLAIV Studio works

From a sentence about the business to a governed organisation doing the work. Every part below is a place in the product, shown here with a simulated example.

The loopDesignBuildOrganisationWork@ YOUKnowledgeConnectionsAuditUnderneath

The shape of it

One loop, and nothing skips it.

You describe an outcome. CLAIV proposes a design. You approve it. Specialists are built and qualified, then they do the work — and what actually happened is what proposes the next change.

DescribeWhat the business needsDesignTeams, limits, approvalsProveQualify before it runsOperateMissions and decisionsAccountEvidence and learningVERIFIED OUTCOMES CHANGE THE DESIGN
Nothing runs because a model decided it should. Each stage leaves a record that the next one is checked against.

Design

It starts with the objective, not a canvas.

CLAIV reads what the outcome requires, checks what your workspace already has, and proposes a complete organisation for you to approve.

  • Only the questions that change the designYou are asked where an answer actually matters, such as the value above which a refund needs you. Unrelated decisions stay separate questions.
  • Everything named before it existsGoals, teams, specialist roles, the knowledge each will rely on, the systems they need, and every action that will pause for approval.
  • Missing things are named as missingA disconnected system or an unsourced document is listed as work still to do — not as a flaw in the design, and never as something already handled.
  • You approve that exact designApproval is bound to the proposal you read. If it changes, it needs approving again.
Simulated example. The proposed organisation for an online shop: goals, teams, specialists, and the actions that will wait for a person.

You approve a specific design, not a direction. Change any part of it and CLAIV asks again, because an approval that survives a rewrite is not an approval.

Design · approval

Simulated example. Specialists being built and tested, knowledge being sourced, and a missing connection named as the blocker it is.

Build

Nothing is ready until it has been proven.

Approval starts a durable build. Close the tab or restart the app and it carries on; reopening shows the same operation rather than starting a second one.

  • Assembled, then examinedEach specialist is tested against realistic cases for the work it will do. One that does not pass is not presented as ready.
  • Knowledge gathered deliberatelySources are collected, checked and promoted with their provenance attached, rather than pasted into a prompt and forgotten.
  • Blockers are honestA missing connection stops the build and says so, with the action that fixes it. No silent fallback, no pretend success.
  • Ready is derived, not declaredReadiness comes from qualification, connections and governance together. “The build finished” is a different claim.

Organisation

Who owns what, and what they are allowed to do.

The map of your AI workforce: teams with real responsibilities, and the specialists who staff them.

Simulated example. A specialist opened from the organisation: her charter, what she may do alone, what she must ask about, and how she qualified.

Teams hold responsibility

Each team owns an area of the business, with its own goals, work, specialists and open decisions.

Specialists are inspectable

Charter, competencies, limits, pinned knowledge and tools, and the exact versions in use.

Qualification is visible

You can see what a specialist was tested on and when, rather than trusting a label.

It is navigation, not decoration

Selecting a team, specialist or mission opens the real thing, in the state the rest of the product shows.

Simulated example. A late delivery worked by four specialists, each step marked proposed, attempted, observed or verified.

Work

Missions are rooms you can open.

A mission is a durable unit of work with an owner, a plan and a shared record. Several specialists can work in one, each under its own identity, knowledge and authority.

  • The timeline separates claimsProposed, attempted, observed and verified are different states, and the room shows which one each step reached.
  • Evidence travels with the workSources, tool actions and decisions attach to the mission rather than getting buried in a conversation.
  • Conflicts become decisionsWhen specialists disagree it surfaces as an explicit decision or approval, instead of being quietly averaged away.
  • Closing a tab cancels nothingWork is durable. Reopening reattaches to the same thread, and a reply that lands while you are away waits where it belongs.

@ YOU

One queue, only for things that genuinely need you.

An item appears because something actually stopped: an approval, a missing connection, a blocked mission, an effect that needs reconciling. Ordinary completions never interrupt you.

  • Every item says why youWho is asking, what exactly will happen, the evidence for it, and the consequence of delay.
  • Approval is bound to the actionYou approve this refund, this amount, this customer. A changed request cannot reuse your answer.
  • It clears when it is resolvedItems disappear when the underlying thing is satisfied, not when someone dismisses them. There is no dismiss.
Simulated example. An approval request: what will happen, why it needs a person, the evidence, and what waiting costs.

Knowledge

What it knows, and how it knows it.

Knowledge is governed rather than absorbed. Every claim a specialist relies on traces back to a source and a version.

Simulated example. A promoted policy with its claims, each showing its source, how fresh it is, and which specialists depend on it.

Provenance on every claim

Where it came from, which version is current, how fresh it is, and exactly which specialists consume it.

Sources are untrusted until promoted

Gathered content is screened before it becomes something the organisation relies on.

Learning is proposed, never slipped in

What a mission teaches arrives as a candidate with its diagnosis and evidence. You decide whether it becomes real.

Changing a fact has consequences

When a pinned claim changes, the specialists that depend on it requalify before they count as ready.

Connections

Three states most tools blur into one.

Connecting an account, a capability being available, and a specialist being allowed to use it are separate facts. Keeping them separate is what stops quiet over-permission.

Connected

The account is linked, and its health is reported honestly — including when a provider will not confirm whose account it is.

Capability available

What the provider actually offers, classified by whether using it changes anything on the other side.

Authority granted

Which specialists may use which capability, for which work. Granting or restricting goes through the same approval discipline as any other change.

Credentials are handles, never values: the interface can tell you a credential exists without being able to reveal it.

Simulated example. The trail behind one refund: the proposal, the policy that stopped it, the approval, the effect, and its verification.

Audit

The whole answer to “why did that happen?”

Audit joins the decision, the authority behind it, the exact versions involved and the proof that it happened — for any outcome, in one trail.

  • Lineage, not log grepMission, decision, approval, tool attempt, observed effect and verification, linked in order with their identities.
  • Versions are pinnedWhich specialist version, which knowledge version, which policy and which model route were in force at the time.
  • Exports are safe by constructionEvidence exports carry a metadata allowlist: no prompts, no outputs, no source bodies, no credentials.
  • Explanations, not monologueConcise, user-safe reasoning with the evidence — never a model’s hidden chain of thought.

Underneath

The parts you never navigate.

These make the areas above dependable. You meet them in build progress, qualification evidence and Audit — not in the navigation.

Agent Runtime

Runs each specialist as a versioned package with durable lifecycle state, so work survives a restart or a lost worker.

Context and routing

Assembles the smallest sufficient context for each step and routes it to a model your policy allows, including local ones.

Tool Fabric

Checks every action against policy at the moment it would run, and records intent before any external effect.

Memory

Keeps what the organisation learns with provenance, versions, contradiction handling and a visible correction path.

Hive

Lets specialists coordinate through typed messages and shared state instead of one enormous shared prompt.

Flow

Executes long-running work durably: retries, timers, approvals, joins and recovery across restarts.

Private beta

Put it against your own work.

Bring one thing you keep doing yourself, and see what CLAIV proposes for it.

  • Full access to CLAIV Studio while it is in private beta.
  • You drive it. CLAIV designs the organisation, proves it and asks you to approve it — no consultants, no onboarding calls.
  • Beta means rough edges, and what beta users hit first is what gets fixed first.

Three short steps

Who you are, what you would use it for, and whether your machine can run it. It creates your account at the same time, so there is nothing to do when you are approved.

Request beta access

Already requested? Check your download page.