Your compliance blocks. Can it testify?

Three questions the stack cannot answer today

1. What ran? Which policy version executed on this transfer, against which data? Today: log files someone promises are complete, and an auditor who samples.
2. At what privacy cost? Persistent on-chain identity registries and decade-long workpapers that hold sampled client files are disclosure channels.
3. What survives? Ten-year retention obligations; evidence trapped inside vendor systems that turn over in a few years.

We do not replace the compliance gate. It stays. We make it provable, privacy-preserving, and vendor-independent, beside the part that works.

Three claims

Durable. The verifier is published, escrowed, and self-hostable: evidence stays checkable for the retention period with every vendor gone, including us.

Policy as a compiled decision

A compliance policy is not a PDF, not an allowlist, not a vendor black box. The rules already live as decision tables, rules engines, and policy-as-code. Lemma compiles them. The first planned frontend is a bounded subset of decision-table models (DMN class). Engineers who want to author directly still can; the compiler target stays readable and pinable in a repo.

Each checked transfer emits a certificate: a zero-knowledge proof that this exact policy version ran over attested inputs. Verifiable by anyone entitled. Revealing no one.

Data declares where it is allowed to live: public and verifiable by anyone; private, encrypted for authorized parties; secret never leaving its lawful holder’s machine; witness material consumed only inside the prover. A junior engineer cannot leak a residency into a public field; the compiler rejects it:

this.denial.reason = `blocked: sender residency ${this.sender.residency}`;

error E201: '@secret' data cannot reach '@public' field 'reason'
  sender.residency is @secret; custody: its holder's machine, forever

What a certificate is, and is not

Version control for regulation

Policies change. Evidence must say which version ran. A policy registry binds the approved source, the compiled artifact, the verifier configuration, and the effective activation point. Historical certificates stay checkable against the version that actually applied. Cutover is explicit; revocation and overlap windows are part of the record. A supervisor can ask “which version ran on this transfer” and get a hash, a key, and a block, not a slide deck.

Compliance that composes across institutions

A subscription on a tokenized fund can require evidence from several parties at once: the issuer’s offering restrictions, the custodian’s holding predicate, an eligibility provider’s status check, the distributor’s local policy. Each party keeps its private inputs. The receiving institution checks that the proofs join on the same asset, action, and subject, under compatible versions and time windows. Four unrelated valid proofs are not enough. Composition is the product.

FAQ

How is this different from on-ledger transfer controls? On-ledger controls enforce on one network. We produce evidence that can travel to a counterparty, an auditor, or another venue without forcing everyone onto the same ledger or the same operator.

How does a regulator or auditor use this? They re-perform the agreed population on their own hardware against the published verifier. They see computation results and version identity, not client files, unless a lawful disclosure path is separately opened.

What happens when the policy changes mid-lifecycle? New actions use the newly effective version. Historical actions remain checkable against their original version. The registry records the cutover.

What does it cost? The differential harness is free to run in CI. Paid work is the pilot that binds one real policy, one receiving audience, and a verification path written for the buyer’s auditor. Proof cost per checked transfer is part of the pilot measurement, not a slogan.

How do we integrate? Start beside the gate: differential-test the modules you already run. Adapters for common decision-table and rules-engine surfaces are the planned path; engineers keep ownership of authoring tools.

How we work with buyers

We start where the buyer already is: validating the compliance modules they run today against the standards those modules claim, then a calibrated pilot whose findings are written for their auditor. No rip-and-replace, no cryptography expertise required on the buyer's side. The full adoption path is part of the buyer materials, shared under invite.

Oracle boundary: coverage and standing rest on signed attestations consumed in-circuit, never proven underlying assets or KYC truth beyond contractual liability of attesters. A certificate is evidence, never discharge of statutory duty.