Internal GCCAP operating surface

This page is retained behind the public client website.

GCCAP does not delete operating records, trial packs, hardware activation surfaces or evidence automation layers. They are preserved for authorised client portal, command-centre and internal operating use while the public website stays clean for airline first impressions.

Open portal access

Internal GCCAP surface

Control the production runtime split, service startup manifests, dependency map and cutover blockers.

The lab is the internal operating surface for separating GCCAP into production runtime services. It keeps web, ingestion, worker, socket/live update, simulation isolation and deployment boundaries governed before service cutover.

Return to public platform Open portal access

StatusInternal / restricted surface. Not part of the public client walkthrough.

GCCAP

Sensor

Gateway

Evidence

Watchdog

Journey intelligenceRepresentative demo

APIs/api/runtime-split/*

Servicesweb, ingestion, workers, live updates

StatusCutover blocked until evidence

Operational layer

Lab APIs

Use these endpoints to maintain the runtime split control plane.

Stats

/api/runtime-split/stats

Web process

/api/runtime-split/web-processes

Ingestion

/api/runtime-split/ingestion-services

Workers

/api/runtime-split/worker-services

Live updates

/api/runtime-split/socket-services

Readiness

/api/runtime-split/readiness

Governance

Founder note

P11 is an architecture correction build. It makes GCCAP more investable and more credible because the platform stops depending on one process for everything.

Do not process high-volume telemetry inside the web server.
Do not run simulation inside production runtime.
Do not deploy workers without retries, DLQ and health checks.
Do not launch production v1 until the runtime split has cutover evidence.