Problem: Smart Electricity Grid Risk Analysis

A smart electricity grid wants to identify components whose operating condition may become unstable due to overload, sensor anomalies, direct faults, upstream fault propagation, or maintenance state.

The grid stores component details, power-flow connections, load demand records, sensor readings, fault events, and maintenance logs. The task is to analyze the records and print components whose operational risk level is CRITICAL or WARNING.

This is a graph-based problem involving downstream load aggregation and upstream fault propagation. A parent component supplies power to its child components.

Read input from STDIN, print output to STDOUT. Do not print any extra/arbitrary strings — this breaks test cases.

Data Structures

Grid Components Table

Field	Description
componentId	Unique identifier
componentName	Name of the component
componentType	SUBSTATION, FEEDER, or TRANSFORMER
capacityKw	Maximum safe downstream load capacity (kW)
criticalFlag	YES if critical, otherwise NO

Grid Connections Table

Field	Description
connectionId	Unique identifier
parentComponentId	Component that supplies power
childComponentId	Component that receives power from parent

Load Demand Records Table

Field	Description
loadId	Unique identifier
componentId	Component where load is directly recorded
demandDay	Day demand was recorded
demandKw	Demand in kilowatts
consumerType	RESIDENTIAL, COMMERCIAL, INDUSTRIAL, or HOSPITAL

Sensor Readings Table

Field	Description
readingId	Unique identifier
componentId	Component the reading belongs to
readingDay	Day recorded
voltage	Voltage value
temperature	Temperature value

Fault Events Table

Field	Description
faultId	Unique identifier
componentId	Component where fault occurred
faultDay	Day recorded
severity	LOW, MEDIUM, or HIGH

Maintenance Logs Table

Field	Description
maintenanceId	Unique identifier
componentId	Component maintained
maintenanceDay	Day recorded
maintenanceType	INSPECTION, REPAIR, or SHUTDOWN

Valid Record Rules

A grid connection is valid only when:

1. parentComponentId exists in Grid Components.
2. childComponentId exists in Grid Components and differs from parentComponentId.
3. Adding it would not create a cycle.

After invalid connections are removed, valid connections form a directed forest:

1. Each component has at most one parent.
2. A component can have zero or more children.
3. No cycles.
4. If the same (parent, child) pair repeats, only the first occurrence is used.

The data is guaranteed to satisfy these forest properties once invalid/duplicate connections are stripped out.

A load demand record is valid only when: componentId exists, demandKw is in the valid range (blurry — looked like "between 1 and 100000" or "≥ 0," verify exact bound), and consumerType is one of the four valid types.

A sensor reading is valid only when: componentId exists and voltage/temperature meet validity conditions (blurry — this line wasn't legible).

A fault event is valid only when: componentId exists and severity is LOW, MEDIUM, or HIGH.

A maintenance log is valid only when: componentId exists and maintenanceType is INSPECTION, REPAIR, or SHUTDOWN.

Invalid records are ignored. For maintenance logs, use the latest valid entry (greatest maintenanceDay) per component; if none exists, use NONE.

Features to Calculate (per component)

1. directLoadKw — sum of valid demandKw recorded directly on the component.
2. downstreamLoadKw — the component's directLoadKw plus the directLoadKw of every descendant in the forest, each counted exactly once.
3. directHighFaultCount — whether the component has at least one valid HIGH-severity fault directly on it.
4. (direct/upstream) MEDIUM fault condition — blurry, involves ancestor faults of MEDIUM/HIGH severity.
5. upstreamHighFaultPresence — whether any ancestor (parent, grandparent, etc.) has a HIGH-severity fault.
6. Latest voltage / latest temperature — from the most recent valid sensor reading; handle "no reading exists" as its own condition.
7. Latest maintenance type — from latest valid maintenance log, or NONE.

Operational Risk Score

A table of conditions, each adding points if true — legible ones:

• downstreamLoadKw > capacityKw → adds points
• downstreamLoadKw > capacityKw × (some multiplier, looked like 1.2) → adds more points
• direct HIGH fault exists → adds points
• direct/upstream MEDIUM fault condition → adds points
• upstream HIGH fault impact exists → adds points
• latest voltage outside a valid range → adds points
• latest temperature ≥ some threshold → adds points
• no valid sensor reading exists → adds points
• no valid maintenance log exists → adds points
• criticalFlag is YES → adds points

(Exact point values per condition weren't legible — please pull these from your screen.)

Operational Risk Level

Score	Level
14 or more	CRITICAL
8 to 13	WARNING
less than 8	NORMAL

Only components with CRITICAL or WARNING are output.

Constraints

• 1 ≤ numberOfComponents ≤ 100000
• 0 ≤ numberOfConnections ≤ numberOfComponents − 1
• 0 ≤ numberOfLoadDemandRecords, numberOfSensorReadings, numberOfFaultEvents, numberOfMaintenanceLogs ≤ 200000
• 1 ≤ referenceDay ≤ 100000
• 1 ≤ capacityKw ≤ 10000000
• 0 ≤ demandKw, sensor values, faultDay, maintenanceDay ≤ 1000000
• All ids/names/types are space-free strings.

Input Format

referenceDay
numberOfComponents
numberOfConnections
numberOfLoadDemandRecords
numberOfSensorReadings
numberOfFaultEvents
numberOfMaintenanceLogs
<componentCount lines>: componentId componentName componentType capacityKw criticalFlag
<connectionCount lines>: connectionId parentComponentId childComponentId
<loadCount lines>: loadId componentId demandDay demandKw consumerType
<sensorCount lines>: readingId componentId readingDay voltage temperature
<faultCount lines>: faultId componentId faultDay severity
<maintenanceCount lines>: maintenanceId componentId maintenanceDay maintenanceType

---