AI-Powered Inbound Load & Hazmat Screening – From BRD to Demonstration Build in 48 Hours

Protecting the Recycling Line: A 2-Day BRD-to-Build Blueprint for AI-Powered Inbound Conveyor Hazmat Screening — Lithium-Ion Batteries, Solar PV Panels, and Wind Turbine Blade Detection — Platform Layer Engineered to Production Standard; Demonstration Build

This production use case build demonstrates a full end-to-end, prompt-engineering-driven SDLC in action: an industrial-grade Inbound Load & Hazmat Screening Platform (Module 3 of the Renewi EHS Lighthouse CCTV Analytics suite), architected directly from a Business Requirements Document (BRD) and built on a single unified custom-trained YOLOv8 model, into a fully functional, stakeholder-ready, cloud-native application in just 48 hours. What typically requires months of human sprint cycles — requirements analysis, AI infrastructure design, backend services, hazmat data pipelines, and enterprise frontend dashboards — was executed methodically through structured AI collaboration, with the Principal Solution Architect directing and the AI acting as lead engineer across every layer.

Managing inbound recycling conveyor safety across waste management and recycling facilities is one of the most operationally complex and regulatory-critical challenges in the EHS sector. Ensuring that hazardous materials — specifically lithium-ion batteries, solar PV panels, and wind turbine blade fragments — are identified and stopped before entering shredding or processing lines cannot be reliably enforced through manual visual inspection alone. Observer fatigue on high-throughput conveyor lines, the absence of photographic evidence at the moment of detection, and the impossibility of simultaneous multi-belt monitoring leave facilities exposed to catastrophic equipment damage, personnel safety incidents, environmental liability, and regulatory enforcement action.

The platform delivers always-on AI-driven hazmat screening, real-time per-hazard severity-coded alert generation, per-zone incident attribution, and executive-grade analytics dashboards — backed by annotated photographic evidence and a complete audit trail. The following is the detailed account of how this platform was engineered from BRD to a stakeholder-ready demonstration build in 48 hours.

Target

Purpose and Value Proposition

The regulatory and operational mandate for hazardous material control on recycling conveyors is defined by frameworks including the Hazardous Waste (England and Wales) Regulations 2005, the Environment Act 2021 (duty of care provisions), COSHH (Control of Substances Hazardous to Health) Regulations 2002, and applicable WEEE (Waste Electrical and Electronic Equipment) Directive requirements for lithium battery and solar panel handling. Manual inspection processes are inherently fragile on high-throughput recycling lines — creating material exposure risk during peak operational volumes, compliance spot-checks, and incident investigations.

This platform was engineered to close those gaps. By leveraging a structured AI-driven build process to translate complex conveyor safety requirements into a fully governed, automated detection system, the team delivered a platform that identifies three categories of hazardous material in real time, generates evidentiary snapshots at the moment of detection, raises distinct severity-coded alerts per hazard type, and maintains the complete audit trail required by waste management regulatory frameworks.

How It Can Be Used

• EHS Directors / Waste Operations Managers: Monitor live hazmat detection rates, active alert volumes, severity breakdown (CRITICAL / HIGH), and incident trends across all screened conveyor zones via the executive KPI dashboard. Drill into specific battery, solar panel, or wind blade detection events for audit readiness.
• Conveyor Operators / Line Supervisors: Receive real-time push alerts the moment a hazardous item is detected — with distinct named alerts for each hazard class. Review annotated photographic evidence directly in the platform and acknowledge alerts with a traceable digital action.
• Platform Architects / Engineering Leads: Access a production-ready backend service architecture built on SOLID principles, a clean FastAPI layer with REST and WebSocket endpoints, a module=hazmat switch that reuses the established Module 2 (Fire & Smoke) integration patterns, Supabase PostgreSQL repositories, and Docker Compose deployment topology.
• Quality & Compliance Auditors: Execute full audit readiness by inspecting per-hazard incident evidence packages, tracing alerts back to originating detection events, verifying annotated snapshot URLs in Supabase Storage, and reviewing the complete event and alert audit log with UTC timestamps and camera attribution.
• Executive Stakeholders / Innovation Teams: Open the enterprise React dashboard and experience a fully working, stakeholder-presentation-ready AI hazmat screening platform — from live conveyor detection through evidence forensics and analytics — with minimal environment setup via Docker Compose.

Value Provided

• Requirement-to-Code Precision: Every high-level hazmat screening requirement — from three-class hazard detection to per-hazard severity coding, temporal smoothing, snapshot evidence generation, and the three-token JSONB persistence convention — was mapped directly to production FastAPI endpoints, Pydantic validation schemas, Supabase repository methods, and React dashboard components. The HazmatDetectionService, normalize_hazard_label function, and JSONB violating_classes token schema were all implemented in strict alignment with the original BRD specification.
• Fast Detection with Deliberate Smoothing for False-Positive Suppression: The YOLOv8 inference pipeline completes single-image hazmat detection in under 200ms on CPU (observed in testing) — detection is fast. For video and live feeds, confirmed incident alerts are intentionally governed by the temporal smoothing engine: a hazard must persist for 0.3 seconds before an event is raised, then a 5-second suppression cooldown per camera+hazard pair prevents duplicate alerts for ongoing detections. These are two distinct and separate controls — the 0.3s window gates confirmation; the 5s cooldown gates repeat firing. Inference latency and confirmed-alert delivery are appropriately separated: fast detection, deliberate confirmation.
• Three Distinct Severity-Coded Hazard Events: Rather than emitting a single generic “prohibited item” alert, the platform raises named per-hazard events — HAZMAT_BATTERY_DETECTED (CRITICAL), HAZMAT_SOLAR_PANEL_DETECTED (HIGH), HAZMAT_WIND_TURBINE_BLADE_DETECTED (HIGH) — enabling operators to prioritise and respond appropriately to each hazard category.
• Evidence-First Conveyor Safety: Every confirmed hazmat detection triggers an annotated snapshot generation pipeline: bounding boxes, class labels, and confidence scores are rendered directly onto the captured frame using OpenCV, uploaded to Supabase Storage, and linked to the event record with a permanent public URL. Incident response teams receive photographic evidence for every alert without manual screenshot workflows.
• Zero Model Training Overhead — Platform Engineering Focus: The platform treats the custom-trained UC-2 best.pt model — a single unified YOLOv8 model for all three hazard classes — as a production-ready external AI asset for platform integration purposes. No dataset collection, labeling, fine-tuning, or training infrastructure was required from the platform engineering team. The full engineering effort was invested in the service layer, persistence architecture, and dashboard around the model. Note: the model’s confidence threshold is set at 0.20 — intentionally low for a small custom training dataset — to surface true positives that a higher threshold would silently drop. Threshold tuning and accuracy validation against a larger labeled dataset are recommended before full production deployment.

YOLOv8 Framework Licensing Note: The UC-2 best.pt model weights are custom-trained and owned by the project — no third-party model attribution is required for the weights themselves. However, the underlying YOLOv8 architecture and inference framework are provided by Ultralytics under the GNU AGPL-3.0 License. While the surrounding enterprise platform layers (FastAPI backend infrastructure, Supabase data pipelines, and React dashboard) are engineered to production standard, any commercial production deployment of the platform must strictly adhere to AGPL-3.0 open-source copyleft provisions with respect to the YOLOv8 framework, or obtain an upstream commercial enterprise licence from Ultralytics.

• Schema-Free Taxonomy Extension: The UC-2 hazard taxonomy (hazard_class, severity, HAZMAT sentinel) is carried entirely within the existing events.violating_classes JSONB column using a three-token convention — [“HAZMAT”, hazard_class, “SEVERITY:<LEVEL>”] — requiring no schema migration. Metrics queries derive severity-bucketed counts by matching SEVERITY: tokens, keeping the shared platform database clean and migration-free.
• Complete Audit Trail by Default: Every detection, event, alert, and acknowledgement action is logged in Supabase with UTC timestamps, camera source attribution, hazard class, severity, and user identity. The event lifecycle — NEW → ACTIVE → ACKNOWLEDGED → RESOLVED — is fully traceable, providing the complete audit evidence required for waste management regulatory inspection and environmental compliance reporting.

Three-Class Hazmat Taxonomy

The UC-2 best.pt model detects three hazard categories. The canonical class mapping, severity, and operator-facing descriptions are:

 

Class Index	Canonical Backend Class	Display Name	Severity	Operator Description
0	battery	Lithium-Ion Battery	CRITICAL	Loose batteries, battery packs, EV modules. Severe thermal-runaway and fire risk if punctured during shredding.
1	solar_panel	Solar PV Panel	HIGH	Broken or intact PV panels. May contain heavy metals (lead, cadmium) which can leach into environment.
2	wind_turbine_blade (raw model label: wind_blde)	Wind Turbine Blade	HIGH	Fiberglass/carbon-fiber blade pieces. Releases toxic dust and fumes when processed without specialist handling.

 

Label normalisation note: The model’s third training class is wind_blade. The backend HazmatDetectionService.normalize_hazard_label function normalises this label — and all synonyms including blade, fin, turbine — into the canonical id wind_turbine_blade. Non-hazard labels are discarded silently, so the module is designed to report only the three intended hazard categories in normal operation.

Technique: The Kavia AI Streamlined Workflow

The technique used to build this platform represents a fundamental shift in how industrial hazmat screening software can be engineered. Traditional delivery of a platform of this complexity — encompassing computer vision AI services, real-time streaming architecture, per-hazard severity logic, a multi-table cloud database with a schema-free taxonomy extension, an enterprise React dashboard, and production Docker deployment — would typically require 4–6 weeks of sprint cycles across specialised engineers.

This delivery compressed that timeline to 48 hours by positioning a structured, prompt-engineering-driven AI collaboration workflow as the primary delivery mechanism. The Principal Solution Architect acted as strategic director, compliance authority, and integration decision-maker — directing the AI through a three-stage build pipeline that sequentially produced every platform layer from architecture documentation through to deployed frontend.

Crucially, the AI did not just “write code.” It acted as the lead architect and planner — ingesting the full UC-2 BRD, decomposing requirements into functional service boundaries, generating sequence diagrams for the RTSP inference pipeline, the alert lifecycle state machine, and the temporal smoothing and suppression logic, and producing enterprise-grade implementation decisions. This rigorous AI-driven planning phase minimised requirement drift and ensured the HazmatDetectionService singleton pattern, three-class label normalisation, and JSONB taxonomy convention were designed correctly before a single line of implementation code was produced.

The Platform Stack Defined at Architecture Stage: React + TypeScript + TailwindCSS + Framer Motion (Frontend) │ Python 3.11 + FastAPI + Ultralytics YOLOv8 + OpenCV (Backend) │ Supabase PostgreSQL + Supabase Storage (Data) Model Asset: UC-2 best.pt — Single unified custom-trained YOLOv8 model for Inbound Load & Hazmat Screening (Renewi EHS Lighthouse platform). Three detection classes: battery (Lithium-Ion), solar_panel (Solar PV), wind_turbine_blade (Wind Turbine Blade pieces). Confidence threshold: 0.20 (intentionally low for small custom dataset; tuning against a larger dataset recommended before full production deployment). Model weights are custom-trained and project-owned. The YOLOv8 inference framework is Ultralytics AGPL-3.0 — commercial production deployment must comply with AGPL copyleft provisions or obtain an Ultralytics commercial licence.

Project Timeline and the 2-Day Build

Below is the high-velocity pipeline followed to build the Inbound Load & Hazmat Screening Platform from BRD to a fully functional, stakeholder-ready demonstration build:

1. Requirement Ingestion and Solution Architecture Design

The build began with the AI ingesting the UC-2 Hazmat Screening BRD in full, performing an automated decomposition into user stories, functional requirements, and non-functional requirements. Within the first session, the AI drafted a complete Solution Architecture Document (SAD) covering Executive Summary, Business Context, Objectives, Scope, Assumptions, Constraints, all Functional and Non-Functional Requirements, End-to-End Architecture, Component Architecture, AI/ML Architecture, Data Flow Architecture, Security Architecture, Integration Architecture, and Deployment Architecture.

It generated detailed Mermaid-syntax architecture diagrams for the full system topology, the UC-2 inference pipeline, the per-hazard alert lifecycle state machine, and the Supabase JSONB taxonomy integration — establishing the complete engineering blueprint before any implementation began. The critical architectural decisions made at this stage included the single unified best.pt model design (consolidating the original dual-model plan onto one trained model), the module=hazmat query-parameter switch reusing established Fire & Smoke integration patterns, and the three-token JSONB violating_classes convention for schema-free taxonomy persistence.