Status: Runnable

Bind a Verifier

A Verifier on its own checks nothing. You attach it to what it checks with a verified_by binding on the Service, on one component, or on an Agent Card. The binding also decides who runs it: your code, or a schedule.

Bind a Verifier your code calls

This is the support desk’s full Service. It binds one Verifier to the whole Service and two to the agent. Switch tabs to see each Card a binding points at:

support-desk.yaml yaml

apiVersion: wyrd/v1
kind: Service
metadata:
  name: support-desk
  version: 1.0.0
  space: default
spec:
  service_type: agent
  # The Service's own Verifier checks every answer the desk gives.
  verified_by:
    - verifier: ./no-refund-promise.yaml
  tables:
    - name: tickets
      schema:
        type: object
        properties:
          question: {type: string}
          answer: {type: string}
        required: [question, answer]
  components:
    - alias: agent
      ref: ./support-agent.yaml
      verified_by:
        - verifier: ./ticket-complete.yaml
        - verifier: ./follows-policy.yaml
    - alias: prompt
      ref: ./support-prompt.yaml

no-refund-promise.yaml yaml

# The Service-wide check: whatever component answers, the desk never promises
# a guaranteed refund. One assertion, no model.
apiVersion: wyrd/v1
kind: Verifier
metadata:
  name: no-refund-promise
  version: 1.0.0
  space: support
spec:
  description: A support answer never promises a guaranteed refund.
  inputs:
    answer: {type: json}
  requirements:
    - id: no-refund-promise
      statement: The answer never promises a guaranteed refund
      check: {kind: assert, path: inputs.answer, operator: not_contains, expected: guaranteed refund}

ticket-complete.yaml yaml

# A code check: sandboxed Python reads the ticket and names every field the
# help desk needs that is missing. No model.
apiVersion: wyrd/v1
kind: Verifier
metadata:
  name: ticket-complete
  version: 1.0.0
  space: support
spec:
  description: A support ticket carries the fields the help desk needs.
  inputs:
    ticket: {type: json}
  requirements:
    - id: ticket-complete
      statement: The ticket has an answer and an order id
      check:
        kind: code
        entrypoint: check
        inputs: {ticket: inputs.ticket}
        source:
          inline: |
            def check(ticket):
                missing = [field for field in ("answer", "order_id") if not ticket.get(field)]
                return {
                    "outcome": "failed" if missing else "passed",
                    "reason": "missing " + ", ".join(missing) if missing else "all fields present",
                    "citations": [{"slot": "ticket", "locator": {"json_pointer": ""}}],
                }

follows-policy.yaml yaml

# The support agent writes a refund decision letter; this Verifier checks the
# letter against the refund policy. The policy is fixed in policy-judge's
# prompt, so the letter is the only evidence the app sends, and a new policy
# means a new judge and Verifier version. The judge calls a model, so the app
# runs this one in the background.
apiVersion: wyrd/v1
kind: Verifier
metadata:
  name: follows-policy
  version: 1.0.0
  space: support
spec:
  description: A refund decision letter follows the refund policy.
  inputs:
    letter: {type: media, formats: [markdown], max_bytes: 1048576}
  steps:
    # Turn the uploaded file into text the judge can read and cite by line.
    - id: read-letter
      action: {kind: extract, from: inputs.letter}
  requirements:
    - id: follows-policy
      statement: The letter's refund decision follows the refund policy
      check:
        kind: agent
        agent: ./policy-judge.yaml
        inputs:
          claim: requirement.statement
          letter: steps.read-letter.output

support-agent.yaml yaml

apiVersion: wyrd/v1
kind: Agent
metadata:
  name: support-agent
  version: 1.0.0
  space: default
spec:
  prompt: ./support-prompt.yaml
  execution_route:
    kind: wyrd_gateway
    deployment: openai
  tool_names: []
  run_config:
    max_iterations: 1

Bound on	Verifier	Applies to
The Service’s `verified_by`	`no-refund-promise`	Every Run of the Service, as `run.observe.verify(...)`
The `agent` component’s `verified_by`	`ticket-complete`, `follows-policy`	The agent’s view of a Run, as `run.for_card("agent").observe.verify(...)`

None of these bindings has runs_on, so nothing runs them on its own. Your code calls verify or submit with the evidence; Verify inside the run shows both. That is the right default for anything that judges one request.

Bind a Verifier to a schedule

A schedule judges samples your service recorded over time, such as request latency, instead of one request. Add runs_on with a Trigger and optionally on_failure with the Operators to run when it fails:

latency-watch.yaml yaml

apiVersion: wyrd/v1
kind: Service
metadata:
  name: latency-watch
  version: 1.0.0
  space: default
spec:
  verified_by:
    - verifier: ./latency-shift.yaml
      runs_on: ./daily.yaml
      on_failure:
        - ./alert-on-call.yaml

latency-shift.yaml yaml

apiVersion: wyrd/v1
kind: Verifier
metadata:
  name: latency-shift
  version: 1.0.0
  space: default
spec:
  description: Daily check that request latency has not shifted from the healthy baseline.
  inputs:
    latency: {type: samples, features: [latency]}
  requirements:
    - id: latency-unshifted
      statement: Request latency has not shifted from the healthy baseline
      check:
        kind: drift
        on: inputs.latency
        method: Psi
        signal:
          kind: Distribution
          baseline_ref: {kind: Data, name: latency-baseline, version: 1.0.0, space: default}
          features: [latency]
        condition: {kind: Statistical}
        profile:
          kind: Psi
          binning_strategy: {kind: EqualWidth, n_bins: 10}
          threshold: {kind: Fixed, value: 0.25}

daily.yaml yaml

apiVersion: wyrd/v1
kind: Trigger
metadata:
  name: daily
  version: 1.0.0
  space: default
spec:
  description: Once a day at midnight UTC.
  kind: schedule
  cron: "0 0 * * *"

alert-on-call.yaml yaml

apiVersion: wyrd/v1
kind: Operator
metadata:
  name: alert-on-call
  version: 1.0.0
  space: default
spec:
  description: Page the on-call hook when latency shifts. The origin comes from the connection.
  kind: http
  method: post
  url: /hooks/latency-shift
  auth:
    scheme: bearer
    connection: on-call-hooks
  body:
    execution_id: "{{execution_id}}"
    summary: "{{summary}}"

Every day at midnight UTC, the server compares the day’s latency samples with the baseline and, on a failed verdict, posts to the on-call hook. Monitor drift walks through recording the samples.

Binding fields

Field	Required	Holds
`verifier`	Yes	A path to the Verifier’s Card file, or a declared Verifier
`runs_on`	No	A Trigger, as a path, a declared Card, or inline. Absent, only your code runs the Verifier
`on_failure`	No	Operators to run after a `failed` verdict, as paths, declared Cards, or inline

A Trigger is {kind: schedule, cron: "<cron>", tz: <zone>}, with tz defaulting to UTC. Schedules only judge recorded samples: binding runs_on to a Verifier with other inputs fails declaration. A binding has no other fields, and an unknown field such as when is rejected.

If it fails

You see	Cause	Fix
`WYRD_SDK_404_UNKNOWN_VERIFIER` from `verify` or `submit`	The Verifier isn’t bound to the view you called it on	Call it on the view whose Card binds it, or add the binding
`WYRD_SPEC_400_DUPLICATE_VERIFICATION_BINDING`	The same Verifier is bound twice on one subject	Remove one
`WYRD_SPEC_400_TRIGGER_ACTIVATION_MISMATCH`	`runs_on` is set on a Verifier that doesn’t judge `samples`	Remove `runs_on` and call the Verifier from code
`WYRD_PERMISSION_403_DENIED_RBAC` at declaration	A binding has `on_failure`, and your credential lacks `operators:invoke`	Declare with a credential that has it

Declare and inspect the Service. To write your own Verifier, see Author a Verifier.

Last updated October 19, 2026

Bind a Verifier

Bind a Verifier your code calls

Bind a Verifier to a schedule

Binding fields

If it fails

Next