Crossdeck University
Docs Start free
Watch — a guarantee that's a test, not a promise Film in production
0:00 / 0:00
Lesson 1 of 4 · Prove it

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.

4 min Concepts · CI

When you're done: you know how to verify Crossdeck's guarantees yourself, instead of taking anyone's word.

1 The trinity — claim, code, test

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.

2 How it's enforced

Four layers, each catching a different kind of drift

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

  • Schema-lock. A pre-commit and CI validator checks every contract's shape; a mis-shaped one is blocked before review.
  • Per-SDK assertion tests. Every test reference must resolve to a real test in the repo — Vitest for TS/Web/Node/React Native, XCTest for Swift, JUnit for Android. If a test was renamed or removed without updating its contract, the Contract Audit workflow fails the build.
  • CI + deploy. Every push to main runs the suites, audits the references, and publishes the backend — and the logs are publicly readable per run.
3 Verifying it yourself

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.

  • The JSON. The canonical contracts live under contracts/. Diff the directory between two SDK releases and you see exactly which structural guarantees changed.
  • The CI runs. Every push to main runs Test, Contract Audit, and Deploy — and the logs are public.
  • The SDK source. Each SDK is published to its public GitHub mirror and registry, and the runtime registry inside each artefact reads the same JSON that ships in the monorepo.

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.

4 Why this is the moat

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.

github · contracts/ · contract audit
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.

Read the full contract ledger in the docs

A contract is a matched triple — claim, code, test — stored as JSON under contracts/ and enforced at four layers (schema-lock, per-SDK tests, Contract Audit, deploy). You can verify the whole posture from three public sources: the JSON directory, the CI runs, and the SDK mirrors. The guarantee is the test, not the prose — proven, not promised.