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
The hardware integration layer defines how sensor records, gateway identifiers, cart assignments and site context will be received, normalised and mapped into GCCAP once the approved devices are configured.
StatusInternal / restricted surface. Not part of the public client walkthrough.
Hardware ingestion readiness
This is the controlled readiness surface for testing how Teltonika EYE EN12830 temperature events and FMC150 gateway data will enter GCCAP. It does not claim production connection until real hardware, dishwasher testing, BLE performance and payload fields are validated.
Use GCCAP_ADMIN_TOKEN. Local development can use GCCAP_UNSAFE_LOCAL_ADMIN=true.
Waiting for P28 APIs.
Decision clarity
P28 moves GCCAP from a simulated hardware bridge into a structured ingestion readiness layer for actual Teltonika payload testing.
Operational layer
P28 gives the exact technical checklist for Sakshi/Teltonika so the meeting produces implementation facts, not vague product advice.
Confirm the exact EYE EN12830 temperature, timestamp, battery, RSSI and identifier fields exposed through FMC150.
Confirm how the tracker stores BLE records during signal gaps and how backfilled events are timestamped.
Confirm practical number of EYE sensors per FMC150 in dense metal-cart environments and recommended scan interval.
Strongest next move
P29 should turn this readiness layer into the operational test harness used when the devices arrive: washer test records, BLE test logs, mapping confirmation, first payload evidence and pass/fail signoff.
Request a controlled pilot