Soubi

Fallback Tiers

Explicit, per-feature, author-overridable behavior for every harness.

Soubi declares one of four dispositions for every portable feature × harness pair.

The four tiers

TierMeaningWhat the compiler does
supportlossless native representationemit the native artifact
degradelossy-but-functional fallback existsapply it automatically, emit a warning
dropno representation existsomit the artifact, emit a warning, keep building the rest
unsupported-hardfeature is load-bearing and can't be fakedexclude the whole target with a named failure

The compiler applies failures per target:

A drop or degrade never blocks a build. A single unsupported-hard failure excludes only that one target (with its reason preserved); every other harness still builds. One harness opting out never blocks the rest.

Degrade in practice

Current adapter translations include:

  • Kimi and MastraCode agents become invocable specialist skills.
  • Amp and Maki agents become delegation tools backed by their plugin APIs.
  • Herdr instructions, skills, commands, and agents become readable actions.
  • Gemini observe-only hooks are emitted with a warning that they cannot block.

Author override: onUnsupported

Every skill, hook, and agent accepts an override for behavior that must not be translated or dropped:

defineHook({
  event: "TaskCompleted",
  handler: { type: "command", command: "./notify.sh" },
  // If no harness can represent this natively, exclude that target rather
  // than ship a plugin that silently misbehaves:
  onUnsupported: "fail",
});
OverrideResulting tier
'drop'drop
'degrade'degrade
'fail'unsupported-hard

Use 'fail' for load-bearing behavior; use 'degrade' / 'drop' to soften an otherwise-hard default.

The build output and soubi check report every applied fallback, including the target, feature, and replacement.

On this page