/ Xendai Method

A consistent method. Technology chosen for the problem.

We do not start with a preferred model, framework or vendor. We start with the operation, define what the system should be responsible for and establish how its performance will be verified.

Problem first. Architecture second. Technology when it earns its place.

Start a project →
  1. 01 Understand
  2. 02 Design
  3. 03 Build
  4. 04 Verify
  5. 05 Deploy
  6. 06 Operate ↺
Six disciplines. Verified before trusted. Operated with an owner.A method, not a product

02 / Start with the work

First define the work. Then decide what system it needs.

An AI project should not start by asking which model to use. It should start by understanding what happens today, where friction appears, which business outcome matters and what responsibility should move to a system.

03 / The method

From current process to operating system.

Method sheet — decisions and output per phase

Verify precedes acceptance · Operate feeds improvement

  1. 01

    Understand

    Understand the operation.

    process, people, systems, data, volume, cost, exceptions, constraints.

    Operating model
  2. 02

    Design

    Define the system's responsibility.

    inputs, context, decisions, actions, permissions, human checks, failure paths, success criteria.

    System design
  3. 03

    Build

    Engineer the right architecture.

    models, tools, data, APIs, workflows, interfaces, controls.

    Working system
  4. 04

    Verify

    Test before trusting.

    normal cases, edge cases, failure cases, permissions, handoff, cost, acceptance.

    Accepted behaviour
  5. 05

    Deploy

    Bring it into real operations.

    environment, access, secrets, dependencies, observability, handover, rollback.

    Production system
  6. 06

    Operate ↺

    Observe, maintain and improve.

    monitor, evaluate, maintain, correct, optimize, govern.

    Operating capability

Lime marks acceptance at Verify. Operate returns evidence to earlier decisions.

Method is the delivery discipline — not six paid services

04 / Technology selection

Architecture before allegiance.

Xendai is model-agnostic and framework-agnostic. Technology is chosen around the task, quality, latency, cost, integration, maintainability, security, data, deployment and client operating capability.

Selection recordProblem → Requirements → Architecture → Technology selection

01Problem
The operation and its constraint
02Requirements
task · quality · latency · cost · integration · maintainability · security · data · deployment · client operating capability
03Architecture
Pattern chosen for the requirements
04Technology selection
A variable, decided last. No vendor allegiance.

05 / Native fit

Native before custom.

Before building a new layer, we check what the existing software can already do. If a native capability solves the problem well enough, we use it.

Decision fork — both outcomes valid

Lime marks a verified fit on either branch

Business need
Native capability?
Yes / Use itExisting software does the work
No / Engineer gapOnly the unmet requirement is built

Partial fit: keep the native capability, engineer the rest

Build only the gap.

06Authority

Control before autonomy.

We do not chase maximum autonomy. We define permissions, boundaries, verification, exceptions and human intervention before the system is allowed to act.

Authorization gate — conditional, not universal approval

Propose → Risk / Authority → Execute / Human approval → Verify

  1. Propose
  2. Risk / Authoritymandate · permissions · boundaries
  3. Executepermitted and proportionate
  4. Human approvalhigher risk or out of mandate
  5. Verify

Coral only where intervention is required. Routine permitted actions execute. Everything is verified.

07 / Xendai Core

The technology changes. The operating system for building does not.

Xendai Core is the reusable set of Method, Architecture, Reusable IP and Standards applied across projects. It is not a mandatory platform, proprietary SaaS or hosting requirement.

Xendai Core — four strata of repeatable practice

Travels with the project. Not a product, not a tenant.

  1. 01

    Method

    How we identify, design, verify and operate AI Systems.

  2. 02

    Architecture

    Reusable patterns for context, tools, actions, controls and observability.

  3. 03

    Reusable IP

    Components, connectors, schemas, workflows, prompts, evaluations and procedures.

  4. 04

    Standards

    Conventions for quality, control, deployment, documentation and Runtime.

Technology — chosen per project, outside Core

Integrity register

A well-defined system

  • BoundaryResponsibility is defined.
  • ControlActions have permissions and limits.
  • MeasurementWe know what correct functioning means.
  • FailureExceptions and failures have a response.
  • TraceabilityWe can reconstruct what happened.
  • DeploymentThe running environment and control responsibilities are clear.
  • OwnershipSomeone is responsible after launch.

08 / Start a project

You do not need to know which technology you need.

Tell us what work should function better. Our first responsibility is to understand the problem before deciding what to build.

Start a project →