Fallback Pipeline

The Fallback Pipeline in OpenVoiceOS (OVOS) manages how fallback skills are queried when no primary skill handles a user’s utterance. It coordinates multiple fallback handlers, ensuring the system gracefully attempts to respond even when regular intent matching fails.

---

Pipeline Stages

Pipeline ID	Priority Range	Description	Use Case
fallback_high	0 – 5	High-priority fallback skills	✅ Critical fallback handlers
fallback_medium	5 – 90	Medium-priority fallback skills	⚠️ General fallback skills
fallback_low	90 – 101	Low-priority fallback skills	🚫 Catch-all or chatbot fallback skills

Fallback skills register with a priority, allowing the pipeline to query them in order.

---

How It Works

• When no regular skill handles an utterance, the fallback pipeline queries registered fallback skills asynchronously.
• Each fallback skill can decide whether to handle the utterance.
• Fallback skills are tried by priority level (can be overriden by users)
• If no fallback skill accepts the utterance, no fallback response is generated by the pipeline itself.

---

Skill Integration

Skills integrate as fallbacks by:

• Registering on the message bus with a fallback priority.
• Listening for fallback queries carrying all utterance variations.
• Responding with success/failure on whether they handled the fallback.

This enables modular and customizable fallback behavior depending on your skill ecosystem.

---

Notes

• The pipeline itself does not define or enforce a default fallback response.
• The default "I don’t understand" reply is implemented in the separate ovos-skill-fallback-unknown skill.
• This modular design allows developers to create custom fallback strategies or add fallback chatbot skills without modifying the core pipeline.
• Fallback skills are expected to implement some dialog if they consume the utterance

---

Security

Just like with converse a badly designed or malicious skill can hijack the fallback skill loop, while this is not as serious as with converse some protections are also provided

You can configure what skills are allowed to use the fallback mechanism, you can also modify the fallback priority to ensure skills behave well together.

Since priority is defined by developers sometimes the default value is not appropriate and does not fit well with the installed skills collection

"skills": {
    // fallback skill configuration
    "fallbacks": {
        // you can add skill_id: priority to override the developer defined
        // priority of those skills, this allows customization
        // of unknown intent handling for default_skills + user preferences
        "fallback_priorities": {
           // "skill_id": 10
        },
        // fallback skill handling has 3 modes of operations:
        // - "accept_all"  # default mycroft-core behavior
        // - "whitelist"  # only call fallback for skills in "fallback_whitelist"
        // - "blacklist"  # only call fallback for skills NOT in "fallback_blacklist"
        "fallback_mode": "accept_all",
        "fallback_whitelist": [],
        "fallback_blacklist": []
    }
},