01Reference

What you can call, and what it guarantees.

Written for whoever has to decide whether this is a system or a prompt with a logo. The endpoint list below is the real surface. The section under it describes how output is kept trustworthy, which is the part that actually matters.

Conventions

Auth. Bearer token from POST /auth/login. Scoped to one organisation; a token cannot reach another org's data.

Idempotency. Every write accepts an Idempotency-Key. A repeat replays the stored response; the same key with a different body is a 409; a failed request releases the key so a retry works.

Errors. A stable machine code, a human message, and a correlation id echoed in the x-correlation-id header.

02The validation model

Where a model is allowed to be wrong, and where it is not.

An agent that is confidently wrong about a compliance obligation moves money. These are the constraints that make that survivable.

01

Deterministic rules run first, and always persist

Requirement extraction is rule-based and runs on every turn over the entire transcript. Its output is stored before any model is consulted. A rule that misses a signal leaves a visible gap the customer can correct; a model that silently invents one moves money.

02

The model adds, it does not overrule

A model is then asked for a second opinion against a JSON schema, and merged additively above a confidence floor. It can add a signal the rules missed. It cannot remove one they found, and cannot change the classification when the rules had direct evidence. Every signal is stored with its provenance and the phrase that produced it.

03

Structured output is validated, not trusted

Model responses are parsed and validated against a schema. An invalid response is retried once with the validation error fed back, and a second failure is discarded rather than passed downstream. Repaired responses carry a lower confidence score than first-pass ones.

04

Money and gates are code, not prompts

Pricing is a pure function over stored requirements. The contract, payment and kickoff gates are explicit state machines with the illegal transitions enumerated. No model participates in deciding whether work may start.

05

Credentials never reach a model

Every outbound prompt is scanned for API keys, cloud access keys, tokens, private keys, connection strings and card numbers, and redacted before the call leaves the process.

06

Everything is reconstructible

Requirements, estimates and contracts are versioned. Each carries the input that produced it and a confidence score, so a decision made months ago can be explained rather than defended.

What we do not publish

Accuracy, precision and recall figures, because they are meaningless without the dataset they were measured on and we will not quote a number you cannot check. What we will do is agree the acceptance thresholds for your project in the statement of work, before work starts, and measure against them on your data. That is in the contract rather than on a slide.

03Endpoints

The whole surface.

Grouped by the stage they belong to. Notes call out the behaviour that will surprise you, not the behaviour the path already implies.

Auth

Sessions are stateless bearer tokens. SSO is stubbed pending an identity provider.

POST/auth/login

Exchange email and password for a session token.

public
GET/auth/sso/redirect

Begin an SSO flow.

Returns 501 until an identity provider is configured for your deployment.

public
POST/auth/sso/callback

Complete an SSO flow and provision the user on first sight.

public
POST/auth/logout

Record a logout.

Advisory. Tokens are stateless, so discard client-side; server-side revocation needs a blocklist.

bearer token
GET/me

The authenticated user and their organisation.

bearer token

Intake

Chat-first requirement capture. Every turn re-extracts over the whole transcript and persists the result.

POST/intakes

Open an intake session and its project.

bearer token
GET/intakes/:id

Session state, message history and the latest extracted requirements.

bearer token
POST/intakes/:id/messages

Send a message. Returns the reply and the classification.

Requirements are persisted before the reply is generated, so a dropped connection never loses the extracted scope.

bearer token
GET/intakes/:id/stream

The same turn over SSE.

Emits a classification event first, then token events, then done. The message is a query parameter because EventSource cannot send a body.

bearer token
POST/intakes/:id/classify

Re-read the stored classification without adding a message.

bearer token
POST/intakes/:id/finalize

Lock requirements so an estimate can be issued against a stable scope.

bearer token

Requirements

Prerequisite schemas are served by the API so the form is generated from one definition.

GET/schemas/cv_prereqs

JSON Schema for vision prerequisites.

bearer token
GET/schemas/rag_prereqs

JSON Schema for retrieval prerequisites.

bearer token
PUT/projects/:id/cv_prereqs

Save vision prerequisite answers.

Answers augment what intake extracted; they never replace it. Rejected once requirements are locked by a contract.

bearer token
PUT/projects/:id/rag_prereqs

Save retrieval prerequisite answers.

bearer token

Estimates

Pricing is computed server-side from stored requirements. There is no field for an amount.

POST/projects/:id/estimate

Price the project. Body carries configuration only: agents, add-ons, billing term.

Supplying a price in the body changes nothing. Asserted by test.

bearer tokenrequires member
GET/projects/:id/estimate

The current estimate with its complexity drivers.

bearer token

Contracts

The statement of work is generated server-side, versioned, and issued for signature.

POST/projects/:id/contract

Generate the SOW and open a signature envelope.

Approves and freezes the estimate. Refuses if a contract is already out for signature.

bearer tokenrequires admin
GET/projects/:id/contract

Contract status, envelope reference and the document itself.

bearer token

Payment

Status changes only ever arrive by signed webhook. A client cannot mark itself paid.

POST/projects/:id/checkout

Open a checkout for the approved amount.

Refuses while the contract is unsigned, and while another payment is in flight. The amount comes from the estimate, not the request.

bearer tokenrequires admin
GET/projects/:id/payments

Payment history for the project.

bearer token

Delivery

Work cannot begin until the contract is signed and payment has cleared.

POST/projects/:id/kickoff

Start delivery and queue the task list.

Returns 409 KICKOFF_BLOCKED with the blockers named until both gates pass.

bearer tokenrequires admin
GET/projects/:id/tasks

The delivery task list with its owning agent.

bearer token
POST/projects/:id/deploy

Start a deployment to a target.

Targets: onprem, aws, azure, gcp, edge.

bearer tokenrequires admin
GET/projects/:id/telemetry

Health, progress and the gate state.

bearer token
GET/projects

Projects in your organisation.

bearer token
GET/projects/:id

Everything about one project in a single read.

bearer token

Connectors and audit

Credentials are sealed per organisation. Every consequential action is recorded.

POST/projects/:id/connectors

Store a connector credential, encrypted.

Refuses rather than storing plaintext if no vault key is configured. The secret never appears in the audit log.

bearer tokenrequires admin
GET/audit

The audit trail for your organisation.

bearer tokenrequires admin

Webhooks

Unauthenticated but signature-verified. Verification is constant-time over the raw request bytes.

POST/webhooks/esign

Signature provider events.

Replay-safe: an event that would not change state returns success rather than an error.

signature verified
POST/webhooks/payment

Payment provider events.

The only way a payment reaches SUCCEEDED.

signature verified

Operational

GET/health

Status, database driver and which providers are configured.

Names every active stand-in, so a deployment never has to guess whether it is talking to a real payment provider.

public
04Running it yourself

Including where nothing can leave.

The platform is packaged for Docker and Kubernetes, with offline bundles for environments that have no outbound connectivity. Self-hosted models are available where no traffic may reach a third party at all.

platform specification
Model layerAgnostic, per task
System of recordPostgreSQL
Cache and locksRedis
ArtifactsObject storage, versioned
Chat transportSSE streaming
PackagingDocker / Kubernetes
Availability target99.9% control plane
Chat latencyP95 under 2s to first token
Scale10k concurrent sessions
Air-gappedOffline bundle supported