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

Prove every GCCAP release before clients or Watchdog rely on it.

Internal system phase creates the QA control layer for release-candidate verification: test plans, payload tests, tenant isolation checks, report accuracy evidence, Watchdog safety tests and defect management.

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

GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Build28
PurposeRelease-candidate verification
BoundaryNot production certification

Operational layer

What Build 28 controls

GCCAP now has a register-driven QA layer to stop untested releases from being treated as client-ready or public-ready.

Master test plan

Defines release-candidate scope across platform, data, evidence, portal and Watchdog safety.

Teltonika sample tests

Turns CtrlOps/Teltonika payloads into repeatable adapter and decoder evidence.

Tenant isolation tests

Verifies clients only see their own carts, journeys, incidents, reports and exports.

Report accuracy tests

Checks that report statements trace back to raw packets, journeys, rules and approved evidence.

Decision clarity

Release-candidate gates

Build 28 keeps production blocked until critical test evidence exists.

Unit and integration testsRequired before release-candidate approval.
Security and tenant testingRequired before external client access.
Watchdog safety testsRequired before public benchmark publication.
Defect registerOpen production-blocking defects prevent release readiness.

Governance

Quality boundary

This layer is a QA control plane. It does not magically prove quality without executed tests.

  1. Treat all QA records as planning/control evidence until actual tests are run.
  2. Do not accept Teltonika/CtrlOps feed as evidence-grade until sample payload tests pass.
  3. Do not expose Watchdog rankings until publication safety tests pass.
  4. Do not call Build 30 production without release-candidate verification and post-30 hardening.