README.md

metadata

title: Granite Switch Tiny
emoji: 🛡️
colorFrom: yellow
colorTo: purple
sdk: gradio
sdk_version: 6.5.1
app_file: app.py
pinned: false
license: apache-2.0
models:
  - barha/granite-switch-4.0-350m-cti

Granite Switch 4.0 350M — CTI Technique Mapping

A Gradio demo for barha/granite-switch-4.0-350m-cti.

Enter a piece of cyber threat intelligence (CTI) text describing adversary behavior. The demo runs the same base model twice on the same prompt and shows the results side by side:

• Adapter OFF — the plain ibm-granite/granite-4.0-350m base. It answers in prose and rarely produces a clean technique ID.
• Adapter ON — the embedded cti-technique-mapping LoRA is fired by a single control token, and the model emits one MITRE ATT&CK technique ID (e.g. T1059.001), which the Space then resolves to its official technique name.

The model is a Granite Switch composition of the ibm-granite/granite-4.0-350m base with a cti-technique-mapping LoRA adapter (attention + MLP coverage). The adapter is activated by the <|cti-technique-mapping|> control token, which the chat template inserts when adapter_name="cti-technique-mapping" is passed to apply_chat_template — that single difference is the entire "switch". The model is loaded locally in the Space using the granite-switch package ([hf] backend).

The user input is wrapped in the exact instruction format the adapter was trained on — What ATT&CK technique does the following CTI procedure sentence describe? followed by the sentence inside <cti>...</cti> tags.

The ID→name lookup uses mitre_id_to_name.json, built from the official mitre-attack/attack-stix-data Enterprise bundle (697 techniques + sub-techniques), bundled in the Space so no network call is needed at inference.

Note: the adapter was trained on the top-10 most frequent techniques in its source dataset, so inputs outside those classes may map to a near-but-imperfect ID. The demo's point is the base-vs-adapter behavior difference, not exhaustive ATT&CK coverage.