Provider health
Records health check proof across database, storage, queue, monitoring and deployment.
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 accessInternal GCCAP surface
Record provider health checks, proof results and external service binding evidence.
The P20 lab is the internal surface for proving that managed database, object storage, queue, monitoring, notification, billing and deployment bindings work before GCCAP moves toward real staging cutover.
StatusInternal / restricted surface. Not part of the public client walkthrough.
GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
APIs/api/provider-binding/*
PurposeExternal service proof
StatusBlocked until provider tests pass
Risk reducedFalse production readiness
Operational layer
Lab controls
Use these APIs to track provider binding proof without storing real credentials.
Connection proofs
Records database, object storage and queue data movement proof.
Alert and notification proofs
Records monitoring, breach email, gateway silence and notification delivery proof.
Evidence packs
Compiles proof records into a provider binding evidence pack for cutover review.
Governance
Proof boundary
P20 stores test evidence and redacted metadata only. Real provider credentials remain external.
- Use secret manager references instead of literal secrets.
- Record test IDs, timestamps, latency and result status only.
- Suppress real client charging during billing webhook tests.
- Do not approve staging cutover without evidence pack review.