The Casefile Agent is the historical analyst of the BWTS IOT pipeline. When the IOT Manager dispatches a Phase 1 investigation, this agent searches past incidents, fleet-wide patterns, and resolution histories to find precedents. Its output tells the Manager whether this problem has been seen before, how it was resolved, and whether the fix actually worked.
Investigation Process
graph TB
START["Receive Investigation\nTask from IOT Manager"] --> S1
Search for past alerts and investigations on the same vessel and equipment tag. This is the highest-relevance search — identical hardware in identical operating conditions. Look for the same alarm code, the same parameter, and any related alarms that co-occurred.
Fleet-Wide Pattern Search
Expand the search to all vessels in the fleet with matching equipment types. Look for the same alarm code or symptom appearing on sister vessels. Fleet-wide patterns often indicate systemic issues — firmware bugs, batch defects, or environmental factors affecting multiple installations.
Resolution Effectiveness
For every matching past incident found in Steps 1 and 2, check whether the resolution actually worked. Did the same alarm recur within days or weeks? Was the fix a permanent resolution or a temporary workaround? This step prevents the pipeline from recommending fixes that have already been tried and failed.
Contextual Similarities
Search for incidents that share contextual factors even if the alarm code differs. Relevant context includes: operating mode at time of alert (Treatment, CIP, Standby), time since last CIP cycle, seasonal/geographic conditions (tropical waters, cold climate ports), and vessel operational profile (tanker vs. bulk carrier, short vs. long voyages).
Data Sources
Completed Alert Tasks
LifeOSAI Issue Search
Searches past completed investigation tasks using the ?q= parameter. Each completed task contains the original alert, the IOT Manager’s synthesis, confirmed causes, and the resolution applied. This is the richest source of structured investigation history.
PARA Memory Graph
Knowledge Graph
The PARA memory system stores distilled knowledge from past investigations as atomic YAML facts — equipment quirks, recurring patterns, known failure modes, and lessons learned. These facts persist across sessions and capture institutional knowledge that may not be fully recorded in task history.
IOT Events Database
bwts_iot_events Table
Raw event log in PostgreSQL containing timestamped records of all BWTS alerts, state changes, and operator actions. Used for statistical analysis — how many times has this alarm fired? What is the mean time between occurrences? Is the frequency increasing?
Output Format
Every Casefile Agent response follows the CASEFILE REPORT structure.
Search completed investigation tasks using the ?q= query parameter. Returns past alerts, confirmed causes, and applied resolutions.
PARA Memory Files
Query the knowledge graph for distilled facts — equipment quirks, recurring patterns, lessons learned. Persists across sessions.
db_query.py
Run SQL queries against the bwts_iot_events table in PostgreSQL. Used for statistical analysis — alert frequency, recurrence intervals, event clustering.
What It Does NOT Do
No Sensor Analysis
Never queries telemetry tables, never analyses trends, never interprets sensor values. Live and historical sensor data is the Data Analysis Agent’s domain.
No Maintenance Checks
Never accesses maintenance schedules, planned work orders, or service records. Maintenance data belongs to the PMS Agent.
No Manual Search
Never searches equipment manuals, troubleshooting guides, or manufacturer documentation. That is the Manual Agent’s responsibility.
No Report Generation
Never creates client-facing reports, never sends emails, never formats HTML output. Report creation and distribution is the Report Agent’s job.