Alert object model
Every high-value rule incident can become a governed alert with severity, priority, owner, routing, SLA, source incident, cart, journey, evidence, and visibility policy.
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
Alerts, escalation, corrective action, and closure control for every cold-chain incident.
Internal system phase takes incidents produced by the rules engine and turns them into operational work: who needs to act, how fast, what evidence is attached, what corrective action was recorded, and whether the issue can be closed safely.
StatusInternal / restricted surface. Not part of the public client walkthrough.
GCCAP
Sensor
Gateway
Evidence
Watchdog
Journey intelligenceRepresentative demo
Alert sourceRules incidents
WorkflowAck > CAPA > close
Client viewTenant-filtered
Public useBlocked
Operational layer
What Build 8 changes
GCCAP no longer stops at detecting an incident. It now creates a controlled action record, assigns priority, tracks acknowledgement, records corrective and preventive action, monitors SLA risk, and keeps public Watchdog outputs blocked.
Acknowledgement workflow
Operators and authorised client users can acknowledge that an alert has been seen, creating an audit trail before the issue is handled.
Corrective action workflow
Build 8 records action type, summary, root cause, preventive action, evidence references, and status before serious issues can be closed.
Escalation and SLA control
The platform calculates acknowledgement and resolution due times, flags SLA breaches, and can escalate overdue critical or high alerts into a local notification outbox.
Decision clarity
Pilot versus production boundary
Build 8 is the right pilot-stage action layer, but production alerting requires real contact routing, SLA agreements, notification integrations, monitoring, and cloud deployment controls.
Ready nowInternal alerts lab, client-visible tenant alerts, acknowledgement, CAPA, closure validation, escalation state, and local notification outbox.
Not yet final productionSMS/email/Teams integrations, 24/7 NOC workflow, contractual SLA automation, production database, MFA, SSO, audit retention, and incident playbooks signed by each client.
Commercial valueA paid pilot can now prove that GCCAP detects, explains, routes, tracks, and resolves cart cold-chain risks rather than merely showing dashboards.
Watchdog safetyAlerts remain private operational records. Public Watchdog aggregation remains blocked until later governance builds approve what can be published.
Operational layer
Alert lifecycle
The controlled lifecycle is designed to stop data from becoming noise. The system must show which risks need action and what was done.
Open
Created from a cold-chain incident or data-quality issue after rule evaluation.
Acknowledged
Someone has seen the issue and accepted that it needs review or action.
Action in progress
A corrective action or investigation note has been recorded.
Escalated
The alert has breached timing or severity expectations and requires higher review.
Closed or false positive
Closure requires evidence notes and, for high-risk alerts, corrective action and root-cause notes.
Strongest next move
Next build after Build 8
Build 9 should create the internal GCCAP Command Centre: one all-client view for live alerts, cart health, sensor health, client status, Watchdog readiness, and operational command decisions.
Review Command Centre direction