GCCAPCold chain. Clear evidence. Confidence.

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

Make every incoming sensor event fit the GCCAP evidence model.

The live data activation layer defines the internal structure GCCAP needs before supplier-specific payloads arrive: client, site, cart, sensor, gateway, journey stage, timestamp, temperature and evidence status.

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
Build31
Event modelVendor-neutral
Journey stages14
Live modeBlocked

Live data activation readiness

Vendor-neutral data contract, cart journey lifecycle and demo/test/live controls.

GCCAP prepares for Teltonika arrival without waiting for final payload specs. The hardware adapter can change, but GCCAP's event contract, journey stages, registers, evidence boundaries and mode controls stay stable.

Activation boundaryPre-Teltonika / no live claims
ContractGCCAP event schema
Journey14-stage cart lifecycle
TenancyClient/site/cart IDs
ModeDemo / Test / Live
Live stateBlocked until validation
NextEvidence engine

Universal event contract

Every future Teltonika payload is normalised into GCCAP's own event shape before it can drive evidence, alerts, reports or client portal views.

event_id
client_id
site_id
cart_id
sensor_id
gateway_id
journey_id
stage
temperature_c
recorded_at
received_at
source
mode
hash

Cart journey lifecycle

  1. Cold room storage
  2. Cart loading
  3. Pre-dispatch staging
  4. Dock / dispatch hold
  5. Truck loading
  6. Vehicle transit
  7. Airside arrival
  8. Aircraft handover
  9. On-board holding
  10. Service window
  11. Post-service return
  12. Return transport
  13. Wash / reset cycle
  14. Ready for reuse

Registers created before data arrives

ClientTenant boundary
SiteFacility boundary
CartAsset boundary
SensorEYE mapping
GatewayFMC150 mapping
JourneyCold-chain timeline

Mode control

Demo modeSimulated data only. Client approval walkthrough.
Test modeManual/sample/real hardware validation data.
Live modeBlocked until payload, hardware, mapping, tenant and client gates pass.

Why this build matters commercially

GCCAP should not wait for a supplier payload before defining its own operating truth. P31 means Teltonika becomes an adapter into GCCAP's evidence engine, not the owner of GCCAP's data model. This protects profit, authority, defensibility and multi-client scalability.

Pre-hardware readiness only. No page claims live monitoring, food safety certification, regulatory compliance or client-specific performance.

Decision clarity

What Build 31 changes

Build 31 converts the waiting period before Teltonika hardware into high-value architecture work. It defines what GCCAP must know about every event before the supplier-specific payload arrives.

Universal event schemaDefines the internal GCCAP event format for every future sensor, gateway or manual import.
Cart journey lifecycleLocks 14 operating stages from cold room storage through aircraft handover, return, wash and reuse.
Multi-client register baseCreates the client, site, cart, sensor, gateway and journey registers needed for global multi-tenant separation.
Mode boundaryMakes demo, test and live states explicit so GCCAP does not overclaim simulated or validation data.
Adapter strategyKeeps Teltonika as an ingestion adapter while GCCAP owns the evidence model, reports, dashboards and Watchdog controls.

Operational layer

Live mode unlock gates

These gates must pass before live client monitoring can replace simulation or test data in client-visible surfaces.

Payload confirmation

FMC150/EYE payload shape, identifiers, timestamps, temperature field, battery, signal and backfill behaviour confirmed.

Hardware proof

EYE sensors and FMC150 gateways received, registered, mapped, mounted, washed and BLE-tested.

Backend proof

API endpoint, database, tenant boundary, event normalisation and audit hash path proven.

Client approval

Client approves the controlled pilot scope, data handling, no-public-claim boundary and report pathway.

Strongest next move

Next build: Evidence Engine Foundation

Build 32 should turn this data contract into the evidence rules engine: warning/excursion logic, recovery time, time above threshold, data completeness, evidence limitations and client-safe reporting language.

Request a controlled pilot