Gate-skip and receipt
non-emission.
Two named adversaries. What the protocol can prevent by design, what it can only make detectable, and the enforcement-tier model that names the difference plainly.
Two weaknesses lived in the earlier spec language, and v0.5 closes them. First: gate-enforcement assertions read as absolute, "the query engine enforces gates before returning anything," without naming which party operates that engine or what stops that party from running a modified one. A gate constrains disclosure, and disclosure is irreversible. Therefore: a gate is enforceable only by the party that holds the data at the instant of the operation, and only before that party releases the bytes. The strength of the guarantee is entirely a function of who that holder-of-record is and what trust root backs their execution.
Second: the receipt model treated non-emission as an edge case under the disputes section rather than a named adversary. A counterparty that simply never returns a receipt is outside the earlier dispute model, which addressed disagreements over receipt content. This page treats receipt suppression as a first-class threat and describes the defenses available at each tier.
Adversary A: the holder that skips gate evaluation
A · Gate-skipThe attack: a party that holds data runs a modified gate engine that skips evaluation, evaluates against a different gate set, or fabricates evaluation results, disclosing facts the honest engine would have withheld.
The protocol's answer is the enforcement-tier model. Not all deployments achieve the same guarantee; the spec names the difference explicitly rather than hiding it behind uniform "the engine enforces" language. The tier is a claim about the trust root of the holder-of-record's gate engine, and it travels in every receipt so auditors can inspect it:
| Enforcement tier | Holder-of-record | What stops gate-skip | Guarantee strength |
|---|---|---|---|
| T0 | Sovereign-self User's own vault / Sovereign Personal Agent (SPA) |
Nothing needs to: enforcer and protected party are the same principal. Gate-skip would harm only the user's own lenses or agents. | Prevention (structural). Gate-excluded facts cannot reach the lens. The strong claim is TRUE here. This is the slf-core v0 case. |
| T1 | Attested Provider in a verifiable runtime (TEE) |
Skipping the gate breaks the attestation quote carried in the receipt. The honest-engine measurement is part of what remote attestation covers. | Prevention, conditional on attestation integrity. Requires TEE or remote-attestation infrastructure. |
| T2 | Cryptographic Gate controls the decryption capability |
Skipping the gate yields no plaintext: the key is policy-bound or held by a threshold scheme that requires gate evaluation to release it. | Prevention (strongest). Applies only where the user controls encryption of the relevant facts. |
| T3 | Accountable-only Provider holds plaintext; trusted to evaluate honestly |
Nothing prevents it. A signed receipt names the gates the holder claims to have evaluated, so a holder that skips or fabricates evaluation produces receipts that do not reconcile with the substrate's signed gate set. The user can revoke the grant; the steward's trust list records the pattern. | Accountability, not prevention. Most real cross-party deployments today. Detection, revocation, and reputation are the available levers. |
The slf-core v0 reference implementation runs at T0, and its conformance suite now exercises the T0 prevention claim under attack: across a 32-variant adversarial corpus, a prompt-broadened agent and a cross-tenant adversary reach a zero leak rate against a gate-excluded canary, and every exclusion is receipted. That is evidence under attack, not a proof of non-interference (the residue is named below). A conformant implementation at any tier must carry an honest tier declaration in every receipt; a T3 deployment cannot assert T0 prevention guarantees. Every gate-enforcement assertion in the spec should be read against the tier of the deployment in which it runs.
"T3 is the fallback for immature deployments."
T3 describes most real cross-party data flows today, including GDPR-regulated healthcare and financial services. T1/T2 infrastructure (TEEs at substrate scale, policy-bound encryption across organizational boundaries) exists but is not yet widely deployed for substrate-level gate evaluation. The tier model names what deployments achieve. Most deployments arrive at T3 and make accountability the operating guarantee. That is an accurate description of the current state, not a failure of the spec.
Adversary B: the counterparty that suppresses its receipt
B · Receipt non-emissionThe attack: a counterparty that benefits from a disclosure never emits its signed receipt. The bilateral model assumes both sides return a signed receipt. A holder that practices receipt suppression is outside the earlier dispute model, which addressed disagreements over receipt content, not absence. Non-emission breaks the audit chain at its root: the user cannot verify gate evaluation that was never recorded.
The protocol's response operates in four layers, strongest defense first:
Receipt-as-precondition: gate the beneficiary.
The most effective defense flips the incentive. Rather than treating the receipt as a logging obligation the holder may or may not honor, make a valid receipt the thing the beneficiary of the operation needs to complete the transaction.
Counter-signature makes a one-sided receipt incomplete.
The v1 receipt mode requires both parties to sign and retain a copy. A holder that never emits means the user's side records the request and the missing counter-signature. An operation where the user holds a signed request record but no counter-signed receipt reads as an incomplete operation. The user's runtime treats that absence as a denial and declines to disclose further to that counterparty. Non-emission becomes visible as non-completion rather than silent absence.
For T1+ cross-party flows, counter-signing is load-bearing rather than optional. The v0 deferral of counter-signing is the right prioritization for the T0 reference implementation; it is the wrong default for any cross-party deployment that relies on receipts as audit evidence.
Opt-in witness for T1+ flows.
For high-stakes disclosures, receipts or their hashes may be appended to a user-controlled or steward-run transparency log, following the certificate-transparency pattern. Non-emission becomes detectable when the user has independent signal that an operation occurred: the transparency log holds a record of the operation even if the counterparty never emitted its receipt copy.
Base protocol is chain-neutral. The base protocol carries no dependency on any distributed ledger or central authority. The witness is a deployment option for T1+ flows, not a protocol requirement. The option is the right choice for high-stakes flows where the user needs an independent check against a counterparty they do not fully trust.
A witness cannot detect the absence of a receipt for an operation the user never knew happened. The transparency defense closes "suppressed receipt for a known operation," not "covert read of a T3-held substrate."
Revocation and reputation.
Pattern receipt suppression lowers the counterparty's trust tier in the steward's rating system and triggers grant revocation. This is the only lever against a covert plaintext-holder that has already disclosed and will not acknowledge it. It is ex post, not preventive, and it operates across a population of interactions rather than on a single event.
The rating system is a T3 backstop. It catches counterparties whose suppression pattern is visible across many users. It does not catch a single-event suppression by a counterparty with no prior history in the system.
The residual
C · What the protocol cannot preventThe protocol cannot force a self-interested party that fully controls both the data and the action to emit a receipt for a covert disclosure. What SLF can do is make the useful, completable, repeatable path require a receipt, so that non-emission costs the non-emitter (no completed transaction, dropped trust tier, no future grants). The spec states this plainly rather than implying receipts are self-enforcing.
Residual cases, named plainly:
- Covert read at T3. A provider that holds plaintext can read and act on it without emitting any receipt for the read. The user has no independent signal the read occurred unless a witness or counter-party-side audit trail exists. Prevention at T3 is not available for facts the provider already holds; T1/T2 infrastructure is the structural answer, and the T3 economic disincentive structure (revocation, reputation, legal backstop) is the available lever.
- Single-event suppression by a new counterparty. The rating system catches patterns across many interactions, not a first suppression event. Defense 2 (making silence into evidence of non-completion) is the strongest available tool for single-event cases.
- Gate-skip at T3 without detection. A T3 holder that skips gate evaluation and then produces a plausible-looking receipt can suppress evidence of the skip. The signed receipt names the gates claimed to have been evaluated; it does not prove they were evaluated correctly. T1/T2 address this; T3 does not.
These residuals are not spec failures. They describe what the protocol achieves relative to the trust structure of each deployment tier. At T0, gate-skip is structurally prevented and receipt non-emission is self-inflicted. At T3, accountability is the operating guarantee. The tier label in every receipt makes this distinction legible to auditors and implementers rather than hidden behind uniform "automatic enforcement" language.
What this page does not claim
D · Overclaims to avoid- The strong "cannot-leak" claim does not apply above T0. Gate-excluded facts structurally cannot reach the lens at T0 (sovereign vault). At T3, the guarantee is accountability via receipts. The tier label in the receipt is the distinction.
- Receipt-as-precondition depends on ecosystem adoption. The MUST spec rule is correct. The ecosystem gap is substantial: enforcement requires SLF-aware audiences willing to refuse uncredentialed data. The deployment guidance SHOULD acknowledges this gap.
- The opt-in witness does not extend to covert reads. Transparency closes "suppressed receipt for a known operation." It cannot detect a read the user never knew happened.
- T1 and T2 infrastructure does not yet exist at scale. TEEs for substrate-level gate evaluation and policy-bound encryption across organizational boundaries exist but are not yet deployed at the scale the T1/T2 claims require. The tier model describes where infrastructure needs to go; it is not a claim about current deployment reality.
- The conformance suite tests tier declaration, not tier truth. A conformant implementation must carry an honest tier label in every receipt. The suite can test that a T3 receipt does not assert T0 guarantees. It cannot audit whether a T3 holder's gate engine actually ran honestly, because that is not a testable property at the receipt layer alone.
If you are reading this with a security, regulatory, or deployment lens and the residuals look understated, the defenses look overstated, or a named adversary is missing, that is the feedback this draft needs. Contact details are in the header above.
← All SPA / SLF deep-dives