OVOS-FALLBACK-1: Fallback Pipeline Plugin Specification#39
Draft
JarbasAl wants to merge 6 commits into
Draft
Conversation
Defines the fallback pipeline plugin that handles otherwise-unmatched utterances. Uses a ping/pong discovery cycle to find willing skills, selects by priority, and dispatches to the chosen skill. Covers skill registration (§3), discovery cycle (§4.1), selection algorithm (§4.2), dispatch to the selected skill (§5), and pipeline positioning after persona and deterministic intents (§6). Co-Authored-By: big-pickle <big-pickle@opencode.ai>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…name, bus-exchange exception - All: ovos.skills.fallback.* → ovos.fallback.* (consistent with ovos.stop.*, ovos.persona.*, ovos.audio.*) - §3: priority range examples made abstract (was 0-50, 50-80, 80-100) - §4.1: added ping payload table (utterances, lang, session); bus-exchange exception note; bounded → "bounded to a few hundred milliseconds" - §4.3: intent_name standardised as "fallback" (was e.g."fallback") - §8: conformance bounded window aligned with §4.1; standardised intent_name subscription - Removed ≈500ms from conformance section Co-Authored-By: Claude Code <claude@anthropic.com>
Design changes from previous draft: - Drop broadcast ping/pong (STOP-1 pattern); adopt sequential unicast per-skill query (CONVERSE-1 pattern): <skill_id>.fallback.request / <skill_id>.fallback.response - Pool ordering follows transformer/pipeline composition model: session.fallback_handlers (preference) → stage range → availability → session.blacklisted_skills (policy). One session field claimed. - No separate blacklisted_fallback_handlers — blacklisted_skills covers per-skill exclusion; blacklisted_pipelines covers stage exclusion - Multi-stage interleaving (fallback_high/medium/low) preserved via per-instance priority range configuration; session ordering works identically within any stage - Session-scoped registration via INTENT-4 §11.1 - skill_id payload MUST equal context.skill_id (anti-spoofing) Companion edits: - ovos-pipeline-1.md §7.3: reserve intent_name "fallback" - ovos-session-1.md §3: register fallback_handlers field; fix response_mode shape owner_id → skill_id Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- §3.3: recommended three-tier convention (0-49 high confidence, 50-74 medium, 75-100 low confidence / catch-all) with examples per tier - §3.3: default-response skill guidance — deployments SHOULD include a catch-all skill at priority 100 that always returns can_handle: true; without it unmatched utterances produce no user response - §8.1: add deployment SHOULD for catch-all skill - §1 non-goals: rephrase to not claim priority ranges are undefined (§3.3 now provides non-normative guidance) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
§2: add explicit statement that the defining property of a fallback skill is evaluating the utterance with its own logic rather than relying on intent registrations. Regular skills use INTENT-4 patterns selected by a pipeline plugin; fallback skills receive the raw utterance at query time and decide for themselves. Analogous to CONVERSE-1's per-skill converse poll. §6.1: fix missing utterance payload in the request. The request is derived via .reply() so context.session propagates, but data does not — the skill needs utterances+lang in the payload to do its evaluation. Add the two fields to the request table. Add prose explaining this is where the skill runs its own parsing logic. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Standardise on ping/pong for pipeline-plugin capability-discovery exchanges per AGENTS.md §4.5. The unicast dotted-addressed form <skill_id>.fallback.ping / <skill_id>.fallback.pong is consistent with the broadcast ovos.stop.ping / ovos.stop.pong pattern already established in STOP-1. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
JarbasAl
changed the title
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion issue: #48
Summary
Defines the fallback pipeline plugin — the final stage(s) in the utterance lifecycle that handle utterances no earlier stage claimed, by querying registered fallback skills in priority order and dispatching to the first willing one.
The defining property of a fallback skill is that it evaluates the utterance with its own logic rather than relying on registered intents. Regular skills declare coverage through INTENT-4; fallback skills receive the raw utterance at query time and decide for themselves — analogous to CONVERSE-1's per-skill poll.
What the spec covers
ovos.fallback.register/.deregister) with priority hint; session-scoped per INTENT-4 §11session.fallback_handlers(ordered preference list, same composition model as transformers)session.blacklisted_skills<skill_id>.fallback.ping/<skill_id>.fallback.pong); request carriesutterances+langso skill can parse the utterance itself<skill_id>:fallback(reserved intent name, PIPELINE-1 §7.3)fallback_high/medium/low) preserved via per-instance priority rangesCompanion edits (same PR)
ovos-pipeline-1.md§7.3 — reserve intent_namefallbackovos-session-1.md§3 — registerfallback_handlersfield