Same input. Same configuration. Same output.
We say Sentiqra is deterministic. Every LLM-based competitor says their moderation is "consistent." One of those claims is verifiable. This page is the verification.
Enter any text below. Click detect. Look at the comparison hash. Now click detect again. The hash is identical. Not similar. Not close. Identical - byte for byte, under the same pinned configuration and output profile.
Then run the same loop against any analyzer you already use - and compare the response hashes on repeated calls.
Language: · anonymous runs are limited to curated samples executed live — custom text requires an request access
Response
Live result - run . The detection configuration ID is returned in verification.configuration in the response itself.
Demo comparison hash (SHA-256)
Computed in your browser over the displayed analysis fields - a demonstration aid only, not the API's verification.fingerprint. Identical hashes across runs prove determinism; the API fingerprint and signature are what you'd store and verify in production.
Run this exact request again - the hash will be identical.
Verification log
SECTION 1
You just verified our core architectural claim.
The demo fingerprint you saw is the fp2_ value recomputed in your browser from the response itself - RFC 8785 canonical JSON over the analysis payload (analyzers, outcomes, signals, language, configuration), hashed with SHA-256 and checked against the signed verification.fingerprint returned in every successful analysis response. If a single byte in the analysis differed between runs - one score at 0.941 vs 0.942, one label spelled differently, one field in a different order - the fingerprint would be completely different.
The fact that the analysis is identical across multiple calls means:
Identical analysis payload - same fields, same order, same formatting
Identical indicator set - same detections triggered, none added or dropped
Identical scores - bit-for-bit equal, not "very similar"
Identical configuration ID - both runs resolved to the same immutable analysis configuration
This will still be true tomorrow. And next month. And in six months when a user appeals a moderation decision and you need to reproduce your reasoning. Nothing about the API's behavior on this exact input will change unless we ship an explicitly versioned configuration update - and if we do, the configuration ID in the response tells you.
The receipt fields - what each one proves
Canonical result payload (v2+) { analyzers[], configuration, language, outcomes{}, signals[] }
- the detection decision, never the text
│
│ RFC 8785 (JCS) canonical JSON → SHA-256, truncated to 16 bytes
▼
verification.fingerprint fp2_… Result identity - recompute to prove the result is unchanged
API credential ──HKDF-SHA256 (info "sentiqra/input-binding/v3", L=32)──▶ binding key bk_…
- purpose-separated: verifies commitments, cannot authenticate
Canonical input payload { language, text } - bound separately, keyed by the binding key
│
│ RFC 8785 (JCS) → HMAC-SHA256 (binding key), truncated to 16 bytes
▼
verification.input_commitment ic3_… Input binding - only the binding-key holder can
confirm which input a receipt was issued for
{ fingerprint | input_commitment } - ASCII concatenation, '|' separator
│
│ Ed25519 (Sentiqra-held private key; public key published)
▼
verification.signature sig_ed25519_… Authenticity - proves Sentiqra issued this
receipt; verify fully offline with the public key from
GET /v1/verify/public-key (no API key needed)
verification.key_id edk_… Which published public key signed this receipt
verification.binding_key_id bk_… Which derived binding key bound the input (v3)
verification.version 3 Receipt spec version (1-2 = legacy receipts)
verification.configuration sqcfg_… Pinned configuration ID - replay this exact version to reproduceTogether these fields are the verification receipt. The fingerprint deliberately excludes the submitted text, so a receipt cannot be used to test candidate inputs offline. Timestamps, request IDs, and latency are operational metadata - excluded from the fingerprint by design; that also means the fingerprint proves result identity, not a unique transaction or its time - identical inputs yield identical fingerprints. For event evidence, mint a separately versioned event record via POST /v1/event and verify it via POST /v1/verify/event. The v3 binding key is HKDF-derived from the API credential, so verification secrets no longer couple to credential retention - revoke the credential, keep the bk_ key in your vault. Receipts issued under spec v1/v2 (fp_/ic_/ic2_ prefixes) remain verifiable via POST /v1/verify.
SECTION 2
The same experiment. A completely different result.
Now run the same experiment against a generative analyzer - same input, 20 calls, a few minutes apart - and compare the response hashes:
Sentiqra
reproduced live on this pageUnique hashes: 1 - verify it with the demo above
Generative endpoint
illustrative exampleIllustrative pattern, not a vendor measurement - run the curl loop in Section 4 against your own provider to see your own numbers.
Generated output commonly varies between calls. This is not a bug - sampling produces variance by design, serving fleets introduce hardware-level non-determinism, and even when the visible answer agrees, surrounding "reasoning" text differs. temperature=0 and seed parameters reduce variance but are not, by themselves, a published commitment to byte-identical output.
In a moderation deployment, whether that variance is a problem is a contract question. If the analysis behind a flag can differ between calls, reproducing the exact analysis that triggered an action - for an appeal, a regulator, or a DSA transparency report - depends on what your vendor's versioning and replay terms actually commit to. Worth checking before you need it.
SECTION 3
Reliability is a promise. Reproducibility is a property you can test.
"Deterministic" gets used loosely - it can mean anything from "produces similar labels most of the time" to a contractual guarantee. We mean "produces a byte-identical analysis payload for the same input under the same pinned configuration and output profile, verifiable via cryptographic hash."
This distinction matters for four groups of buyers:
Compliance officers preparing for DSA transparency reports need reproducible per-decision evidence. A response that can differ between calls cannot, by itself, reproduce the analysis behind a decision. Sentiqra receipts can.
Trust & Safety leaders defending appeals need to show why a specific piece of content was actioned. "The model analyzed it as harassment" isn't a defense if the model analyzes it differently on Tuesday.
Security teams building post-incident evidence need to reconstruct what fired, when, and why. Non-reproducible detection signals aren't admissible in the story.
Anyone deploying detection in a regulated environment needs audit trails that hold up over time. Generated analysis can shift between model revisions - whether your vendor commits to stability is a contract question. Sentiqra behavior is locked to an immutable configuration you can pin, with a published support policy for historical IDs.
If your deployment doesn't need reproducibility, LLM moderation is fine. If it does, this is the difference that matters.
SECTION 4
Verify programmatically
Don't take our word for it - automate the test.
Copy this into your terminal. Send the same request 100 times. Count how many unique fingerprints you get.
Test Sentiqra:
for i in {1..100}; do
curl -s -X POST https://sentiqra.tech/v1/analyze \
-H "Authorization: Bearer sq_live_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{"text": "I hope you fail miserably at everything you do", "language": "en", "analyzers": ["trust-safety"]}' \
| jq -r '.verification.fingerprint'
done | sort | uniq -c
# Expected output: 100 identical fingerprints
# (response bodies differ - latency_ms is volatile metadata;
# the fingerprint covers only the canonical analysis payload)
Test any LLM moderation you're currently using:
for i in {1..100}; do
curl -s -X POST https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer YOUR_OPENAI_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4o",
"temperature": 0,
"messages": [{
"role": "user",
"content": "Analyze this message. Reply with JSON: {\"harmful\": boolean, \"category\": string, \"confidence\": number}. Message: I hope you fail miserably at everything you do"
}]
}' \
| sha256sum
done | sort | uniq -c
# Compare the unique-hash count with the Sentiqra result above -
# you will typically observe multiple distinct hashes, even at temperature=0
Get a free API key and run the test on your own hardware, from your own network. We're publishing this test because we're confident in the result.
Request accessSECTION 5
What "deterministic" actually guarantees
The technical guarantee, in plain language.
Given:
- • The same input text (any language, any length up to our API limits)
- • The same pinned detection configuration (returned in every successful analysis response as
verification.configuration)
The API will always return:
- • The same analysis payload - byte-identical, field for field
- • The same classification fingerprint of that payload
- • Operational metadata - request ID, timestamps, latency - may differ and is excluded from the fingerprint
This holds:
- • Across time (today, next month, 12 months from now)
- • Across caller geographies - the guarantee doesn't depend on where your request originates (deployment regions and transfer basis are disclosed in the Trust Center)
- • Across scale (whether we're processing 100 calls/day or 10M/day)
- • Across our own infrastructure changes (server upgrades, region migrations, etc.)
What this rules out:
- • Silent model updates changing behavior
- • Non-deterministic sampling introducing variance
- • Model drift between requests
- • "Improvements" that shift enforcement statistics without warning
- • Category hallucinations that don't exist in your policy
What this does not guarantee:
- • 100% analysis accuracy - no system is right 100% of the time
- • Immunity from you being wrong about which threshold to set - that's your call
- • Reproducibility across configuration upgrades - a new configuration = new outputs, but always intentional and documented
SECTION 6
For the technical readers: why this is architecturally different
Why byte-identical output is rare in generative pipelines - even at temperature=0.
1. Uncontrolled serving environments.
Different hardware generations, accelerator library versions, and batch sizes produce slightly different floating-point results for the same input. LLM providers run inference across large heterogeneous fleets; you have no control over which hardware served your request. Two identical requests can hit different hardware and return different (though similar) outputs.
2. Model updates without version pinning.
OpenAI, Anthropic, and Google update their base models regularly. gpt-4o today is not gpt-4o in six months. You can pin to dated snapshots for a period, but they eventually get deprecated. Sentiqra publishes a configuration lifecycle - an update creates a new configuration, and the old one stays supported for the window in the published support policy (or your contract's commitment) before it can become unavailable.
3. Autoregressive generation is a probability distribution, not a lookup.
Even with temperature=0, the model isn't retrieving a stored answer - it's regenerating token-by-token from probability distributions. Any tiebreak in the top-token selection can produce different completions.
4. Wrapping "classification" in generation loses precision.
LLM-based analyzers work by asking the model to generate a JSON response describing the analysis. The analysis label might match across runs, but the surrounding JSON - key ordering, whitespace, occasional extra fields - varies. Which means the response byte-string, and its hash, varies.
Sentiqra doesn't have these problems, because it doesn't do generation. Submitted text is processed by a deterministic, versioned non-generative analysis engine that returns structured signals and a receipt. Behavior is fixed by the pinned configuration - there is no probabilistic sampling anywhere.
Same normalized input + same pinned configuration + same output profile → same canonical analysis.
These are considerations, not impossibilities: generated JSON can be canonicalized, caching is always possible, and any vendor could commit to output identity contractually. The practical question is whether a vendor's published terms commit to it - what to compare across vendors.
SECTION 7
5,000 analyzer runs per month. No credit card. No sales call.
Get an API key in 60 seconds. Run the determinism test in your own environment. Verify the guarantee with your own inputs.
Already convinced? See pricing → - every plan includes deterministic outputs, no submitted-content retention, no training on submitted content.
The API fingerprint (verification.fingerprint) is a truncated SHA-256 over the RFC 8785 canonical analysis payload (analyzers, configuration, language, outcomes, signals). The submitted text is bound separately via the caller-keyed verification.input_commitment. Volatile fields like latency_ms and request_id are excluded - they may differ between identical calls; the fingerprint cannot. The comparison loop in Section 4 is the full methodology: same input, repeated calls, hash each response, count uniques - run it against any provider with your own credentials and judge the results yourself. A receipt attests to what Sentiqra produced; it is not proof that a classification is true.