# Run the contracts against your integration

Most platforms describe how they behave in prose and ask you to trust it. That's the wrong order. Crossdeck ships each guarantee as something you can check — a claim, the code that implements it, and a test that fails the day they drift apart.

Source: https://cross-deck.com/university/contract-tests/
Verified Crossdeck University lesson — prose plus real, runnable code.

## A guarantee that isn't a test is just a promise

A Crossdeck contract is a matched triple: a claim small enough to be true, the source code that implements it, and a test that fails the moment the source drifts from the claim. The product of a contract isn't the sentence in the docs — it's that test. Each one lives as a JSON file under contracts/<pillar>/<id>.json, carrying its claim, a reference to the code, a reference to the test, plus its pillar, status, and which SDK platforms it applies to.

## Four layers, each catching a different kind of drift

The contract set isn't decorative — it's enforced before code can ship:

## Three places, no trust required

This is the part that matters for you: you can audit Crossdeck's entire contract posture without relying on any marketing page, using three public sources.

That last point is the runtime tie-in: the SDK self-verifies against the same contracts at runtime, and its reliability hook can surface a contract failure straight from your own test harness — so the guarantee you read about is the guarantee running in your app.

## Proven, not promised

Anyone can write "we isolate entitlements per user" in their docs. Crossdeck turns that sentence into a JSON contract, a line of source, and a test that goes red the day it stops being true — and lets you read all three. When a platform's claims are falsifiable and the evidence is public, you don't have to trust it. You can check.

claim · code · test — green
 Every contract a matched triple, every test reference resolved by CI, every run public. The guarantee is the test, and you can read it.