ReleaseProof

Every dataset release needs a recall path.

Comment

Inspiration

Every dataset release needs a recall path.

An external-data request often begins as a vague sentence: “Send the customer file to Northstar for campaign analysis. They need it this week.”

The risk lives in everything that sentence omits. Which legal recipient? Which governed dataset? Which fields are actually necessary? Is there an active agreement? How long should access remain live? Who owns the decision? Did the provider expose exactly what was approved? What happens if consent, purpose, or vendor risk changes tomorrow?

Most release workflows optimize for publication. ReleaseProof treats minimization, observed-state verification, and recallability as parts of the release itself.

What it does

ReleaseProof is a proof-carrying data release autopilot for temporary external sharing.

Its core contract is:

Requested → Owner-approved effective → Observed

  1. A requester supplies ambiguous prose or an optional ticket/agreement image.
  2. The live Qwen path extracts a typed release intent and proposes narrow, read-only evidence calls.
  3. The server validates and rebinds those calls, completes mandatory recipient, dataset, current-share, and agreement reads, and treats all model output as untrusted.
  4. Deterministic policy either denies the request or produces the smallest permitted manifest.
  5. A data owner reviews and approves that exact effective manifest—not the original prose.
  6. A synthetic clean-room adapter creates one idempotent share.
  7. ReleaseProof reads provider state back and reports completion only when the observed recipient, dataset, tier, fields, expiry, and unique share identity match the approved expectation.
  8. Manual recall or TTL expiry revokes the workflow-created share, followed by read-after-recall verification.
  9. Model, tool, policy, owner, release, verification, and recall events are linked in a prior-hash audit chain.

Qwen is never offered a share-create, approval, recall, or policy-override tool. Language-model output is evidence, not authority.

Counterfactual minimization receipt

ReleaseProof makes minimization inspectable instead of reducing it to a warning.

Before approval, the operator sees a Requested → Effective manifest receipt. It shows the requested release tier, TTL, and every requested field-action beside the deterministic result. Retained fields are marked explicitly. Removed fields carry the policy finding that removed them. If an action is absent without a recognized permission, the release fails closed instead of inferring authority.

For the synthetic campaign scenario, an over-broad request for direct identifiers, raw export, consent override, and 72 hours becomes an owner-reviewable profile release containing only the allowed aggregate/profile actions with an 8-hour TTL.

This receipt is counterfactual evidence: it shows not only what will leave, but what would have left without the control.

Recall Contract

Recall is visible before approval, not added after publication.

The pre-approval Recall Contract binds:

  • the exact recipient and dataset target;
  • the manual or TTL trigger;
  • the reviewed active-share baseline;
  • the success condition for the workflow-created release; and
  • the required read-after-recall proof.

A recall command is not considered success. ReleaseProof reports success only after observed state returns to the reviewed baseline—normally zero active matching shares for that workflow-created release.

Recall revokes future synthetic access. It does not claim to erase copies a recipient may already have made.

How we built it

ReleaseProof is a TypeScript application with a React/Vite workbench and an Express API. The production build ships as one Node.js container, with Express serving both the frontend and API so the Qwen credential never enters browser code.

The backend owns an explicit state machine. Qwen handles the ambiguous interpretation boundary. Zod schemas and an allow-listed tool boundary validate the model response. Synthetic catalogs provide recipient, dataset, agreement, and current-share evidence. Deterministic policy owns authorization. A named owner decision gates the write. The sandbox adapter provides idempotent share creation and targeted recall, while separate verifiers define success from observed state.

The submitted backend is running on Alibaba Cloud Simple Application Server behind Nginx:

http://8.219.184.228

The deployed revision is:

https://github.com/xiaodouzi666/releaseproof/commit/7a6e503eb03849d19d663597e2993b093c201738

How Qwen Cloud is used

The implemented live path makes two logical OpenAI-compatible Qwen Cloud calls:

  • structured release-intent extraction; and
  • constrained read-only evidence-plan generation.

The server rejects malformed or unknown calls, rebinds arguments to validated identifiers, adds mandatory evidence reads that the plan omitted, and records provider/model/fallback/call/latency/token metadata without exposing the API key.

Qwen implementation:

https://github.com/xiaodouzi666/releaseproof/blob/7a6e503eb03849d19d663597e2993b093c201738/server/qwen.ts

At 04:21 Beijing time during final pre-deadline validation, the account inference entitlement activated. We then ran a fresh custom request on the public Alibaba-hosted deployment with scenarioId=null—not a preset or fixture.

Judge-friendly live workflow UI:

http://8.219.184.228/?workflow=wf_5b606ad019564ce9ae

Machine-verifiable live-Qwen JSON receipt:

http://8.219.184.228/api/workflows/wf_5b606ad019564ce9ae

That workflow used Qwen Cloud qwen3.7-plus without fallback, completed two model calls (940 prompt + 263 completion tokens, 4,769 ms total model latency), and recorded separate extraction.completed and context.plan_selected Qwen audit events. Deterministic policy produced requires_approval; the exact manifest was approved, the resulting share was read back and verified, then recalled and read back again. Final state is rolled_back, the grant is revoked, release verification and recall verification are both true, and the 34-event audit chain ends with recall.completed.

The public under-three-minute video was produced before activation and remains clearly labeled Recorded Demo. It substitutes deterministic fixtures only for Qwen extraction and read-plan generation; policy, owner approval, synthetic share creation, observed-state verification, recall, metrics, and audit use the same application paths. The public workflow JSON above is the final successful live-model evidence.

Challenges we ran into

Turning ambiguity into a manifest without turning the model into policy

Recipient names, dataset aliases, purposes, fields, and retention periods arrive in inconsistent prose. Qwen is useful for normalization and evidence planning, but a plausible response cannot establish vendor verification, agreement status, or dataset classification. We separated interpretation from deterministic release authority.

Defining “released” from reality

A successful write response does not prove that the intended projection exists. ReleaseProof treats create and recall as small sagas: act idempotently, read state back, compare it with the stored expectation, and fail closed on mismatch.

Making reversal part of the approval decision

Many demos stop at publication. We had to carry exact share identity, baseline state, TTL, recall trigger, and verification criteria through the whole workflow. The Recall Contract makes that exit path reviewable before the owner approves.

Keeping evidence honest while entitlement changed

The Qwen KYC/entitlement gate remained unresolved during most of submission preparation. Rather than disguising a fixture as a successful call, we exposed provider state, retained a clearly labeled Recorded Demo path, and documented the limitation. When inference access activated before the deadline, we ran a fresh custom request through the public deployment, verified the complete live-Qwen release-and-recall lifecycle, and updated the final evidence without relabeling the earlier video.

Accomplishments that we are proud of

  • A complete request-to-release-to-recall lifecycle.
  • A visible Requested → Owner-approved effective → Observed proof model.
  • Counterfactual field minimization with deterministic removal reasons.
  • A pre-approval Recall Contract with a measurable success condition.
  • Qwen structured extraction and read-only planning behind a strict schema/tool boundary.
  • Hard denial for unknown, inactive, or unverified recipients and restricted datasets.
  • Exact-manifest owner approval.
  • Idempotent synthetic share creation.
  • Read-after-release and read-after-recall verification.
  • A prior-hash-linked audit trail.
  • A successful public custom live-Qwen run with two model calls, token/latency metadata, and Qwen audit events.
  • Explicit live-Qwen versus Recorded Demo disclosure.
  • A public Alibaba Cloud deployment of the submitted revision.
  • 69/69 automated tests and 16/16 deterministic policy evaluation cases passing on the submitted revision.

What is real and what is simulated

The workflow orchestration, schema/tool boundary, deterministic policy, owner transition, minimization receipt, Recall Contract, idempotency, observed-state verification, recall path, metrics, audit chain, UI, container, and Alibaba Cloud deployment are implemented.

Recipients, datasets, agreements, and share state are synthetic fixtures. The clean-room adapter does not move real customer data. Destination-region enforcement, semantic agreement-purpose matching, authenticated owner identity, and provider-native clean-room integration are not implemented.

ReleaseProof is not a production DLP, privacy, consent, legal-review, or data-governance platform. Its audit chain is tamper-evident, not externally immutable.

What we learned

Data minimization is more useful when it produces an executable projection rather than a warning.

Approval is not proof. The provider state must be read back.

Recall is more credible when its target, baseline, trigger, and success condition are agreed before release.

And model transparency is stronger when the application shows exactly where the model stops having authority.

What is next

The next milestone is a read-only enterprise pilot:

  1. connect authoritative vendor, contract, dataset, lineage, consent, and residency sources;
  2. evaluate extraction quality on a consented multilingual text/image corpus and add drift/failure benchmarks;
  3. bind authenticated owner approval to a signed canonical manifest;
  4. integrate a provider-native clean room without enabling raw egress;
  5. add transactional state and durable expiry/recall scheduling;
  6. sign and externally anchor audit checkpoints; and
  7. enable production writes only after privacy, legal, security, and vendor-risk review.

Links

Built With

Share this project:

Updates

Submission history