Programmable trust isn't a slogan. It's an architecture.

"We make trust programmable" is on the front page of stg.thoryn.org. It sounds like a slogan. So let's unpack what it actually means in code — because the whole product is organised around it.

The problem with "trust"

Every product that handles real users makes trust decisions. Can this user log in? Are they old enough? Do they work at a customer's company? Do they hold a valid driving licence? Do they have permission to open this door?

Most systems answer those questions implicitly. There is a session cookie somewhere, a role column in the database, an IF branch in the code. When someone asks "why was this person allowed in?" the answer is scattered across six services and two engineers' heads.

Programmable trust means: every one of those decisions is a piece of data and code you can read, review, and version. No implicit session trust. No invisible IF branches.

What's programmable in our platform

We built the platform around four primitives. Each is an API:

Identity — Broker

An OID4VP gateway that accepts Verifiable Credentials from any wallet, validates them against the Trust Registry, and returns verified claims. No session state. No stored user identities. A credential comes in, verified claims go out.

Trust anchors — Trust Registry

A registry of the issuers you trust and the credential types they can issue. Called in real time on every verification. Revoke an issuer at 15:00, and by 15:00:01 every verifier in your ecosystem has stopped accepting their credentials.

Rules — Policy Engine

A Kotlin library that evaluates JSON rule trees against claim maps. Rules are pure data:

{
  "operator": "AND",
  "conditions": [
    { "field": "role",      "op": "eq", "value": "officer" },
    { "field": "clearance", "op": "in", "value": ["SECRET", "TOP_SECRET"] }
  ]
}

Check it into git. Review it like code. Evaluate it in a millisecond.

Enforcement — TrustGate

A physical access gateway that brings all the above together at the edge. Zones tie to rules. Doors render QR codes. Credentials unlock things. Every attempt is logged.

Why "programmable" matters

When trust is programmable, three things become true at once.

It's auditable. You can point at a specific rule and say "this is why the door opened." Not "the SAML group claim probably matched." Not "the session must have been trusted." The rule fired, the decision was recorded, the reason is in the log.

It's composable. Trust Registry answers "who do we trust?" Policy Engine answers "under what conditions?" Broker answers "did they actually prove it?" Each is replaceable, testable, and reusable. None of them holds the whole decision; together they do.

It's reversible. Revoke an issuer, change a rule, update a policy — the change propagates in seconds with a full audit trail. Compared to the alternative (rolling a release to every service that had the trust decision hardcoded), this is a different world.

What's not programmable, and why that's fine

We don't pretend everything is code. The decision to trust a new credential issuer is still a human one. The policy that says "officers with SECRET clearance can enter" still comes from a security officer, not from a ML model. The cryptography under SD-JWT is still math, not config.

Programmable trust doesn't eliminate judgment. It moves judgment to where it belongs — in the rule, in the registry, in the code review — instead of hiding it in application logic.

Try it

The easiest way to see programmable trust in action is to run one of the wallet broker demos locally — KvK, Gate, Transport, Nightclub, Red Team, or Army. Each one exercises the full stack with a real OpenID4VP flow, a real Trust Registry, and real Policy Engine rules. All in Docker, no cloud account required.

Or request access and we will walk you through wiring the platform into your own product. Most teams are making their first verified trust decision within a week.