Pilot status. Public preview gateway is in shadow mode: it can record events and produce packages for evaluation, but it does not control or block your live business workflow. Not enterprise-certified. No formal third-party audit yet. Free offline vault (no gateway) lives at /vault.
What it does

Ingest → policy → seal → verify

Accept normalized events (API, webhook, connectors). Optionally evaluate policy. Seal a case into an encrypted package. Return metadata and verification — not open plaintext to the internet.

When to use it

Path 2 · team capture

Use the gateway when jobs, photos, or change orders should be sealed as they happen. For a one-off secret with no integration, use the browser vault instead.

How to start
Four steps for a pilot
Same product whether you use the public pilot surface or deploy your own process.
Step 01

Open or deploy

Try the pilot at /platform/, or run apps/gateway from qev-platform on your host.

Step 02

Check health

Confirm the process is up and see mode (shadow vs control). Use GET /v1/health and GET /v1/preflight.

Step 03

Send an event

POST /v1/events with a bearer ingest token, or a signed webhook, or the JS SDK / a connector.

Step 04

Seal & verify

Complete a case with POST /v1/flows/{flow_id}/complete, then inspect package metadata and run verify.

Live pilot surface

https://secure.imagineqira.com/platform/

Hosted preview of the gateway UI and API (admin, wizard, portal, review when enabled on the process).

# Example — public pilot health (no secrets)
curl -sS https://secure.imagineqira.com/platform/v1/health | jq .

# Expect fields like: product, version, mode (e.g. shadow),
# mode_behavior.records_events, preflight checks
API overview
Core routes
Authoritative detail is in OpenAPI. This table is the operator map.
MethodPathPurpose
GET/healthz · /readyzLiveness / readiness
GET/v1/health · /v1/preflightProduct status, mode, dependency checks
POST/v1/eventsIngest one event (bearer token)
POST/v1/webhooks/{connector_id}Signed webhook ingress
POST/v1/flows/{flow_id}/completeSeal a case into a package
GET/v1/packages/{id}Package metadata (not plaintext)
POST/v1/packages/{id}/verifyIntegrity / decrypt check with passphrase
GET/v1/cases · /v1/receipts/{event_id}Case list, ingest receipts
POST/v1/policy/evaluatePolicy dry-run without sealing

Protected routes expect Authorization: Bearer <ingest token> (see OpenAPI IngestToken). Configure tokens only on instances you control — do not paste production secrets into public examples.

Example · ingest shape

POST /v1/events

curl -sS -X POST "$QEV_GATEWAY_URL/v1/events" \
  -H "Authorization: Bearer $QEV_INGEST_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "event": {
      "schema": "qev.event.v1",
      "flow": "field-service",
      "case_id": "JOB-1",
      "type": "work.completed",
      "actor": { "id": "tech@example.com" }
    },
    "seal_if_complete": false
  }'

From app code, use the JS SDK (qev.capture(...)) pointed at your gateway base URL. Source: packages/sdk-js.

Run your own

Customer-controlled process

Gateway code lives in the monorepo under apps/gateway. Default local surfaces include admin, wizard, portal, and review UIs, plus the /v1/* API.

Trust boundary

What never leaves your data plane

Design intent: customer documents, prompts, and encryption keys stay with the gateway you operate. Optional control-plane features must not receive package plaintext. See Trust program.

Evidence bundles Audit status
Related docs

JS SDK

Capture from Node/TypeScript apps.

SDK overview →

Evidence Bundle V1

What a sealed export contains and how to verify it.

Bundle docs →

Field service evidence

Example vertical for estimates, photos, completion.

Field service →

Need help standing up a pilot?

We help wire capture without taking custody of your keys.