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

Turn telemetry into the full evidence story of a catering cart.

Internal system phase is the operational meaning layer. It groups processed sensor events by cart, reconstructs journey windows, assesses the 6-hour soak model, captures dry-ice process events, flags temperature exposure, and prepares the data for client portal replay and future evidence reports.

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

Journey modelSoak -> bay -> dry ice -> truck -> aircraft

Cold-chain rule6h soak at target temperature

Evidence outputReplay-ready timeline + breach review

Operational layer

What Build 4 now does

The journey engine is where GCCAP stops being a stream of readings and becomes an evidence system for airline catering operations.

Journey grouping

Groups processed telemetry into cart-specific operational journeys using cart ID, timestamp continuity, client context, airport context, and configurable gap rules.

Stage windows

Builds stage windows for cart soak, loading bay, dry ice event, truck dwell, aircraft handover, and return/recovery when evidence exists.

Soak assessment

Checks whether the available evidence can prove the target 6-hour soak model at the configured temperature threshold.

Breach staging

Flags temperature exposure above target, estimates exposure minutes, assigns severity, and creates review-ready breach records.

Replay foundation

Creates an ordered timeline with source packet references, manual events, stage confidence, location, temperature, and limitations.

Evidence confidence

Scores whether the journey has enough stage coverage, temperature data, location data, and source packet evidence to support stronger conclusions.

Decision clarity

Journey data model

These fields are now the core shape that later client portals, reports, AI agents, command centre views, and Watchdog governance will consume.

Cart identitycartId, clientId, airportCode, sensorId, gatewayId, vehicleId, flightNumber where available

TimingstartAt, endAt, durationMinutes, event timestamps, received timestamps, late/offline indicators

Stagescart_soak, loading_bay, dry_ice_event, truck_dwell, aircraft_handover, return_recovery, unclassified

Cold-chain evidencetemperatureC, humidity, threshold exposure, maximum temperature, soak compliance, breach severity

Location evidencelatitude, longitude, airport/facility context, future geofence support

Source evidencepacket IDs, raw hashes, manual event IDs, confidence score, known limitations

Cart evidence graph

Operational cart journey now has a computable structure

The same journey model used on the public website is now represented in backend logic so future dashboards and reports do not become disconnected from the actual data engine.

Cart soak

6-hour target soak, temperature curve, threshold compliance, source sensor confidence.

Loading bay

Staging timestamp, dwell duration, warming trend, location confidence.

Dry ice event

Manual or integrated event, placement time, process evidence, subsequent thermal response.

Truck dwell

GPS movement, dwell time, temperature exposure, gateway signal, vehicle context where available.

Aircraft handover

Handover window, custody event, final condition, exception and report readiness.

Governance

Build 4 operating boundaries

This engine is intentionally strict about what can and cannot be concluded before the real Teltonika/CtrlOps payload and field rules are confirmed.

Do not treat inferred stages as proven custody events unless explicit stage, geofence, manual event, or operational system data supports them.
Do not treat soak compliance as proven unless the timing window and temperature coverage are strong enough.
Use manual dry-ice process events until a validated integration or sensor/operational event confirms dry-ice placement automatically.
Treat all breach outputs as review records until formal report governance is built.
Keep Watchdog disconnected from raw journey outputs until aggregation, anonymisation, confidence thresholds, and publication governance are complete.

Strongest next move

Build 4 makes the paid pilot more concrete

The next sales promise can now be specific: GCCAP can capture a controlled cart lane, process telemetry, reconstruct the cart journey, assess soak evidence, show temperature exposure, and prepare replay-ready proof for an executive pilot report.

Request a controlled pilot