Soak compliance rules
Checks whether the cart soak stage has enough time, enough readings, and acceptable maximum temperature against the configured six-hour model.
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
Convert every cart journey into a governed cold-chain decision.
Internal system phase is the decision layer. It evaluates reconstructed cart journeys against configurable cold-chain rules for six-hour soak evidence, temperature exposure, dwell limits, dry ice process confirmation, missing data, device health, evidence confidence, incident severity, and public-readiness blockers.
StatusInternal / restricted surface. Not part of the public client walkthrough.
GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Rules scopeSoak + exposure + dwell + dry ice + data quality
Decision outputCompliance score + incident severity
Public safetyWatchdog blockers before public use
Operational layer
What Build 5 now does
The rules engine is where GCCAP stops listing exceptions and starts producing a controlled operational decision model. These outputs become the source for reports, alerts, AI review, command centre queues, and Watchdog governance later.
Temperature exposure rules
Scores every journey stage for target breaches, high exposure, critical exposure, and estimated minutes above target.
Dwell rules
Flags loading bay, truck dwell, and aircraft handover durations that exceed configurable operational limits.
Dry ice process rules
Requires dry ice confirmation and checks whether dry ice appears before truck dwell within the configured process window.
Data quality rules
Detects missing cart assignment, missing sensor/gateway identity, low confidence, late data, offline backfill, telemetry gaps, battery, signal, and raw packet evidence gaps.
Watchdog readiness rules
Separates private operational evidence from public-ready aggregate inputs so raw or weak data is not pushed into Watchdog prematurely.
Decision clarity
Build 5 decision model
Each journey evaluation now produces a structured compliance decision rather than a loose dashboard warning.
InputBuild 4 reconstructed journey with events, annotations, stages, temperatures, timestamps, raw packet references, and evidence summary.
RulesetAviation catering default ruleset with client override support for future airline/caterer-specific thresholds.
OutputEvaluation status, compliance score, evidence confidence, incidents, severity, recommendations, and public-readiness blockers.
Incident severityCritical, high, medium, low, and info, with category, evidence, recommendation, status, client, cart, airport, and journey reference.
Commercial useSupports paid pilot reports by making the system explain why a journey is compliant, questionable, or action-required.
BoundaryThis is not yet the final client report, alert workflow, AI agent, command centre, or public Watchdog score.
Governance
Rules engine operating boundaries
Build 5 is designed to protect GCCAP from weak or misleading claims while still creating decisive operational intelligence.
- Do not treat a rule evaluation as final client evidence until the real Teltonika/CtrlOps fields, timestamps, buffering behaviour, and site SOPs are confirmed.
- Do not use public Watchdog outputs from a journey unless public-readiness blockers are clear and later governance approvals are complete.
- Client-specific rules should only be configured after a signed pilot scope or agreed operating threshold is documented.
- Use the incident model to prioritise action, not to publish allegations.
- Preserve raw packet hashes and source evidence before relying on reports or commercial claims.
Strongest next move
The platform can now decide what a journey means.
Build 6 should turn these rule evaluations and incidents into client-grade reports and evidence packs, because a paid pilot needs defensible outputs a customer can read, circulate, and act on.
Request a controlled pilot