Start here

Getting started with Kaidera

A practical orientation for teams evaluating Kaidera: why it exists, how to get access, what the platform does, and what to review first.

Public draft for dev reviewLast verified 2026-05-22

Derived from the E94 website/docs source map, current public product narrative, and CTO Phase 2 docs direction.

Start with the story

Kaidera began as a practical problem: Amad needed to build an aviation solution that was too complex to move through ordinary tools and a small manual workflow. The answer was to build the operating system for the builders first - a governed AI worker team that could plan, remember, coordinate, test, and hand work back for review.

What Kaidera is

Kaidera is a managed AI worker team and workbench. It turns product intent into planned, executed, verified software work by combining AI worker teams, project memory, model routing, governance, and human approval gates.

Current access path

The long-term sign-up process will be self service. For the current enterprise phase, new customers should contact the Kaidera worker team, receive an enterprise account, and start with a guided onboarding path so the first project, users, access, billing, and model settings are configured correctly.

  • Contact sales or the Kaidera worker team to request access.
  • Confirm organisation details, account owner, and expected use case.
  • Receive the enterprise account and invite the first users.
  • Start with one project and one clear review path before expanding.

The operating loop

Work starts as a goal, becomes a scoped handoff, is claimed by the right AI worker, and is verified before it is treated as complete. PROMI coordinates the lifecycle and Cortex records the project memory behind each decision.

  • Define the goal and target outcome.
  • Let the platform break work into bounded handoffs.
  • Review evidence when the work reaches a gate.
  • Approve promotion only after dev review passes.

What to review first

Start with the product surfaces, project dashboard, Workbench, FileVault, AI worker team, Cortex memory, and model settings. Those surfaces explain how work is requested, assigned, stored, remembered, governed, and powered.

How the docs are organised

The docs are arranged around the user journey: story, access, product surfaces, projects, Workbench, FileVault, AI workers, Cortex, models, settings, trust controls, how-to guides, and FAQs. Each page explains what a user can do, how to configure the feature, what result to expect, and where human review remains required.

Website context

Connect this guide back to the product story

The technology docs map links this page to the public technology narrative and helps buyers move from a capability overview into the right operating guide.

Open technology docs map →