Migration Guides
If you're already using a probabilistic AI safety system, you almost certainly want both worlds for a transition window — the old one keeps producing scores while you stand up Trinitite, and only when the deterministic Guardian has demonstrated parity (or improvement) does the old one come out.
These guides show side-by-side translations for the five most common cutovers.
Guardrail topics → Trinitite Policies. ApplyGuardrail → POST /v1/chat. Topic policies → JSON Patch corrections.
Guard categories → Guardian rubrics. Detect-only API → deterministic decision API.
RAIL specs → Trinitite Policies. Reasking → JSON Patch corrections without re-generation.
Per-category booleans → unified Passed/Corrected/Blocked. Scores → semantic difference vectors.
Colang flows → Policy clauses. Action server → Guardian. Self-check rails → Glass Box Ledger replay.
Recommended migration shape
- Run side-by-side. Send every output to both your existing system and Trinitite for ≥ 2 weeks. Reconcile the verdicts. Trinitite makes this easy via the Logs API — every Guardian decision is comparable.
- Map the false-positives and false-negatives. Each disagreement is a training signal — feed the cluster back as a new test scenario via the Test Suites endpoint.
- Promote the Guardian when the Safety Ratchet has advanced past your old system's known coverage.
- Cut the legacy system out of the inference path. Keep it on for one more cycle as a paranoia check, then retire.
- Notify your auditors. The Compliance Matrix gives you the framework-by-framework story for every decision the new Guardian makes.