Skip to main content
Core concepts

A small set of ideas keeps the whole platform clear.

Read this once. The rest of Trinitite will click into place: who does the work, what your app gets back, and how each decision helps the next release.

1. The cast shares one rulebook​

Guardian

Checks each move

Applies your rules and returns a clear verdict.

Warden

Warden

Coordinates the work

Runs governed tools and keeps the chain connected.

Emu

Helps people use AI well

Brings guidance to the place where work happens.

  • A Guardian checks one call or action against the rules for that work.
  • Warden coordinates governed agents and tools across a larger job.
  • Emu helps people use AI with that same guidance close at hand.

The names describe roles, not separate governance systems. The same policies, identity, evidence, and result model connect them.

2. Your app gets one of six verdicts​

Every governed call returns one lowercase verdict. That verdict tells your app what to do next.

PassedThe output is fine.200 passthrough
CorrectedSomething was off. Trinitite fixed it.200 + JSON Patch
BlockedSomething was dangerous. Trinitite stopped it.403 GOVERNANCE_BLOCKED
MaskedSensitive data was swapped for a token on the way out.masking hook in proxy
HiTLA human needs to look.pending review, SLA-clocked
FailedThe check itself broke.guardian error, surfaced

passed, corrected, and blocked cover the common path. masked keeps sensitive values outside a trust boundary. hitl pauses for a person. failed tells the app that the governance check itself did not complete.

The verdict is always the source of truth. Emu adds personality, but never replaces a clear text state.

3. The result gives you more than a yes or no​

A GovernanceResult can include:

  • the output your app can use
  • the exact changes made to a corrected response
  • findings linked to policies and controls
  • a plain explanation of why the decision happened
  • risk and compliance context
  • an optional signed receipt for later verification

This lets developers build the app path and answer the next question: “What should we fix?”

4. Rules follow the goal​

Most teams need three layers:

  1. A baseline holds rules that apply across the organization.
  2. A scope groups AI that shares one goal, such as resolving refunds.
  3. An asset is a model client, MCP server, CLI, Skill, connector, sandbox, or RAG system attached to that work.

You set common rules once. A scope adds the goal and any focused rules. Assets inherit both. The SDK concepts guide shows the complete developer model.

5. Every useful failure can become a better test​

Technical workshop

Inspect the closed loop

Nothing advances until you do.

Step 1 of 5

Pin the baseline, goal, and scope.

Governed traffic gives evals real cases to study. Evals and red-teaming reveal repeat patterns. Those patterns can guide prompt candidates, Guardian training, model work, and release gates. The next version goes through the same checks.

That is how risk turns into product value: the team learns where to focus, can prove the change helped, and ships with less guesswork.

6. A receipt keeps the decision connected​

When a call produces a receipt, Trinitite keeps the decision linked to the Guardian version, policies, identity, and evidence behind it. Developers can trace or replay the decision later without rebuilding that context by hand.

Receipts support proof. Compliance pages provide framework crosswalks and evidence. They do not claim that one SDK setting certifies an organization.

Open the developer map​

You know the platform model. Next, see how the SDK brings model calls, MCP, CLI, Skills, evals, training, observability, governance, and compliance into one developer surface.

→ Explore the SDK

Last updated on