LIVE · receipts.thehiveryiq.com/v1/amplify

AmpliHive Patent Pending
The output-side leg of the signed inference rail.

Every smsh tier signs the prompt going in. AmpliHive enriches the answer coming out, pulling from a per-tenant corpus that no other tenant can reach, then signs the prompt, response, and enrichment under one ML-DSA-65 certificate. The corpus grows on every call. It's yours alone. Patent pending.

Run the live bench What would impress me curl /selftest
29.77%
Input token reduction, measured live on a 131-token SaaS indemnity prompt.
/v1/amplify/bench · 2026-06-02
4.47 ms
p50 AmpliHive overhead. p95 6.05 ms. (compile + compress + retrieve + sign + writeback)
n=10 sequential, prod
ML-DSA-65
FIPS 204 conformant. 1,952-byte pubkey, 3,309-byte sig, OID 2.16.840.1.101.3.4.3.18.
/v1/smsh/pq/selftest
0
Cross-tenant leaks. SQL predicate tenant_did = ? on every read. No global index.
verified 2026-06-02

What would actually impress me, if I were buying.

Four buyers, four hard questions. Each answered with a number you can re-derive, not a promise.

Fireworks · Lin Qiao
"Show me your overhead is below the SLA budget I quote my customers."
Compile, compress, retrieve, sign, and writeback all run in 4.47 ms at p50, 6.05 ms at p95, on a free Render dyno. Subtract LLM latency and we're line noise on your gradient routing budget.
curl /v1/amplify/bench → amplify_overhead_ms: 94.1 (with LLM) · amplify_only p95: 6.05
Anchorage · Rand
"Show me the cryptographic isolation is structural, not policy."
The corpus table has no index that skips tenant_did. No global view. No join across tenants. We seeded an Acme corpus, queried as another tenant, and got back zero rows. The boundary lives in the query, not in a wrapper.
leak_test = FALSE · SQL: WHERE tenant_did = ? · sealed at rest
Amazon · Bedrock
"Show me this does not lock me into one LLM provider."
On HTTP 402 from the primary gateway we fall back to a configured secondary LLM. The tenant DID, prompt hash, and certificate schema stay the same no matter which provider answers. Same key. Same signature shape. Same audit story.
claim 7: provider invariance · runtime: hivecompute → fallback at 402
Cloudflare · Prince
"Show me you don't add a hop I can't justify at the edge."
AmpliHive is one FastAPI router, about 600 lines. No neural embedding dependency at all. Embeddings come from a deterministic BLAKE2b hashing trick that runs on any hardware with no model fingerprint. Drop it next to Workers AI without a GPU.
embed dim 256 · BLAKE2b 8-byte digest · no torch · no transformers

Run the bench right now.

This calls the live production endpoint. The numbers below are from the call you just made, not from a cache.

Side-by-side: raw call vs full AmpliHive loop

Pick a prompt, or edit it, then click Run. You'll see raw provider latency and tokens, then AmpliHive's compressed-prompt latency and tokens, the post-quantum signature, and the difference between them.

Raw provider

status...
latency...
prompt tokens...
input cost...

AmpliHive loop

status...
total latency...
tokens after compress...
amplify overhead...
cert algorithm...
input cost...
Click Run bench to see live production numbers.

The closed loop. Output-side, on purpose.

smsh runs on the prompt going in. AmpliHive runs on the answer coming out. Together they're the only inference rail where one PQ public key checks both legs of the same call.

┌──── INPUT-SIDE (smsh family) ─────────┐ ┌──── OUTPUT-SIDE (AmpliHive) ──────────┐ │ │ │ │ caller ──▶ COMPILE ──▶ COMPRESS ──▶ LLM ──▶ AMPLIFY ──▶ CERTIFY ──▶ WRITEBACK ──▶ caller │ ▼ per-tenant corpus (WHERE tenant_did = ?) one ML-DSA-65 public key verifies the smsh receipt AND the AmpliHive certificate

Where AmpliHive plugs into the smsh family.

AmpliHive works independently of compression. It bolts onto the output side of every tier. Buy a tier alone, or add AmpliHive to close the loop on the whole rail. smshPQMax plus AmpliHive equals XCALIBUR.

smsh smshPQ smshMax smshPQMax
Compression (input) Lossless 2.83×Lossless 2.83× + PQTwo-tier 6.25×Two-tier 6.25× + PQ
Input receipt SHA-256ML-DSA-65SHA-256ML-DSA-65
AmpliHive (output) + add-on+ add-on+ add-onIncluded
Per-tenant corpus moat with AmpliHivewith AmpliHivewith AmpliHiveIncluded
Output receipt SHA-256ML-DSA-65SHA-256ML-DSA-65
Single-key dual-leg verify N/Awith AmpliHiveN/AIncluded
Article 50 ready N/AYesN/AYes
Sovereign routing N/AN/AN/AFour wires
Price (per 1M tokens) $0.10$0.18$0.30Custom
AmpliHive add-on + $0.06+ $0.06+ $0.06Included
Bundle name smsh + AmpliHivesmshPQ + AmpliHivesmshMax + AmpliHiveXCALIBUR

If I were trying to break it, where would I push?

Here are three classic attacks against signed-inference systems, and exactly what AmpliHive does about each one.

Cross-tenant exfiltration
"Can tenant A read tenant B's corpus by query manipulation?"
No SQL path crosses tenants. Every read is a parameterized predicate of the form WHERE tenant_did = ?. There's no global index, no join, no admin view that pulls data across tenants. The boundary lives in the query, not in middleware.
live test: seeded did:hive:acme, queried did:hive:other → 0 Acme rows
Embedding-model fingerprint attack
"Can an attacker reverse the embedding model and probe across tenants?"
There's no embedding model to reverse. Embeddings come from a deterministic BLAKE2b hashing trick with sign-bit accumulation. There's no neural weight to leak. Two tenants with identical content get identical embeddings, but neither can read the other's row.
claim 3 · BLAKE2b digest_size=8 · dim=256 · no torch dependency
Signature ceremony spoof
"Can someone forge the post-quantum certificate?"
The certificate is ML-DSA-65 over the canonical JSON of {tenant_did, prompt_hash, response_sha256, enrichment_sha256, ts_ns}. It's FIPS 204 conformant. The same private key signs the smsh input-side receipt, so one public key checks both. The published key OID is 2.16.840.1.101.3.4.3.18.
/v1/smsh/pq/selftest · sign 59.76 ms · verify 16.76 ms · conformant: true

The corpus is the moat.

Compression is a feature. Signatures are a feature. The corpus is a moat, because every call makes it deeper for that tenant and only that tenant. The confidence score keeps rising per tenant, call after call.

Cold tenant vs warm tenant, same prompt

First call to a new tenant DID:

confidence_cold0.00
corpus_hits0
top_scoreN/A

After 5 tenant-specific facts seeded:

confidence_warm0.21 ↑
corpus_hits5
top_score0.39 (own prior response)

The math, claim-protected

Confidence is computed as:

formula0.5·top_score + 0.5·min(1, n_corpus/N)
monotone in n_corpusYES (claim 14)
monotone in top_scoreYES (claim 14)
structurally exclusive to tenantYES (claim 2)

The eight powers, all output-side, all in every response.

Each AmpliHive response includes a fixed-schema powers block. Integrators never deal with schema churn. Auditors get the same eight fields every time.

P1
Memory
Tenant-scoped retrieval. Reports corpus_hits and density.
P2
Anticipator
Names the highest-scoring related prior response.
P3
Immune System
Flags adversarial patterns. Gates writeback.
P4
Learning Loop
Certified response enters the corpus for next call.
P5
Temporal Engine
Nanosecond timestamp signed inside the certificate.
P6
Chain-Aware
USDC on Base for downstream attestation settlement.
P7
Cold-Start Engine
First call bootstraps the corpus with itself.
P8
Adversarial Hardener
Prompt-injection patterns excluded from writeback.

Trust comes from numbers you can check yourself.

No screenshot. No "trust us." Every claim on this page can be checked from a public endpoint.

FIPS 204
ML-DSA-65 conformant. OID 2.16.840.1.101.3.4.3.18. NIST reference vectors verified at boot.
/v1/smsh/pq/selftest
29.77% cheaper input
Live bench on a 131-token SaaS indemnity prompt. Re-run anytime.
/v1/amplify/bench
p95 6.05 ms overhead
10 sequential warm calls. Compile + compress + retrieve + sign + writeback.
/v1/amplify/call · n=10

For the engineers in the room.

Four curls. No keys, no auth, no signup. Right now.

# 1. Local selftest: checks compile, compress, and ML-DSA-65 sign, no LLM needed curl -sS https://receipts.thehiveryiq.com/v1/amplify/selftest # 2. Live bench: raw provider vs full AmpliHive loop curl -sS "https://receipts.thehiveryiq.com/v1/amplify/bench?prompt=Draft%20a%20SaaS%20indemnity&tenant_did=did:hive:demo&max_tokens=300" # 3. Full closed loop with writeback curl -sS -X POST https://receipts.thehiveryiq.com/v1/amplify/call \ -H "Content-Type: application/json" \ -d '{"prompt":"Draft a 3-clause indemnity for SaaS vendor liability","tenant_did":"did:hive:demo","max_tokens":250}' # 4. Tenant retrieval (boundary enforced by a SQL predicate, not policy) curl -sS "https://receipts.thehiveryiq.com/v1/amplify/corpus/retrieve?tenant_did=did:hive:demo&query=indemnity&k=5"
Run /selftest PQ conformance proof Pilot conversation