Durable queue
Every mappable normalised event is queued as an append-only pipeline item before downstream processing.
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 data pipeline that turns first payloads into usable cold-chain event streams.
Internal system phase sits between raw sensor/server intake and the future cart journey engine. It queues mappable events, deduplicates repeated records, produces processed operational telemetry, stores time-series points, flags late or offline-backfilled data, and supports replay after field mappings improve.
StatusInternal / restricted surface. Not part of the public client walkthrough.
GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Pipeline stageQueue -> dedupe -> processed stream
Evidence handlingRaw hash carried into processed events
Scale directionAppend-only files now, database/queue next
Operational layer
What Build 3 adds
Build 3 makes GCCAP more than an intake lab. It creates the first durable telemetry pipeline that later client portals, command centre views, evidence reports, and AI agents can consume.
Dedupe index
Repeated packets and replayed events are idempotently skipped so the same source evidence is not double-counted.
Processed stream
Events are transformed into a consistent operational telemetry format with temperature, location, identifiers, quality, and evidence metadata.
Time-series store
Cold-chain readings become queryable points by cart, sensor, gateway, client, airport, stage, and time window.
Late data handling
Events are marked late or offline-backfill-likely when event time and receipt time diverge materially.
Replay engine
Existing normalised events can be reprocessed after Teltonika/CtrlOps sample fields or mappings improve.
Data path
Build 3 data path
The pipeline preserves the intake evidence chain and creates the first operational stream. Build 4 will consume this stream to reconstruct cart journeys.
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
Readiness boundary
This build intentionally stops before journey conclusions. It prepares data so later builds can make those conclusions safely.
Ready nowHTTP/Teltonika-style intake, raw vault, field mapping, queue, dedupe, processed stream, time-series points, replay.
Pending CtrlOps/Teltonika sampleExact field dictionary, true sensor/server output format, backfill behaviour, BLE density assumptions.
Next buildCart Journey Model: soak, loading bay, dry ice event, truck dwell, aircraft handover, custody timeline.
Not claimed yetProduction tenant portal, full AI agent autonomy, global-scale database cluster, public Watchdog rankings.
Strongest next move
Keep building from evidence, not assumptions.
When Teltonika/CtrlOps send the real extract, update the field mapping, replay the normalised event store, then build the cart journey engine on top of verified data.
Request a controlled pilot