Validation

Don’t Pass Mystery Blobs Around

Validation is the earliest (and cheapest) guardrail in the loop. It turns inputs and outputs into contracts so problems fail fast at the boundary - before they cascade into behavior specifications, evaluations, or incidents.

The story: bags of data vs contracts

If your workflow passes around an unstructured blob of data, everything looks fine until it doesn’t. A key goes missing. A value changes type. A downstream step assumes something exists, and now you’re debugging a production incident that started as “just a small change.”

Validation flips that around. Instead of "hope the data is shaped correctly," you get an explicit contract at the procedure boundary. Inputs are checked before your procedure runs, and outputs are verified before anything else can depend on them.

Fewer surprises: mistakes fail fast at the boundary, not deep inside the workflow.
Safer iteration: refactors can’t silently break callers.
More leverage: schemas unlock generated forms and machine-readable API docs.

This is one way to “close the loop” for AI-assisted development: make a small change, run it, and get an objective signal immediately - not a vague feeling that it “probably works.”

Schema-first design

In Tactus, schemas live with the procedure. They define what the procedure expects and what it guarantees to return.

procedure.tac

Input + output contracts

Procedure {
    input = {
        topic = field.string{required = true},
    },
    output = {
        findings = field.string{required = true},
        approved = field.boolean{required = true},
    },
    function(input)
        local findings = "..."
        local approved = false
        return {findings = findings, approved = approved}
    end,
}

What you get (even if you never say “Pydantic”)

When the “interface” is natural language, it’s easy for the shape of data to drift: missing fields, wrong types, half-structured JSON, and brittle glue code. Tactus uses schemas to keep the edges of your workflow predictable.

Input validation: catch bad or missing inputs before any tools run.
Output validation: guarantee that downstream code receives what it expects.
Generated UIs: schemas can drive human-in-the-loop forms and approvals.
API docs: procedures can expose machine-readable contracts (OpenAPI) automatically.

If you want the “how,” it’s built on a widely used Python validation layer: Pydantic.

Validation is the guardrail that catches problems earliest. Then come behavior specifications (hard “must not change” rules) and evaluations (a reliability gauge that tells you when a change made things worse).

Under the hood: Pydantic models

A schema is more than documentation. It becomes a real validator. If an agent “forgets” a required field, the run fails loudly instead of quietly returning a broken payload.

schemas.py

Validated classes (high level)

from pydantic import BaseModel

class Output(BaseModel):
    findings: str
    approved: bool

The important part isn’t the library name. It’s the effect: the runtime can enforce contracts consistently, generate helpful errors, and keep your workflow honest as it evolves.

Next: pair this with behavior specifications to lock in “what must always be true,” then run evaluations to quantify how often it stays true across real inputs. For the broader “layers of guardrails” story, see Guardrails and Guiding Principles.