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
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_idssession.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_lowstages 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