Publish v0.4.7 (retrained from v0.4.2 base with multi-state context)

Modelfile.answer

@@ -0,0 +1,41 @@
+# Ollama Modelfile for Selora-AI v0.4.7 / answer specialist (Qwen3 1.7B + LoRA)
+# Build:  ollama create selora-qwen-answer -f Modelfile.answer
+# Run:    ollama run selora-qwen-answer
+
+FROM ./qwen3_17b_base.f16.gguf
+ADAPTER ./selora-v047-answer.f16.gguf
+
+# Qwen3 ChatML template (/no_think suppresses the thinking block — matches the
+# integration's enable_thinking=False chat-template-kwarg and how v0.4.7 was
+# trained).
+TEMPLATE """{{ if .System }}<|im_start|>system
+{{ .System }}<|im_end|>
+{{ end }}{{ if .Prompt }}<|im_start|>user
+/no_think {{ .Prompt }}<|im_end|>
+{{ end }}<|im_start|>assistant
+"""
+
+# v0.4.7 per-specialist system prompt (verbatim from prompts/answer_system_prompt.txt).
+SYSTEM """You are Selora AI's answer specialist for Home Assistant.
+
+Given a user question and the AVAILABLE ENTITIES list, respond with ONE JSON object only:
+{"r":"<response with {entity_id} placeholders where state is needed>","q":["<entity_id>",...]}
+
+Rules:
+- r: response template. Use {entity_id} placeholders for any state references; the consumer substitutes live state. Keep r short — 1-2 sentences max.
+- q: array of entity_ids to look up. Omit when no live state is needed.
+- Either field can be omitted if not used, but never both.
+- Only reference entity_ids that appear in AVAILABLE ENTITIES below.
+- Never invent state values; always template them via {entity_id}.
+- If the question is outside the home's scope, return {"r":"I can only answer questions about your home."}.
+
+Output JSON only — no narration, no markdown fences, no chain-of-thought."""
+
+# Generation params match training-time + integration defaults. repeat_penalty
+# is 1.0 (not 1.15) because v0.4.7 was trained without it; 1.15 measurably
+# distorts the slim-schema outputs (drops short keys like "r").
+PARAMETER temperature 0.0
+PARAMETER repeat_penalty 1.0
+PARAMETER repeat_last_n 256
+PARAMETER stop "<|im_end|>"
+PARAMETER stop "<|endoftext|>"

Modelfile.automation

@@ -0,0 +1,79 @@
+# Ollama Modelfile for Selora-AI v0.4.7 / automation specialist (Qwen3 1.7B + LoRA)
+# Build:  ollama create selora-qwen-automation -f Modelfile.automation
+# Run:    ollama run selora-qwen-automation
+
+FROM ./qwen3_17b_base.f16.gguf
+ADAPTER ./selora-v047-automation.f16.gguf
+
+# Qwen3 ChatML template (/no_think suppresses the thinking block — matches the
+# integration's enable_thinking=False chat-template-kwarg and how v0.4.7 was
+# trained).
+TEMPLATE """{{ if .System }}<|im_start|>system
+{{ .System }}<|im_end|>
+{{ end }}{{ if .Prompt }}<|im_start|>user
+/no_think {{ .Prompt }}<|im_end|>
+{{ end }}<|im_start|>assistant
+"""
+
+# v0.4.7 per-specialist system prompt (verbatim from prompts/automation_system_prompt.txt).
+SYSTEM """You are Selora AI, an automation architect for Home Assistant. The user wants a recurring rule, schedule, or multi-step sequence saved as an automation.
+
+Return ONE JSON object with this shape and nothing else:
+{"intent":"automation","response":"<1-2 sentence explanation>","description":"<2-3 sentences: what it does, what triggers it, when it fires>","automation":{"alias":"<max 4 words>","description":"<...>","triggers":[<one-or-more>],"conditions":[<optional>],"actions":[<one-or-more>]}}
+
+RULES:
+- Use HA 2024+ plural keys: 'triggers', 'actions', 'conditions'.
+- Service calls use the 'service' key (e.g. 'light.turn_on', 'switch.turn_off', 'lock.lock', 'climate.set_temperature', 'media_player.turn_on', 'cover.close_cover', 'fan.turn_on', 'vacuum.start', 'persistent_notification.create', 'notify.notify').
+- State 'to'/'from' MUST be strings ("on"/"off"/"home"/"away"), never booleans.
+- Time values MUST be "HH:MM:SS" strings.
+- Durations MUST be "HH:MM:SS" or {"hours":N,"minutes":N,"seconds":N}, never raw integers.
+- automation.triggers MUST contain at least one entry. Supported trigger shapes:
+    state:           {"trigger":"state","entity_id":"<id>","to":"<state>","from":"<state>"}
+    time:            {"trigger":"time","at":"HH:MM:SS"}
+    sun:             {"trigger":"sun","event":"sunset"|"sunrise"}
+    numeric_state:   {"trigger":"numeric_state","entity_id":"<id>","above":N,"below":N}
+    template:        {"trigger":"template","value_template":"{{ ... }}"}
+  Multiple triggers can fire the same automation (e.g. {"to":"failed"} AND {"to":"partially_failed"}).
+  If unsure, default to {"trigger":"sun","event":"sunset"} or {"trigger":"time","at":"07:00:00"}.
+- automation.actions MUST contain at least one entry referencing entity_ids from AVAILABLE ENTITIES. Supported action shapes:
+    service call:    {"service":"<domain>.<action>","target":{"entity_id":"<id>"|[<ids>]},"data":{<params>}}
+    notification:    {"service":"persistent_notification.create","data":{"title":"<short>","message":"<body>"}}
+    notify channel:  {"service":"notify.notify","data":{"message":"<body>"}}
+  Multiple actions run in sequence (turn on lights AND set thermostat AND notify).
+- automation.conditions are OPTIONAL but encouraged when the user mentions "only on", "if", "while", "between". Supported:
+    state:           {"condition":"state","entity_id":"<id>","state":"<value>"}
+    numeric_state:   {"condition":"numeric_state","entity_id":"<id>","above":N,"below":N}
+    time:            {"condition":"time","after":"HH:MM:SS","before":"HH:MM:SS","weekday":["mon",...]}
+    sun:             {"condition":"sun","after":"sunset","before":"sunrise"}
+- Use entity_ids ONLY from AVAILABLE ENTITIES — never invent placeholder names (e.g. "samsung_smart_light_kitchen") or YAML examples for the user to fill in.
+- If the user's request is vague ("make an automation", "something useful"), pick a sensible automation grounded in AVAILABLE ENTITIES (e.g. lights at sunset, lock front door at bedtime, presence-based hallway light, notify on motion) and emit the full automation JSON.
+- Do NOT duplicate anything in EXISTING AUTOMATIONS.
+- description field MUST be 2-3 sentences explaining what the automation does, what triggers it, and when it fires. List all targeted entities so the user can verify before enabling.
+- The `response` field MUST be 2-3 sentences of natural prose explaining what the automation does. Use **markdown bold** for key entity friendly_names and trigger states (e.g., **Coffee Maker Plug**, **failed**). Embed entity tile markers [[entity:<entity_id>|<friendly_name>]] when first naming a specific device — the panel renders these as live status cards. End with ONE follow-up question offering to enhance the automation (e.g., "Want me to also send a mobile push notification?", "Should I dim the lights at the same time?", "Want me to skip weekends?").
+- Output ONLY the JSON object.
+
+EXAMPLES:
+
+User: Turn on kitchen lights at sunset every day.
+AVAILABLE ENTITIES: light.kitchen (friendly_name="Kitchen Lights"); sensor.sun (friendly_name="Sun")
+EXISTING AUTOMATIONS: (none)
+Selora AI: {"intent":"automation","response":"This automation turns on [[entity:light.kitchen|Kitchen Lights]] every day at **sunset**. The lights will come on automatically as soon as the sun sets, so you walk into a lit kitchen at dusk. Want me to also dim them to 50% instead of full brightness?","description":"Turns on Kitchen Lights every day at sunset using the sun trigger. Fires whenever the sun event 'sunset' occurs, regardless of season. Targets entity light.kitchen.","automation":{"alias":"Kitchen Lights Sunset","description":"Turns on Kitchen Lights at sunset every day.","triggers":[{"trigger":"sun","event":"sunset"}],"conditions":[],"actions":[{"service":"light.turn_on","target":{"entity_id":"light.kitchen"},"data":{}}]}}
+
+User: If the front door is unlocked after midnight, send me a notification.
+AVAILABLE ENTITIES: lock.front_door (friendly_name="Front Door Lock"); notify.mobile_app (friendly_name="Mobile Push")
+EXISTING AUTOMATIONS: (none)
+Selora AI: {"intent":"automation","response":"This automation watches [[entity:lock.front_door|Front Door Lock]] and sends a **Mobile Push** notification whenever it changes to **unlocked** between midnight and 6 AM. It only fires during those overnight hours so it doesn't spam you during the day. Want me to also flash the entryway light when this happens?","description":"Sends a mobile push when the Front Door Lock state changes to 'unlocked' during overnight hours (00:00-06:00). Triggers on state change; only acts inside the time window. Targets lock.front_door for the trigger and notify.mobile_app for the action.","automation":{"alias":"Late Night Unlock Alert","description":"Notify mobile if front door unlocked between midnight and 6 AM.","triggers":[{"trigger":"state","entity_id":"lock.front_door","to":"unlocked"}],"conditions":[{"condition":"time","after":"00:00:00","before":"06:00:00"}],"actions":[{"service":"notify.mobile_app","data":{"message":"Front Door Lock unlocked overnight."}}]}}
+
+User: Make me something useful.
+AVAILABLE ENTITIES: light.kitchen (friendly_name="Kitchen Lights"); light.living_room (friendly_name="Living Room Lights"); lock.front_door (friendly_name="Front Door Lock"); sensor.sun (friendly_name="Sun")
+EXISTING AUTOMATIONS: (none)
+Selora AI: {"intent":"automation","response":"Here's a useful one: at sunset, this turns on [[entity:light.kitchen|Kitchen Lights]] and [[entity:light.living_room|Living Room Lights]], and locks [[entity:lock.front_door|Front Door Lock]] for the evening. It runs every day automatically so you don't have to think about it. Want me to also adjust the thermostat at the same time?","description":"Runs every day at sunset. Turns on Kitchen Lights and Living Room Lights, then locks the Front Door Lock. Targets light.kitchen, light.living_room, and lock.front_door.","automation":{"alias":"Evening Routine","description":"At sunset: lights on, front door locked.","triggers":[{"trigger":"sun","event":"sunset"}],"conditions":[],"actions":[{"service":"light.turn_on","target":{"entity_id":["light.kitchen","light.living_room"]},"data":{}},{"service":"lock.lock","target":{"entity_id":"lock.front_door"},"data":{}}]}}"""
+
+# Generation params match training-time + integration defaults. repeat_penalty
+# is 1.0 (not 1.15) because v0.4.7 was trained without it; 1.15 measurably
+# distorts the slim-schema outputs (drops short keys like "r").
+PARAMETER temperature 0.0
+PARAMETER repeat_penalty 1.0
+PARAMETER repeat_last_n 256
+PARAMETER stop "<|im_end|>"
+PARAMETER stop "<|endoftext|>"

Modelfile.clarification

@@ -0,0 +1,40 @@
+# Ollama Modelfile for Selora-AI v0.4.7 / clarification specialist (Qwen3 1.7B + LoRA)
+# Build:  ollama create selora-qwen-clarification -f Modelfile.clarification
+# Run:    ollama run selora-qwen-clarification
+
+FROM ./qwen3_17b_base.f16.gguf
+ADAPTER ./selora-v047-clarification.f16.gguf
+
+# Qwen3 ChatML template (/no_think suppresses the thinking block — matches the
+# integration's enable_thinking=False chat-template-kwarg and how v0.4.7 was
+# trained).
+TEMPLATE """{{ if .System }}<|im_start|>system
+{{ .System }}<|im_end|>
+{{ end }}{{ if .Prompt }}<|im_start|>user
+/no_think {{ .Prompt }}<|im_end|>
+{{ end }}<|im_start|>assistant
+"""
+
+# v0.4.7 per-specialist system prompt (verbatim from prompts/clarification_system_prompt.txt).
+SYSTEM """You are Selora AI's clarification specialist for Home Assistant.
+
+When the user's request is ambiguous, respond with ONE JSON object only:
+{"q":"<question text>","o":["<option1>","<option2>",...]}
+
+Rules:
+- q: short, specific clarifying question. 1 sentence max.
+- o: optional array of suggested answers. Omit the o key when free-form input is appropriate.
+- Reference entity aliases from AVAILABLE ENTITIES when the ambiguity is about which entity.
+- Don't ask multiple questions in one turn — pick the single most important blocker.
+- Don't restate the user's full request; ask the one thing you need.
+
+Output JSON only — no narration, no markdown fences, no chain-of-thought."""
+
+# Generation params match training-time + integration defaults. repeat_penalty
+# is 1.0 (not 1.15) because v0.4.7 was trained without it; 1.15 measurably
+# distorts the slim-schema outputs (drops short keys like "r").
+PARAMETER temperature 0.0
+PARAMETER repeat_penalty 1.0
+PARAMETER repeat_last_n 256
+PARAMETER stop "<|im_end|>"
+PARAMETER stop "<|endoftext|>"

Modelfile.command

@@ -0,0 +1,42 @@
+# Ollama Modelfile for Selora-AI v0.4.7 / command specialist (Qwen3 1.7B + LoRA)
+# Build:  ollama create selora-qwen-command -f Modelfile.command
+# Run:    ollama run selora-qwen-command
+
+FROM ./qwen3_17b_base.f16.gguf
+ADAPTER ./selora-v047-command.f16.gguf
+
+# Qwen3 ChatML template (/no_think suppresses the thinking block — matches the
+# integration's enable_thinking=False chat-template-kwarg and how v0.4.7 was
+# trained).
+TEMPLATE """{{ if .System }}<|im_start|>system
+{{ .System }}<|im_end|>
+{{ end }}{{ if .Prompt }}<|im_start|>user
+/no_think {{ .Prompt }}<|im_end|>
+{{ end }}<|im_start|>assistant
+"""
+
+# v0.4.7 per-specialist system prompt (verbatim from prompts/command_system_prompt.txt).
+SYSTEM """You are Selora AI's command specialist for Home Assistant.
+
+Given a user command and the AVAILABLE ENTITIES list, respond with ONE JSON object only:
+{"c":[{"s":"<service>","e":"<entity_id>","d":{<optional params>}}],"r":"<short confirmation>"}
+
+Rules:
+- c: ordered array of one or more service calls. Calls execute in array order.
+- s: HA service in "domain.action" form (e.g. "light.turn_on", "lock.lock", "media_player.play_media", "scene.turn_on").
+- e: canonical entity_id from AVAILABLE ENTITIES. Never use the human alias — always the entity_id.
+- d: service parameters object. Omit the d key entirely when there are no params (do not include "d":{}).
+- r: ≤ 1 sentence past-tense confirmation describing what got done (e.g. "Kitchen light on.").
+- The service domain (before the dot) must match the entity_id's domain. light.turn_on goes with light.* entities, lock.lock goes with lock.* entities, etc.
+- For multi-target requests, produce one c entry per (service, entity_id) pair.
+
+Output JSON only — no narration, no markdown fences, no chain-of-thought."""
+
+# Generation params match training-time + integration defaults. repeat_penalty
+# is 1.0 (not 1.15) because v0.4.7 was trained without it; 1.15 measurably
+# distorts the slim-schema outputs (drops short keys like "r").
+PARAMETER temperature 0.0
+PARAMETER repeat_penalty 1.0
+PARAMETER repeat_last_n 256
+PARAMETER stop "<|im_end|>"
+PARAMETER stop "<|endoftext|>"

README.md

@@ -1,173 +1,146 @@
----
-license: apache-2.0
-base_model: Qwen/Qwen3-1.7B
-tags:
-  - text-generation
-  - qwen
-  - qwen3
-  - lora
-  - home-assistant
-  - home-automation
-  - smart-home
-  - iot
-  - instruction-tuned
-  - tool-use
-language:
-  - en
-library_name: transformers
-pipeline_tag: text-generation
+**Artifacts:** [Selora-AI-Local Package Registry — package 60760758](https://gitlab.com/selorahomes/products/selora-ai/models/-/packages/60760758)
+
 ---
 
-# Selora AI
-
-Selora AI is an instruction-tuned [Qwen3 1.7B](https://huggingface.co/Qwen/Qwen3-1.7B) model purpose-built for
-[**Home Assistant**](https://www.home-assistant.io/), the open-source **smart home**
-platform. Four specialist LoRA adapters cover device control, **home automation**
-authoring, Q&A, and clarification — each with its own trained system prompt and
-output shape. The `answer` adapter also emits a `query_state` tool envelope for
-live device-state queries against the Home Assistant REST API.
-
-Selora AI powers the [Selora AI Home Assistant integration](https://gitlab.com/selorahomes/products/selora-ai/ha-integration) and runs locally on Apple Silicon, Linux, or Windows via
-[Ollama](#ollama) or [llama.cpp](#llamacpp), or in the cloud via [vLLM](#vllm-cloud). It targets self-hosted **IoT** deployments where users want their
-home automation assistant to stay private and offline-first.
-
-## Use cases
-
-- **Voice and chat control of smart-home devices** — "turn off the kitchen
-  lights", "set the thermostat to 68", "open the garage door" — resolved against
-  live Home Assistant entity state.
-- **Natural-language home automation creation** — describe an automation in
-  plain English ("when the front door opens after 10pm, turn on the porch
-  light") and Selora returns valid Home Assistant YAML with a risk assessment
-  for review before deployment.
-- **Scene and routine orchestration** — chain actions across multiple entities
-  ("good night" → lock doors, dim bedroom lights, set thermostat) without
-  hand-writing scripts.
-- **Q&A about your home** — "is the laundry running?", "what's the temperature
-  upstairs?" — answered via a `query_state` tool call against the HA REST API.
-- **Privacy-first home assistant** — runs entirely on local hardware
-  (Raspberry Pi 5, Mac mini, NUC-class boxes) with no cloud dependency, so
-  device commands and home telemetry never leave the LAN.
-
-## Specialists
-
-| Adapter | Intent | Output shape |
-| --- | --- | --- |
-| `command` | "Turn off the kitchen lights" | `{intent:"command",response,calls:[…]}` |
-| `automation` | "Wake up lights at 6:30 AM" | `{intent:"automation",automation:{triggers,actions,…}}` |
-| `answer` | Q&A / small talk | `{intent:"answer",response}` |
-| `clarification` | Ask the user a follow-up | `{intent:"clarification",response}` |
-
-The HA integration's `selora_local` provider classifies each request to
-one of the four specialists before the call (cheap regex
-pre-classifier), then sends the request with `model:
-selora-v1-{specialist}`. Backends that support multi-LoRA
-(llama-server's `/lora-adapters`, vLLM `--enable-lora`) activate the
-matching adapter.
-
-## Quick start
-
-### Ollama
+# SeloraAI v0.4.7 — Local
 
-```bash
-ollama pull selora/commands
-ollama run selora/commands
+**Base:** [Qwen/Qwen3-1.7B-Instruct](https://huggingface.co/Qwen/Qwen3-1.7B)
+**Format:** GGUF **F16** base (~3.8 GB, no quantization) + 4 per-specialist LoRA adapters (F16)
+**Architecture:** 4 LoRA specialists routed by a runtime classifier
+**License:** Apache-2.0 (inherited from Qwen3)
+
+## Specialists (4 LoRAs)
+
+| Slot | Specialist | Iters | v0.4.3 final val | v0.4.7 final val | Δ |
+|---:|---|---:|---:|---:|---:|
+| 0 | command       | 800 | 0.016 | **0.012** | -25% |
+| 1 | automation    | 900 | 0.005 | **0.004** | -20% |
+| 2 | answer        | 600 | 0.014 | **0.011** | -21% |
+| 3 | clarification | 400 | 0.015 | **0.011** | -27% |
+
+Every specialist beats its v0.4.3 final val by 20-27%, and the lower starting val on v0.4.7 (e.g. answer 3.58 → 3.01 at iter 1) reflects cleaner training data — the entity-block reconciliation and the negation-answer reshape mean the base model sees less "surprise" structure on the first eval pass.
+
+## What changed since v0.4.3
+
+### Recipe specialist dropped from the bundle
+
+Recipe handling moves to a deterministic pipeline outside the model. The bundle is smaller (4 LoRAs instead of 5, ~120 MB → ~82 MB of LoRAs) and inference doesn't pay the recipe specialist's load cost. Consumer-side intent classifiers should map "install / set up / recipe" requests to the pipeline path, not to a model specialist.
+
+### Entity-block format reconciled with the integration
+
+`format_entities_block` in `scripts/gen_utils.py` now emits the exact per-line shape produced by `_format_entity_line` in `custom_components/selora_ai/llm_client/sanitize.py`:
+
+```
+AVAILABLE ENTITIES:
+  - entity_id=light.kitchen; state=off; friendly_name=Kitchen Lights
+  - entity_id=sensor.sun; state=below_horizon; friendly_name=Sun
 ```
 
-Modelfiles for all four specialists live in [`ollama/`](ollama/) and
-are also published as separate Ollama models.
+Whitelisted attribute keys (`device_class`, `unit_of_measurement`, `percentage`, `current_temperature`, `target_temperature`, `brightness`) are appended in the same order on both sides. This eliminates the train-vs-inference drift that previously sent the model out-of-distribution on entity-context blocks.
 
-### llama.cpp
+### _negation_answer multi-turn reshape
 
-```bash
-llama-server \
-  --model qwen3_17b_base.Q4_K_M.gguf \
-  --lora-init-without-apply \
-  --lora qwen3_17b_command.lora.gguf \
-  --lora qwen3_17b_automation.lora.gguf \
-  --lora qwen3_17b_answer.lora.gguf \
-  --lora qwen3_17b_clarification.lora.gguf \
-  --ctx-size 8192
+`gen_multiturn._negation_answer` was a two-turn chain whose first assistant turn was a command envelope (`{"c":[...],"r":"…want me to also …?"}`) and whose second was the answer (`{"r":"OK, no problem."}`). Routing the whole chain to the answer specialist's training set meant mlx-lm trained on every assistant turn in the example — so the answer LoRA's gradient was reinforced on the command envelope and learned to occasionally emit `c` arrays.
+
+The reshape folds the prior command turn into the user message as plain-English context, and only the final answer envelope reaches the LoRA's gradient:
+
+Before (one example, 5 messages):
+```
+[system: answer prompt]
+[user:      "turn off the yard light"]
+[assistant: {"c":[{"s":"light.turn_off","e":"light.yard"}],
+             "r":"Yard light off. Want me to turn off the kid bath light too?"}]
+[user:      "no thanks"]
+[assistant: {"r":"OK, no problem."}]
+```
+
+After (one example, 3 messages — same conversational context):
+```
+[system: answer prompt]
+[user:      "earlier you turned off the yard light and asked if I
+             wanted the kid bath light off too — no thanks"]
+[assistant: {"r":"OK, no problem."}]
 ```
 
-POST to `/lora-adapters` to switch the active LoRA before each
-`/v1/chat/completions` call.
+Multi-turn awareness at inference is unchanged — the integration still feeds prior conversation history via `_SELORA_LOCAL_HISTORY_TURNS=3`. The cleaning was on the training-data side only.
 
-### vLLM (cloud)
+### Pre-training audit script
+
+`tools/audit.py` runs 22-29 checks before training (tools/generators/prompts/configs import cleanly, cross-layer specialist lists agree as sets, prompts are ASCII-safe, token-length p99 within the 4096 budget). Catches drift early instead of finding it after a training run.
+
+## Training notes
+
+- Framework: **mlx-lm** on M5 Max (64 GB unified memory)
+- Optimizer: adam, learning rate 1e-4, batch size 4, max-seq-length 4096, grad-checkpoint enabled
+- Data: synthetic corpus generated by `v0.4.7/scripts/gen_*.py` from 10 curated home specs + procedural variants. ~45,694 examples total (post-filter, dropped 1,036 over the 14k-char threshold): command 16,081 / automation 14,928 / answer 11,385 / clarification 3,300.
+- Slot order is the **API contract**: 0=command, 1=automation, 2=answer, 3=clarification. Recipe is no longer a slot.
+- LoRA ranks set via per-specialist YAML configs at `v0.4.7/training/configs/<spec>.yaml`.
+
+## Files in this package
+
+- `qwen3_17b_base.f16.gguf` (~3.8 GB) — F16 base, no quantization (keeps LoRA evaluation parity with training)
+- 4 × `selora-v047-<specialist>.f16.gguf` (9.5 MB – 36 MB each, ~82 MB total)
+- `manifest.json` — SHA-256 sums, sizes, slot order, training metadata
+- 4 × `<specialist>_system_prompt.txt` — verbatim system prompts that produced the LoRAs
+- 4 × `Modelfile.<specialist>` — optional [Ollama](https://ollama.com) Modelfiles (see "Running with Ollama" below)
+
+## Running with Ollama (optional)
+
+If you have [Ollama](https://ollama.com) installed, you can use the same base + LoRA artifacts through Ollama instead of llama.cpp. The Modelfiles in this package bake in the ChatML template (with `/no_think`), the per-specialist system prompt, and the generation parameters used at training time — so the only thing you need to do is build each specialist once and run it.
+
+llama.cpp remains the reference runtime; Ollama is offered as a convenience for users who already have it on their system.
+
+### Installing Ollama
+
+These specialists require **Ollama 0.30 or later, installed via the official installer**. Two reasons to be specific:
+
+- **Pre-0.30 Ollama lacks LoRA inference support** — `ollama run` fails with `"failed to initialize model: loras are not yet implemented"`. The build (`ollama create`) succeeds; only inference is blocked. Upgrade if you're on an older version.
+- **`brew install ollama` is currently broken for all GGUF models on 0.30+.** The homebrew formula's `go build` does not produce the new `llama-server` binary that Ollama 0.30 split out for GGUF execution, so any GGUF model — including these — fails with `"error starting llama-server: llama-server binary not found"`. Tracking: [homebrew-core#285917](https://github.com/Homebrew/homebrew-core/issues/285917); fix queued in [PR #285963](https://github.com/Homebrew/homebrew-core/pull/285963). Until that lands, use the official installer.
+
+Install via one of:
 
 ```bash
-python -m vllm.entrypoints.openai.api_server \
-  --model ./qwen3_17b_hf \
-  --enable-lora --max-loras 4 --max-lora-rank 32 \
-  --lora-modules \
-    selora-v1-commands=/path/to/peft/command \
-    selora-v1-automations=/path/to/peft/automation \
-    selora-v1-answers=/path/to/peft/answer \
-    selora-v1-clarifications=/path/to/peft/clarification
+# macOS / Linux: one-line installer
+curl -fsSL https://ollama.com/install.sh | sh
+
+# macOS app bundle
+# https://ollama.com/download
 ```
 
-vLLM activates the matching LoRA based on the request's `model` field;
-no extra routing layer needed.
+### Build
 
-## Generation parameters
+Download the base, all four LoRA `.f16.gguf` files, and the four `Modelfile.*` files into a single directory, then from that directory:
 
-```json
-{
-  "temperature": 0.0,
-  "repeat_penalty": 1.15,
-  "repeat_last_n": 256,
-  "max_tokens": 384,
-  "stop": ["<|im_end|>", "<|endoftext|>"]
-}
+```bash
+ollama create selora-qwen-command       -f Modelfile.command
+ollama create selora-qwen-automation    -f Modelfile.automation
+ollama create selora-qwen-answer        -f Modelfile.answer
+ollama create selora-qwen-clarification -f Modelfile.clarification
 ```
 
-Bump `max_tokens` to 1536 for automation requests (longer JSON output).
-
-## Training
-
-Base: [Qwen3 1.7B](https://huggingface.co/Qwen/Qwen3-1.7B) fine-tuned
-with [Apple mlx-lm](https://github.com/ml-explore/mlx-examples). Each
-specialist has its own LoRA (rank 8–28, scale 20) trained on a curated
-HA-domain corpus (forum threads, HA docs, synthetic command /
-automation pairs). System prompts trained per-specialist; see
-[`prompts/`](prompts/). The `answer` adapter went through a sequential
-continuation pass that added a `query_state` tool envelope on top of
-the original answer-only training distribution; that's preserved in
-the augmented `prompts/answers.txt` and the `Modelfile.answers` SYSTEM
-block.
-
-## Evaluation
-
-10/10 parity pass rate on the four-intent suite (command, automation,
-answer, clarification — plus screenshot regressions). Validator and
-scenarios live in [`parity/`](parity/).
-
-## Files in this bundle
-
-| Artifact | Purpose | Distribution |
-| --- | --- | --- |
-| `qwen3_17b_base.IQ4_XS.gguf` | Quantized base for Ollama / llama.cpp | Hugging Face, ollama.com |
-| `qwen3_17b_{intent}.lora.gguf` (×4) | Specialist LoRA adapters | Hugging Face, ollama.com |
-| `Modelfile.{intent}` (×4) | Ollama recipes (base + LoRA + system prompt) | this repo, ollama.com |
-| `prompts/{intent}.txt` (×4) | Plain-text trained prompts (reference / testing) | this repo |
-
-The full-precision (f16) base and HF safetensors set used by vLLM /
-TGI / SageMaker live separately in the cloud bundle and are not yet
-mirrored to Hugging Face.
-
-## Citation
-
-```bibtex
-@misc{selora-ai-2026,
-  title  = {Selora AI: Qwen3 1.7B + LoRA Specialists for Home Assistant},
-  author = {{Selora Homes}},
-  year   = {2026},
-  url    = {https://huggingface.co/selora-homes/selora-ai}
-}
+The base GGUF (`qwen3_17b_base.f16.gguf`) is stored once in Ollama's blob store and shared across all four specialists; only the ~10–37 MB LoRA adapter is added per slot.
+
+### Run
+
+```bash
+ollama run selora-qwen-command
+# >>> turn on the kitchen light
+# {"c":[{"s":"light.turn_on","e":"light.kitchen"}],"r":"Kitchen light on."}
 ```
 
-Base model citation: Qwen Team, *Qwen3 Technical Report* (2025).
+Or hit the Ollama HTTP API directly — the template and system prompt are already attached:
+
+```bash
+curl http://localhost:11434/api/generate -d '{
+  "model": "selora-qwen-command",
+  "prompt": "AVAILABLE ENTITIES:\n  - entity_id=light.kitchen; state=off; friendly_name=Kitchen Lights\n\nturn on the kitchen light",
+  "stream": false
+}'
+```
 
-## License
+### Notes
 
-Apache-2.0 (matches the Qwen3 base license).
+- Pick the specialist that matches the intent: `command` for direct device control, `automation` for "create an automation that…", `answer` for state questions, `clarification` when input is ambiguous. In a full HA integration the runtime classifier picks for you — when calling Ollama directly, you choose by picking which model to run.
+- Keep `repeat_penalty` at `1.0`. Raising it (Ollama's default elsewhere is 1.1) measurably distorts the slim-schema output and can drop short keys like `r`.
+- The user message must include an `AVAILABLE ENTITIES:` block in the exact format above — these LoRAs were trained on that shape and go out-of-distribution without it.
+- Minimum Ollama version: **0.30** (LoRA inference). See "Installing Ollama" above for installer guidance.

manifest.json

@@ -1,54 +1,50 @@
 {
   "name": "selora-ai-local",
   "version": "0.4.7",
-  "description": "Selora AI v0.4.7 \u2014 Qwen3-1.7B Q6_K base + 4 LoRA specialists. Hub-optimal base quant (fits Vega 8 VRAM, no GTT spill). Specialists retrained on a compacted-JSON corpus (automation rank 32); command specialist prompt updated, other three unchanged from v0.4.6.",
+  "description": "Selora AI v0.4.7 \u2014 Qwen3-1.7B F16 base + 4 LoRA specialists with slim action-then-confirm output schemas. Multi-state entity context (per-entity attribute tails in AVAILABLE ENTITIES) for richer single-turn grounding. Inference: cache_prompt enabled to amortize system-prompt KV cache across requests.",
   "base_model": {
     "id": "Qwen/Qwen3-1.7B",
     "format": "gguf",
-    "dtype": "Q6_K",
-    "filename": "qwen3_17b_base.Q6_K.gguf",
-    "size_bytes": 1673006880,
-    "sha256": "a00bbdb411872149d73e1a0683b9b8a9f13cf74f98ba70ff8e8e430d9a093179"
+    "dtype": "F16",
+    "filename": "qwen3_17b_base.f16.gguf",
+    "size_bytes": 4069678880,
+    "sha256": "3e4009f0d96955a45f29aa77bded839d376d7832823c6909f76c84ace81dc445"
   },
   "loras": [
     {
       "slot": 0,
       "name": "command",
-      "rank": 16,
       "filename": "selora-v047-command.f16.gguf",
       "size_bytes": 19938528,
-      "sha256": "49ba46bc054259409f5cd52eb3d9971101ed858fba27c6678c89e145815af515"
+      "sha256": "b10b5131157698400ee9fafac08ab4101b81230a79ad067eb8f89bd4e29a6273"
     },
     {
       "slot": 1,
       "name": "automation",
-      "rank": 32,
       "filename": "selora-v047-automation.f16.gguf",
-      "size_bytes": 59791968,
-      "sha256": "32e5633f0e554fec5e336d993647065f85a4fffd348366cdc3417ca34824b527"
+      "size_bytes": 37374880,
+      "sha256": "1bdd8c54cb36332889498a67046f01b55de7e5ac019e350419ba98a9c104f78f"
     },
     {
       "slot": 2,
       "name": "answer",
-      "rank": 12,
       "filename": "selora-v047-answer.f16.gguf",
       "size_bytes": 14957792,
-      "sha256": "7584a04e13dd3e4973bfeb89ed01b7b29b3288d768d7bee15bcea3de89ff50c7"
+      "sha256": "9ec14105e7119675a75c1e166c132298886f4a25e57628c4ef720fce2080171e"
     },
     {
       "slot": 3,
       "name": "clarification",
-      "rank": 8,
       "filename": "selora-v047-clarification.f16.gguf",
       "size_bytes": 9977056,
-      "sha256": "75c06c0efbd9ca1e7108ec6ec5811f68e2dc5639d01ef583148a151b11398847"
+      "sha256": "071558279b1bc8c8609fc63a1524604aa7fcf721c5bd6d3ecdf1f55ad16f5e1a"
     }
   ],
   "system_prompts": {
     "command": {
       "filename": "command_system_prompt.txt",
-      "size_bytes": 1374,
-      "sha256": "0fa2b1669dedca18ddba2cebd7f72cd7cff0f7431b87ca4166a4bf60c7aed697"
+      "size_bytes": 1071,
+      "sha256": "9921c6fef09c6ebad4a2ed4fad1dbe7e76efe0bfe4e532bf7c7fe096864de6a4"
     },
     "automation": {
       "filename": "automation_system_prompt.txt",
@@ -68,29 +64,28 @@
   },
   "runtime": {
     "cache_prompt": true,
-    "ctx_size": 8192
+    "ctx_size": 4096
   },
   "training": {
     "framework": "mlx-lm",
     "base_model_repo": "Qwen/Qwen3-1.7B",
-    "scale": 20.0,
-    "rank_per_specialist": {
-      "command": 16,
-      "automation": 32,
-      "answer": 12,
-      "clarification": 8
-    },
+    "optimizer": "adam",
+    "learning_rate": 0.0001,
+    "batch_size": 4,
+    "max_seq_length": 4096,
+    "english_only": true,
+    "data_source": "synthetic \u2014 slim schemas in slim_schemas.md, generated by scripts/gen_{intent}.py from 10 curated home specs + procedural variants; service_matrix.py covers 49 (domain, service) pairs. tools.home_specs.diversify_states() injects multi-state attributes per training example.",
     "iterations_per_specialist": {
-      "command": 800,
-      "automation": 1800,
+      "command": 750,
       "answer": 600,
-      "clarification": 450
+      "clarification": 450,
+      "automation": 1050
     },
     "examples_per_specialist": {
-      "command": 11000,
-      "automation": 10000,
-      "answer": 5500,
-      "clarification": 3000
+      "command": 8800,
+      "answer": 6600,
+      "clarification": 3300,
+      "automation": 6600
     }
   }
 }

prompts/command_system_prompt.txt

@@ -5,11 +5,11 @@ Given a user command and the AVAILABLE ENTITIES list, respond with ONE JSON obje
 
 Rules:
 - c: ordered array of one or more service calls. Calls execute in array order.
-- s: HA service in "domain.action" form. Only these domains are accepted for immediate execution: light, switch, fan, media_player, climate, input_boolean, scene, cover. Examples: "light.turn_on", "switch.turn_off", "media_player.media_play", "cover.open_cover", "scene.turn_on". Do not emit lock.*, alarm_*, script.*, notify.*, or any other domain — those are blocked by the safety policy and the call will fail.
+- s: HA service in "domain.action" form (e.g. "light.turn_on", "lock.lock", "media_player.play_media", "scene.turn_on").
 - e: canonical entity_id from AVAILABLE ENTITIES. Never use the human alias — always the entity_id.
 - d: service parameters object. Omit the d key entirely when there are no params (do not include "d":{}).
 - r: ≤ 1 sentence past-tense confirmation describing what got done (e.g. "Kitchen light on.").
-- The service domain (before the dot) must match the entity_id's domain. light.turn_on goes with light.* entities, cover.open_cover goes with cover.* entities, etc.
+- The service domain (before the dot) must match the entity_id's domain. light.turn_on goes with light.* entities, lock.lock goes with lock.* entities, etc.
 - For multi-target requests, produce one c entry per (service, entity_id) pair.
 
 Output JSON only — no narration, no markdown fences, no chain-of-thought.

qwen3_17b_base.f16.gguf

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3e4009f0d96955a45f29aa77bded839d376d7832823c6909f76c84ace81dc445
+size 4069678880

selora-v047-answer.f16.gguf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:7584a04e13dd3e4973bfeb89ed01b7b29b3288d768d7bee15bcea3de89ff50c7
+oid sha256:9ec14105e7119675a75c1e166c132298886f4a25e57628c4ef720fce2080171e
 size 14957792

selora-v047-automation.f16.gguf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:32e5633f0e554fec5e336d993647065f85a4fffd348366cdc3417ca34824b527
-size 59791968
+oid sha256:1bdd8c54cb36332889498a67046f01b55de7e5ac019e350419ba98a9c104f78f
+size 37374880

selora-v047-clarification.f16.gguf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:75c06c0efbd9ca1e7108ec6ec5811f68e2dc5639d01ef583148a151b11398847
+oid sha256:071558279b1bc8c8609fc63a1524604aa7fcf721c5bd6d3ecdf1f55ad16f5e1a
 size 9977056

selora-v047-command.f16.gguf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:49ba46bc054259409f5cd52eb3d9971101ed858fba27c6678c89e145815af515
+oid sha256:b10b5131157698400ee9fafac08ab4101b81230a79ad067eb8f89bd4e29a6273
 size 19938528