spec: OVOS-FALLBACK-1 — poll semantics, pong correlation, registry liveness

[JarbasAl]

🤖 Auto-generated by Claude Fable 5 (claude-fable-5) via Claude Code — NOT human-reviewed. Verify before acting. Cross-spec citations were model-verified against dev source; behavior-change sections need owner judgment.

Audit follow-up on fallback.md. One file plus its CHANGELOG entry.

Behavior changes — needs owner sign-off

• active_handlers push on fallback dispatch (§7 note). fallback
  is a reserved intent_name, and PIPELINE-1 §7.3 currently suppresses
  the session.active_handlers push for every reserved name. This PR
  states that the fallback row does not suppress it, so a fallback
  dispatch is a fresh activation — which is what makes a running
  fallback skill stoppable and lets a language-model fallback take the
  next utterance through converse. It depends on the per-row property
  landing in the PIPELINE-1 PR; merge that first.
• Pong utterance echo (§6.1). A new REQUIRED field on the
  <skill_id>.fallback.pong wire shape. Written as REQUIRED going
  forward with absence tolerated as a legacy producer (SHOULD accept),
  so an old skill keeps working and the compatibility class does not
  move. Open question for the owner: if adding a required field is
  judged a class change on its own, the header Version (currently 2)
  would need attention — though VERSIONING.md defines only V0/V1/V2,
  so there is no "3" to move to. Not bumped here.

Major

• §6.1 the poll is the decision. No second round exists (unlike
  common query), so a slow evaluator is skipped, not delayed. The
  0.5 s RECOMMENDED ceiling is now stated as calibrated for local
  evaluators; a model-backed stage MUST configure a ceiling above
  its own evaluation latency, or the default silently converts every
  LLM fallback into a non-responder.
• §6.1 evaluation caching. A willing skill is asked the same
  question twice (ping, then dispatch). Skills SHOULD cache the
  ping-time result keyed (session_id, utterance), reuse it at
  dispatch, and discard on a new utterance — mirrors CQ §5.2.
• §6.1 stage collection ceiling. pool_size × per-poll ceiling
  sequentially, one window for the broadcast form. A deployment
  MUST set the stage's match-timeout bound at or above it
  (PIPELINE-1 §4.4, the CQ §2.1 pattern). Broadcast collapses the
  ceiling to a constant.
• §5 deterministic tie-break. Equal registered priorities MUST
  order deterministically; ascending skill_id RECOMMENDED.
  Registration arrival order is not acceptable — it makes the selected
  handler depend on process start order.
• §3.3 the "priority 100" claim is corrected: priority is an
  unbounded integer, so the catch-all guarantee comes from placement,
  not from the number.
• §6.1 reply-derivation rationale. The real reason the ping uses
  the reply derivation is that the responder always replies, so the
  query must arrive response-ready. Session propagation is common to
  every derivation and does not discriminate. The pong MUST derive
  via reply too.

Moderate

• §3.2 deregistration is keyed by context.session.session_id
  (INTENT-4 §11.3), never Message.data, and a payload/context
  skill_id mismatch MUST NOT be honoured — otherwise any skill
  can evict any other. Added to the §10 MUST list.
• §3.5 (new) registry liveness — deregister on shutdown (SHOULD),
  honour ovos.skill.deregister (SHOULD), evict after N consecutive
  timeouts and re-admit on re-register (MAY).
• §3.3 → §8.1 the default-response-skill rule moves to a normative
  home; §3.3 becomes purely descriptive; a §10 deployment bullet added.
• §1/§4 one session field, plus reuse of the PIPELINE-1 denylists.

Minor

• §5/§8.2 range bounds inclusive; ranges SHOULD partition with the last
  stage open above; a skill in no range is never queried — log at WARN.
• §6.1 acknowledges STOP-1's additional 1 s cap.
• §5 the range filter applies after preference, so
  fallback_handlers orders the pool but never admits into a stage.
• §6.1/§10 poll-wait wording unified.

From other audits

• §8.1 reworded: only the low-confidence catch-all fallback stage
  SHOULD follow the persona stage — fallback_high/fallback_medium
  MAY precede it, interleaved with intent-matching stages by priority
  range (§8.2). An earlier pass on this branch had §8.1 require
  persona before every fallback stage and flattened §8.2's example
  to match, which lost the deliberate confidence-interleaving design.
  §8.2's example is restored to stop_high, converse, intent_high, fallback_high, intent_medium, fallback_medium, common_query, persona, fallback_low, aligned with OVOS-PERSONA-1 §10's
  common_query → persona ordering (PR spec: PERSONA-1 — consistency audit (claim rule, mandatory speak, converse, OOB, positioning) #142).
• §3.4 cited INTENT-4 §11.1 alone for "available to all sessions" —
  split into §11.1 (keying) and §11.2 (inheritance).
• The .reply() Python-style residue is replaced with "the reply
  derivation (MSG-1 §5.2)".

Skipped

• GLOSSARY rows for fallback skill / fallback pipeline plugin —
  belongs to the GLOSSARY PR.

Version unchanged at 2. CHANGELOG updated in the existing format.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@JarbasAl, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 36 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 9ce9c3ae-ee28-420d-8368-dc031e0a4025

📥 Commits

Reviewing files that changed from the base of the PR and between 1d3622b and 462fc0e.

📒 Files selected for processing (2)

• CHANGELOG.md
• fallback.md

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}