Raw receiver
POST raw JSON, raw text, or hex payloads to the intake API while preserving the original packet body.
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
The raw sensor intake foundation for GCCAP cart journey evidence.
Internal system phase prepares GCCAP to receive the real output from cart sensors, Teltonika FMC150 gateways, server webhooks, TCP/UDP feeds, or decoded JSON exports before the exact payload format is known. It preserves raw packets first, then maps fields into GCCAP standard telemetry events.
StatusInternal / restricted surface. Not part of the public client walkthrough.
GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Accepted inputsHTTP JSON, raw text/hex, optional TCP, optional UDP
Evidence positionRaw packet preserved before mapping
Next build dependencyJourney engine and operational dashboard
Operational layer
What Build 2 adds
GCCAP can now accept unknown incoming data safely, retain original source packets, inspect fields, and stage normalised telemetry events without pretending the final Teltonika payload is already known.
Packet vault
Every packet is written to an append-only local vault with timestamp, source, hash, size, remote address, and protocol hint.
Payload inspector
Internal tools show recent packets, discovered fields, Teltonika parse summaries, and normalised staging events.
Field mapper
Unknown server output can be mapped into GCCAP canonical fields once the real payload samples arrive.
Data path
Build 2 telemetry flow
The intake path is designed to protect evidence first. GCCAP stores raw input before normalisation, so future decoder improvements can reprocess earlier data without losing source truth.
01Sensor captures cart temperature behaviour
02Gateway collects sensor records
03Raw payload is received and preserved
04Payload is mapped to sensor, cart, gateway, site and client
05Temperature event is normalised into the GCCAP event model
06Event is assigned to the correct cart journey stage
07Rules engine flags warning or review conditions
08Recovery and duration are calculated
09Data completeness and hardware health are assessed
10Evidence report is prepared for private client review
11Approved outputs can support client action and future benchmark methodology
Decision clarity
Protocol readiness matrix
Build 2 does not assume the final server output. It prepares multiple intake modes and keeps the exact mapping configurable.
HTTP JSON webhookReady
HTTP raw / hexReady
Teltonika TCPOptional adapter
Teltonika UDPOptional capture adapter
CSV/API importPrepared conceptually
Client portal deliveryNot yet
Watchdog public filteringNot yet
Operational layer
Canonical event fields now staged
Build 2 creates the field structure that later builds will use for cart journey replay, breach evidence, reports, command centre views, AI analysis, and Watchdog governance.
Identity
Client, cart, gateway, IMEI, BLE sensor, assignment and packet hash.
Cold-chain readings
Temperature, sensor battery, gateway power, signal, timestamps and confidence.
Movement context
Latitude, longitude, altitude, speed, heading and source protocol.
Journey staging
Unknown now by default; Build 3 turns this into soak, bay, dry ice, truck dwell and aircraft handover.
Strongest next move
Next strongest move: Build 3 cart journey engine
Once the first real payload sample arrives, map it through Build 2 and move immediately into Build 3: normalised telemetry store, cart journey stages, soak compliance, temperature timeline and first operational dashboard.
Request a controlled pilot