# Evals — fal

These cases are run by the repo's eval harness: it loads `cases.yaml` and scores the skill's `description` + body against the `should_trigger` / `should_not_trigger` routing and the `capability` rubric. The `should_trigger` prompts (including the non-obvious "subscribe vs submit" and "signature won't verify" ones, and the Spanish webhook prompt) check that fal fires when an agent is wiring a fal endpoint call. The `should_not_trigger` prompts check the boundaries — each `route_to` id (`ai-media`, `replicate`, `runpod`, `modal`) must exist as a sibling skill for the routing to resolve. Because fal emits a checkable artifact (runnable client code + a webhook handler), the `capability` case is the real rigor check: the produced flow must hit every `must_include` item — current client + `FAL_KEY`, `submit` + `webhook_url` for the long job with the why, the webhook payload shape, ED25519 verification against the JWKS, an idempotent handler, reading the output URL, and a per-second cost estimate with the batch path. Run the harness from the repo root against `skills/fal/`.
