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

Prove the hardware path before any live client claim.

The hardware test harness now focuses on MQTT configuration, EYE record storage, gateway reconnect recovery, dense BLE behaviour, duplicate handling and timestamp preservation.

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
BuildPost-30 P29
Hardware5 EYE + 2 FMC150
GateWasher + BLE + payload
ModeTest harness

Real hardware test harness

Device registration, washer proof, BLE proof and first payload evidence.

This is the internal hardware proof surface for incoming Teltonika EYE EN12830 sensors and FMC150 gateways. It records what happened before any client surface switches from representative mode to live pilot mode.

Hardware proof boundaryTest harness / not production
Hardware order5 x EYE / 2 x FMC150
Gate 1Register devices
Gate 2Dishwasher survival
Gate 3BLE gateway proof
Gate 4Payload proof
OutputEvidence pack

Admin access

Use GCCAP_ADMIN_TOKEN. Local development can use GCCAP_UNSAFE_LOCAL_ADMIN=true.

Waiting for P29 APIs.

Harness actions


    

    

      
Readiness gates

      

    

    

      
Harness status
Validation evidence

      
Status loads after token is saved.

    

    

      
Devices and carts
Trial register

      

    

    

      
Dishwasher cycle evidence

      

    

    

      
BLE gateway checks

      

    

    

      
Payload proof

      

    

    

      
Evidence packs

      

    

  






  

    
Decision clarity

    
What P29 changes

    
P29 moves GCCAP from payload readiness into the operational test harness used when the physical hardware arrives.

  

  

    
Device registrationRecords EYE sensor and FMC150 gateway serial/MAC/IMEI data as soon as the shipment arrives.
Cart assignmentLinks each test sensor to a cart, placement method, gateway and trial role.
Dishwasher evidenceCaptures washer cycle, mounting survival, BLE recovery, data integrity and pass/fail result.
BLE gateway proofRecords gateway visibility, signal strength, packet capture and backfill checks in metal cart environments.
First payload proofPushes a sample or real EYE/FMC150 event through the P28 ingestion layer and stores the normalised evidence.

  






  

    
Operational layer

    
Pass/fail gates before client deployment

    
The harness is deliberately strict so GCCAP does not claim live monitoring before evidence exists.

  

  

    
Received hardware
At least one EYE sensor and one FMC150 must be registered as received/tested.
Dishwasher survivability
At least one wash cycle must pass mounting, BLE and data integrity checks.
BLE gateway capture
At least one sensor-gateway check must pass in a realistic cart environment.
Payload proof
At least one event must normalise through the Teltonika ingestion receiver with sufficient mapping confidence.

  






  

    
Strongest next move

    
Next build: deployment split

    
P30 should finalise the Netlify/static website versus backend/API runtime split, live/demo mode switch, deployment guide and rollback pack.

    Request a controlled pilot