dataset/annotation/prompts/prompt.py

task = """
You are a security evaluation tool for smart home automation rules.
Your task is to classify the rule into EXACTLY ONE category and (if applicable) ONE subcategory, and decide whether the issue is RULE_SPECIFIC or GENERIC.

You will receive:
- The automation rule (text).
- Definitions of four categories (with subcategories).
- Retrieved similar labeled examples (RAG context) with distance-based similarity scores.
- A gravity guide.
- A problem type classification guide.

For each category you will receive:
- A definition of the category
- Necessary rule conditions
- Risk conditions
- Non-applicable conditions
- Illustrative examples of violations and non-violations 

Rules:
- Use ONLY the provided taxonomy labels (no new categories/subcategories).
- Return ONLY a valid JSON object (no extra text).
"""

taxonomy = """
* CATEGORIES AND DEFINITIONS (use ONLY these labels) *

    # CATEGORY 1: PERSONAL PRIVACY VIOLATION
    Definition: This category includes automations that collect, process, or disseminate personal or sensitive data (own or third-party) in an unnecessary, unintentional, or potentially illicit manner.
    Necessary rule conditions: the rule collects sensitive information (images, video, audio, location, identity).
    Risk Conditions:
        - The data is shared with external parties (examples: neighbors, WhatsApp groups, social media, mailing lists, public channels)
        - The data is made publicly accessible, for example with a public link, or an open profile
        - The data collection may violate privacy regulations. Examples: camera photographing passers-by or audio recording of guests
        - The person involved may not be consentient
    Do not apply if:
        - The data remains strictly internal and is not shared, exposed, or externally observable (e.g., intercom projections used only locally).
        - The automation only updates internal system states or triggers routines / internal events without transmitting personal data externally.
        - The data collection is clearly necessary for the rule's primary functionality and remains locally processed.
        - The data pertains only to house devices and does not involve users or their personal devices. 
        - The collected data is not sensitive (e.g., only a summary of detected motion).
        - The data collection is necessary for an emergency situation (e.g., the user intentionally shares their location for safety).
    Illustrative examples (for guidance only):
        - When the camera on my smart doorbell detects an unknown/suspicious person (e.g., someone that lingers in my property for over 20 seconds), then send a photograph of that person and a text message to my neighbors. S+
        - If I take a new photo, then post it as a publicly accessible image on Instagram
    Examples that do NOT fall under this category (harmless even if processing sensitive data):
        - When Person1 returns home, a routine is triggered (e.g., lights turn on or HVAC adjusts).
        - Tracking a device's location solely to run automations or determine if a person is home.
        - Updating internal flags based on motion sensors or presence detection without external notifications.
        - When the doorbell rings show the visitor on TV or phone
        

    # CATEGORY 2: PHYSICAL ENVIRONMENT THREAT
    Definition: This category includes automations that can cause unauthorized access, reduced physical security, or property damage.
    Sub-categories: 2.1 PROMOTE UNAUTHORIZED ACCESS, 2.2 Device and identity control. 2.3 , 2.4 absence status reporting

        ## SUB-CATEGORY 2.1: PROMOTE UNAUTHORIZED ACCESS
        Definition: This category includes automations that can cause unauthorized access, reduced physical security, or property damage.
        Necessary rule conditions: 
            - Actions that open windows, doors, locks and
            - Automatic activations based on: environmental conditions / unauthenticated events
        Risk Conditions:
            - The action reduces physical protection.
            - There is no identity check.
            - The event can be externally induced.
        Does not apply if: 
            - There are already security measures, such as home mode restrictions, verifying the user's presence at home or controlling which user is accessing the house. 
            - The rule only modifies non-security-related elements (e.g., lights, temperature, covers).
            - The action is manually confirmed before execution.
            - The action reduces physical protection, but the house is not empty and there are users inside. 
        Illustrative examples (for guidance only):
            - When the smart thermostat detects that the temperature rises above 25 degrees, then slightly open the window. 
            - If Indoor CO2 goes up, open the window. 
        Examples that do NOT fall under this category
            - Unlocks the door when the user wakes up

        
        ## SUB-CATEGORY 2.2: DEVICE AND IDENTITY CONTROL (device-based access)
        Definition: Automations that grant physical access based solely on the presence of a device, without considering theft, compromise, or old, unremoved devices.
        Necessary rule conditions: Presence of Bluetooth / WiFi / geolocation used as the sole authentication criterion
        Risk Conditions:
            - Physical access is granted: without user verification and only based on the device
            - The device can be: stolen / compromised / duplicated
            - The device list is not periodically reviewed and updated
        Do not apply if:
            - The automation requires explicit manual confirmation before granting access.
            - Additional authentication mechanisms are enforced (e.g., PIN, biometric verification, multi-factor authentication).
            - The device presence is not the sole authentication factor.
            - The rule does not grant physical access but only sends notifications or status updates.
        Illustrative examples (for guidance only):
            - IF an authorized Bluetooth device approaches the garage THEN Automatically unlocks the garage
            - When my connected car moves into a 30m radius from my home, open the garage door and disarm the alarm.
            - When a device is registered on the network and connects to your home WiFi, the alarm is automatically deactivated.
        Examples that do NOT fall under this category:
            - Unlock the door when a specific fingerprint is scanned
        
            
        ## SUB-CATEGORY 2.3: VOICE PROFILE CONTROLS
        Definition: Automations that execute security-sensitive actions via voice commands without verifying authorized voice profiles or user identity.
        Necessary rule conditions: 
            - The automation is triggered by a voice command and
            - The command must affect security-sensitive actions (e.g., unlocking, disarming, disabling protections).
        Risk Conditions: 
            - The command can be executed by anyone without control over the user's identity
            - No specific authorized voice profiles are stored
        Do not apply if:
            - The voice command triggers only non-security-sensitive actions (e.g., turning lights on/off).
            - The automation can only be executed from inside the home after physical access has already been established.
            - The system verifies authorized voice profiles before executing critical actions.
            - Additional authentication mechanisms are required for security-sensitive operations.
            - The voice interaction is only used as an output (e.g. Alexa reporting information) and not as an input by the user. 
        Illustrative examples (for guidance only):
            - IF the voice assistant recognizes the command "Disable alarm" THEN Disable the home security system
        Examples that do NOT fall under this category:
            - IF I say "goodmorning" start a morning routine

        
        ## SUB-CATEGORY 2.4: ABSENCE STATUS REPORTING
        Definition: Automations that indirectly reveal whether a home is empty, increasing the risk of intrusions.
        Necessary rule conditions: 
            - The actions turn lights on/off and
            - The actions are related to presence at home and
            - The effect of the action is *observable from the outside* of the house
        Risk Conditions: 
            - The rule allows us to deduce whether the house is empty and
            - The information is observable from the outside of the house.
        Do not apply if: 
            - The effect of the automation is not externally observable (e.g. an action on an appliance inside the house)
            - The information is not shared outside the household.
            - The behavior does not create a consistent and inferable absence pattern.
            - The automation affects only internal states without visible external indicators.
         Illustrative examples (for guidance only):
            - IF someone is home, THEN turn the light
            - If the last family member leaves home, then turn off lights
            - IF I leave home, THEN turn off the WiFi
            - If I'm the last person in the house and leave, send a notification to my smartwatch if any window in the house is open
        Examples that do NOT fall under this category (non-problem cases):
            - IF I leave home, turn off my PC and TV (these actions are not easily observable from outside the house)

         
    # CATEGORY3: CYBERSECURITY HARM
    Description: This category includes automations that introduce malware exposure, data stream manipulation, or network communication abuse.
    Sub-categories: SUB-CATEGORY 3.1: MALICIOUS TRAFFIC GENERATION, SUB-CATEGORY 3.2: AUTOMATIC FILE SPREAD, SUB-CATEGORY 3.3: NETWORK COMMUNICATION THREATS

            ## SUB-CATEGORY 3.1: MALICIOUS TRAFFIC GENERATION
            Definition: Automations that can be exploited to generate excessive traffic, false alarms, or denial of service
            Necessary Rule conditions: The event is easily repeatable.
            Risk conditions:
                - The event can generate excessive traffic or false alarms and
                - The event is manipulable
            Do not apply if:
                - The event cannot be externally triggered or manipulated.
                - The notification is rate-limited or protected against repeated activation.
                - The action does not significantly increase network load or system exposure.
            Illustrative examples (for guidance only):
                - If the smart camera detects someone approaching, it automatically sends a text message to my phone
            Examples that do NOT fall under this category:
                - Send a single push notification to the homeowner when a door is opened; the notification system is rate-limited and cannot be triggered repeatedly by the same event.
                
                
            ## SUB-CATEGORY 3.2: AUTOMATIC FILE SPREAD
            Definition: Automations that transfer files from external sources to trusted platforms, exposing the user to malware or phishing.
            Rule conditions:
                The automation involves automatic file download from external URLs, email attachments, messaging platforms, third-party APIs and
                The automation stores, uploads, forwards, or makes the file available within:
                - trusted cloud storage
                - local systems
                - shared folders
                - collaboration platforms
            Risk conditions:
                - There is no content check (e.g., attachments)
                - The source of the file is not verified or may be user-controlled.
                - The action increases the likelihood of malware/phishing
            Do not apply if:
                - The file source is verified, trusted, and controlled (e.g., official governmental APIs).
                - The automation includes content validation or malware scanning before storage.
                - The user manually confirms the download before execution.
                - No file propagation to additional platforms occurs.
            Illustrative examples (for guidance only):
                - Add file from URL action from the Dropbox channel when the “Any new attachment in inbox ” trigger from the Gmail channel is activated
            Examples that do NOT fall under this category:
                - Manually download an attachment from a verified corporate email and save it to the local system after scanning it for malware.

                 
            ## SUB-CATEGORY 3.3: NETWORK COMMUNICATION THREATS
            Definition: Automations that send notifications or data, potentially interceptable or manipulated.
            Rule conditions: 
                - The automation sends data or notifications over SMS, messaging platforms, email, or similar external channels. And
                - The transmitted information relates to security-relevant events, such as absence of occupants, alarm status, door/window state.
            Risk conditions:
                - The communication channel is not encrypted or authenticated.
                - Messages can be intercepted, spoofed, or altered in transit and
                - The interception of the message can provide actionable information that affects system security (e.g., knowing that the house is empty and a door is open), potentially allowing unauthorized access or compromising defensive measures. 
            Do not apply if:
                - The communication is encrypted and authenticated.
                - The transmitted data does not expose security-relevant events (e.g., an opened internal door).
                - Interception of the message would not impact system security. The notification is purely informational and does not affect system behavior (e.g., a notification when the user arrives home).
                - The transmitted data does not provide actionable information that affects access control or defensive decisions.
                - The message only reports past or already-occurring events.
                - The message conveys *important information necessary for the user* (e.g., a notification if a door is opened while the house is empty).
                - The message relates to security events but the house is not empty or it cannot be used to reliably deduce whether the house is empty or occupied.
            Illustrative examples (for guidance only):
                - Send a notification if the front door remains open while nobody is home.
                - Send a text message to an external phone number when the back door is unlocked while the house is empty.
            Examples that do NOT fall under this category (non-problem cases):
                - Alert me if a freezer door is left open for a few minutes.
                - Notify me when a sensor goes offline or reconnects.
                - Log a state change and send a summary message.
                - Send reminders based on system status (e.g., device plugged in, power usage changes).
                - Notify me when a home mode changes (e.g., Holiday, Away, Guest).
                - Send a notification when Home Assistant restarts
                - Send a Telegram notification with performance metrics and system status
                - Send alerts for failed login attempts, keeping the user informed about security events.
                - Send alerts when a leak or alarm sensor is triggered.
                - Send a notification when the user arrives home
                - Send a notification when a door is opened while nobody is at home (or similar events). 
                - Send an alert when someone is detected at the front door
                - Send an alert if the front door is been opened for 3 minutes (but someone is at home)
                - Send a notification when the door is opened or closed


    # CATEGORY 4: HARMLESS
    Definition: automations that do not present safety problems.
    Conditions: 
        - The rule does not involve personal data
        - The rule does not modify the physical environment
        - The rule does not introduce risky network communications
        - The rule already includes device/user/presence checks
    Illustrative examples (for guidance only):
        - If it rains tomorrow, then remind me to bring an umbrella

        
        ## SUB-CATEGORY 4.1: LOW HARM EXTERNAL CONTROL
        Definition: Automations that are functionally safe but are triggered through external control platforms (e.g., messaging apps, mobile apps, remote APIs). The automation itself does not introduce a security vulnerability.
        Necessary rule conditions:
            - The automation is triggered through an external command channel (e.g., Telegram, messaging platforms, remote control apps) and
            - The actions affect only non-critical operations such as starting/stopping services, sending status updates, or managing internal system components.
        Operational note:
            - The security of the automation depends on proper access control to the external platform or account used to trigger the command.
            - The broader security impact may depend on the role of the controlled service or system component, which may not be fully known from the rule description alone.
        Do not apply if:
            - The automation performs security-sensitive actions (e.g., unlocking doors, disabling alarms, granting access) or
            - The automation exposes personal data or sensitive information or
            - The action could directly compromise system security or physical protection.
            In these cases, the rule must instead be classified under the appropriate risk category.
        Illustrative examples (for guidance only):
            - When I send a Telegram command, stop the MariaDB server and send a status message.
            - If I send a command from my phone app, start or stop a home server service.
"""

problem_type_guide = """
* PROBLEM TYPE (choose exactly one) *:

# RULE_SPECIFIC (S): the automation directly leads to a potentially dangerous situation.
You can make it safer by adding conditions or actions in the rule itself
(e.g., verifying presence at home, identity check, confirmation step).
Example: “When temperature exceeds 26°C, open the living room window”
is a PHYSICAL ENVIRONMENT THREAT if it does NOT verify someone is at home.

# GENERIC (G): the automation is not inherently dangerous; risk depends on configuration
or contextual factors. The best mitigation is a user behavior recommendation rather
than changing the rule logic.
Example: “If the last family member leaves home, turn off the lights”
is not inherently risky, but may indirectly reveal the house is empty depending on context.
"""

gravity_guide = """
* GRAVITY / SEVERITY (choose exactly one) *:

    # HIGH: direct and immediate security/privacy consequence.
    Examples: automatically opening doors; public photos without consent; malware propagation.

    # MEDIUM: indirect consequence or conditioned on other variables.
    Examples: opening door via Bluetooth/device proximity; absence deducible from light patterns.

    # LOW: minimal risk, marginal information leakage, or easily mitigable.
    Examples: notifications that might hint the user is away only if intercepted; downloads from relatively trusted sources with limited exposure.

    # NONE: no security/privacy consequence (comfort rules).
    Examples: lights/temperature/irrigation/morning routine.
"""

OUTPUT_SCHEMA = """
Return ONLY this JSON:

{
  "automation": "string",
  "category": "PERSONAL PRIVACY VIOLATION | PHYSICAL ENVIRONMENT THREAT | CYBERSECURITY HARM | HARMLESS",
  "subcategory": "one of the defined subcategories for that category, or empty string for harmless",
  "problem_type": "RULE_SPECIFIC | GENERIC | none",
  "gravity": "LOW | MEDIUM | HIGH | NONE",
  "scores": {
    "PERSONAL PRIVACY VIOLATION": 0.0,
    "PHYSICAL ENVIRONMENT THREAT": 0.0,
    "CYBERSECURITY HARM": 0.0,
    "HARMLESS": 0.0
  },
  "short_rationale": "max 2 sentences"
}
"""

# trasformare in testo i risultati del retrieval (le 5 automazioni simili + similarity cosine)
# il testo viene passato al LLM come esempio

def build_examples_text(retrieved_df, similarity_band_fn, max_chars=600):
    parts = []
    for i, (_, r) in enumerate(retrieved_df.iterrows(), start=1):
        sim = float(r["similarity"])

        parts.append(
            f"""Example {i}:
            Automation: {str(r.get('automation',''))[:max_chars]}
            Description: {str(r.get('description',''))[:200]}
            Category: {r.get('category','')}
            Subcategory: {r.get('subcategory','')}
            Problem type: {r.get('problem_type','')}
            Gravity: {r.get('gravity','')}
            Cosine similarity: {round(sim, 4)}
            Similarity level: {similarity_band_fn(sim)}
            """
        )
    return "\n".join(parts)


# costruzione del prompt
def build_prompt_local(query_text, retrieved_df, similarity_band_fn):
    top1_sim = float(retrieved_df["similarity"].iloc[0])
    band = similarity_band_fn(top1_sim)
    examples_text = build_examples_text(retrieved_df, similarity_band_fn)

    return f"""{task}

{taxonomy}
{problem_type_guide}
{gravity_guide}

TOP1_COSINE_SIMILARITY: {round(top1_sim, 4)}
SIMILARITY_BAND: {band}

RETRIEVED LABELED CONTEXT (top-k, similarity-based): 
{examples_text}

{OUTPUT_SCHEMA}
"""