Spec proposal: OVOS-FALLBACK-1 — Fallback Pipeline Plugin

Proposal for OVOS-FALLBACK-1, the fallback pipeline plugin specification.

Problem

Fallback skills — those that handle utterances through their own internal logic rather than registered intents — have no normative contract. The current implementation uses a broadcast ping/pong and numeric priorities but lacks any specification for session-level ordering preferences, session-scoped registration, or the conceptual distinction between intent-based and fallback skills.

Proposal

The defining property of a fallback skill is that it evaluates the utterance using its own logic rather than relying on an intent model. Regular skills declare coverage through INTENT-4 registrations; fallback skills receive the raw utterance at query time and decide for themselves.

Pool ordering follows the transformer/pipeline composition model:

• session.fallback_handlers (session preference) — ordered list of skill_ids
• Registered priority (default ordering hint)
• session.blacklisted_skills (policy)

Per-skill query uses the CONVERSE-1 unicast ping/pong pattern: <skill_id>.fallback.ping / <skill_id>.fallback.pong, sequential, stops at first willing skill.

Multi-stage interleaving preserved: fallback_high / fallback_medium / fallback_low stages with per-instance priority ranges remain valid.

Priority guidance: 0–49 high confidence (knowledge bases), 50–74 medium (web search), 75–100 low confidence (LLM catch-alls). Every deployment SHOULD include a catch-all skill at priority 100.

PR

PR #39

Start by reviewing the OVOS-FALLBACK-1 proposal and PR #39. Compare the proposed fallback-skill contract with the existing INTENT-4 and CONVERSE-1 patterns mentioned in the issue. Done means the specification resolves the ordering, registration, query, staging, and priority requirements.