Proofs-as-a-Service

Prove properties of your data — without installing anything.

Point the hosted Verified-Data API at your data and get back a signed certificate: this set is complete, this record is included (or provably absent), this aggregate is the honest answer over a range, this output came from this model. The engine runs server-side — the browser never receives engine source — and anyone can re-verify the certificate for free with only SHA-256.

Completeness

Prove a dataset is exactly what it claims to be — every declared row present, byte-for-byte, nothing silently dropped. A proof-of-exactness the receiver re-checks against a single SHA-256.

Inclusion

Prove a specific record IS in the sealed set without revealing the rest of it — a membership proof anyone can verify against the manifest.

Absence

Prove a record is NOT in the set — the harder, more valuable direction. Show a name, hash or ID was never present, verifiably, without exposing the corpus.

Range analytics

Prove an aggregate — a sum, count or min/max over a filtered window — is the honest answer over the exact rows, with a certificate that pins the query and the result hash.

Proof-of-inference

Prove a model output was produced by the declared model over the declared input — an addressable, re-verifiable capsule of the interaction, not a screenshot.

Free to re-verify

Verification is account-less and free by design. The whole point is that a third party checks the proof with only the certificate — no login, no engine, no trust in us.

Issuing costs; verifying is free

The commercial shape is deliberate. Issuing a proof runs the licensed engine server-side and meters per call. Verifying one is free and account-less — a regulator, auditor, customer or counterparty checks the certificate against a single SHA-256, with no login and nothing installed. That asymmetry is the product: you prove once, everyone re-checks forever, and nobody has to trust you or us.

One API surface

A single POST /api/at1/prove route, wrapped by the per-user auth + billing gate. The Next.js proxy never sees engine internals — it forwards to a Python gateway that runs the compiled at1 CLI on a box you or we control.

# issue a completeness proof over a sealed dataset (metered)
curl -X POST https://tinyfiles.io/api/at1/prove \
  -H "authorization: Bearer $AT1_KEY" \
  -F op=exactness -F file=@orders.at1
#   -> { ok: true, proof: "…", certificate: "cert.json", sha256: "…" }

# ask for an absence proof — "this SSN was never in the set"
curl -X POST .../api/at1/prove -F op=absence -F key=123-45-6789 -F file=@members.at1

# range analytics with a signed result hash
curl -X POST .../api/at1/prove -F op=range -F where=ts:2026-01:2026-02 -F agg=sum:amount

# VERIFY is free + account-less — anyone re-checks the certificate with only SHA-256
at1 verify cert.json            # -> integrity: PASS   (no login, no engine source)

Who this is for

  • Auditors & regulators — receive a proof they can re-check independently, without access to the raw corpus.
  • Data providers — ship a dataset with a completeness certificate so buyers know nothing was dropped.
  • Marketplaces & exchanges — settle disputes with membership / absence proofs instead of screenshots.
  • AI teams — attach a proof-of-inference to each model decision for the record.
Honest scope: hosted service, deploy-on-demand

This is a hosted service, not a self-install. Turning it on is two environment variables — AT1_API_URL and AT1_API_TOKEN — pointed at the Python gateway (query_service/at1_api_server.py) that holds the compiled engine; no code change is required. Until that gateway URL is set, POST /api/at1/prove returns { configured: false } and the console runs in a clearly labeled demo mode. We don't claim a live endpoint before the deploy — it's ready to switch on for your account.