App boundaries
Public website, client portal, command centre and Watchdog split into production app targets.
Internal GCCAP operating surface
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
Production-readiness phase starts the real productionisation program after Internal system phase. It separates apps and services, defines database, object storage and queue migration, controls environments, and keeps production blockers visible before real client onboarding.
StatusInternal / restricted surface. Not part of the public client walkthrough.
Operational layer
P1 converts the Build 30 release candidate into a production architecture plan with clear app, service, storage and queue boundaries.
Public website, client portal, command centre and Watchdog split into production app targets.
Ingestion, telemetry, journey, rules, reporting, alerts, agents and Watchdog governance become service targets.
PostgreSQL-style table groups, evidence object storage and managed queues are specified.
Local, staging, controlled pilot and production are separated with explicit data boundaries.
Decision clarity
GCCAP must pass these before connecting live global client operations.
Governance
P1 protects GCCAP from overclaiming while creating the fastest path to a paid controlled pilot.