Skip to main content

Guardians

Give each kind of AI work its own focused guard. The Warden keeps the fleet in view. Every Guardian keeps its own rules, version, and receipts.

Status: Beta Companion docs: Scopes and assets · Training · Release gates Source of truth: Guardians API · Training API.

One goal, one focused guard​

A Guardian is a small enforcement model trained for a scope's goal. It checks intent, returns one of six verdicts, and produces the same answer for the same governed input and version.

refunds = tr.scope(
    "refunds",
    goal="Resolve valid refunds without exposing customer data.",
    guardian="guardian-refund-v3",
)

response = refunds.client("openai").chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Refund order 4821."}],
)
result = tr.result(response)

The model still does the useful work. The Guardian decides whether that work fits the goal and rules.

Warden fleet

One control plane, independently scoped Guardians

Warden coordinating three scoped Guardians

Choose a Guardian to inspect its assignment.

Bound scope
refunds/*
Active version
guardian-refund-v3

The Warden coordinates policy and promotion. Each Guardian keeps its own scope, version, and receipts.

Let the Warden coordinate the fleet​

Use separate Guardians when jobs have different goals or risk. A payment Guardian should not need the same judgment as a support Guardian.

The Warden coordinates assignments and promotion. It does not merge the Guardians into one broad judge.

Pin versions when repeatability matters​

Pin a version for a release test, replay, or careful rollout:

refunds = tr.scope(
    "refunds",
    goal="Resolve valid refunds without exposing customer data.",
    guardian="guardian-refund@v3",
)

A pinned scope stays on that version until you change the binding. An unpinned scope can follow the active version.

Version vault

Every version stays addressable

Active: guardian-refund-v3

guardian-refund-v3

Serving production calls

guardian://refund/v3

tr.distill creates v4 beside v3. Promotion and rollback change the active pointer; they do not overwrite the vault.

Inspect the version vault​

Get the Guardian, then open its training version vault:

guardian = tr.guardian.get("guardian-refund")
vault = tr.train.versions(guardian.guardian_id)

for version in vault.history():
    print(version.version_id, version.status)

Each training run adds a version. Prior versions remain available for comparison and rollback.

Compare before promotion​

Compare the candidate with the active version on the same approved suite:

comparison = vault.compare(version1=3, version2=4)
print(comparison.body)

Promote only after the comparison and release gate agree:

vault.promote(
    "v4",
    candidate_run_id="evr_candidate_4",
    baseline_run_id="evr_baseline_3",
)

Roll back without erasing history​

vault.rollback("previous")

Rollback changes which version is active. It does not delete the newer version or its evidence. You can inspect what happened, fix the data or recipe, and train another candidate.

Improve from reviewed calls​

Captured violations and approved corrections can feed the next version:

job = tr.distill(scope="refunds")
job.wait(timeout=1800)

print(job.version_id)

Training creates a candidate. A gate proves whether it is ready. Promotion remains a separate choice.

Where to go next​

Last updated on