Determinism Guarantee

A deterministic system produces a byte-identical analysis payload for identical input under the same pinned configuration and output profile - not "similar" or "statistically consistent." Volatile operational metadata (request IDs, timestamps, latency) may differ; the detection result cannot. Sentiqra guarantees this by construction: pinned configurations use a deterministic analysis path with no generative model, no stochastic sampling, and no model state that changes between requests.

Every successful detection response includes a verification.fingerprint field - a truncated SHA-256 hash of the RFC 8785 canonical serialization of the analysis payload (analyzers, outcomes, signals, language, and configuration). Send the same input twice under the same pinned configuration and the same output profile, and both responses carry the same fingerprint. (The emitted signal rows differ between the full.v1 and reduced.v1 profiles - banded scores and a capped signal count are different canonical payloads - so a receipt's fingerprint is profile-specific.) It is independently reproducible by anyone, at any time, without trusting Sentiqra.

Specification versions

Receipts are versioned. The version is identified by the commitment prefix (ic3_ vs ic2_ vs ic_) and echoed in verification.version. Version 3 is the current spec; earlier versions remain verifiable for receipts issued under them.

v3 changes only the input commitment: it keys off an HKDF-derived binding key rather than the raw API credential, so historical verification no longer depends on retaining an authentication secret (see input binding). The fingerprint payload and signature rule are unchanged - a v2 and v3 receipt over the same canonical payload carry the same fp2_. v2 and v1 receipts are not reissued - submit them to POST /v1/verify, which accepts all versions.

1. Canonical payload (v2)

The fingerprint covers the analysis decision only - the requested analyzer set, each analyzer's completion outcome, the emitted signals, the language, and the configuration. The submitted text is deliberately excluded (see input binding below), as is volatile operational metadata.

Fields hashed (exact set - anything else is rejected)

• → analyzers - the requested analyzer slugs, sorted lexicographically before hashing (array order is not significant)
• → configuration - the scoped configuration alias that produced the result (e.g. sqcfg_ZZW77NM9)
• → language - the analysis language
• → outcomes - map of analyzer slug → completed | failed | overloaded | not_applicable, one entry per requested analyzer (from meta.analyzers)
• → signals - the signal objects exactly as emitted in the response (every field of every row, in response order)

Excluded from fingerprint

• × text - the submitted input (bound separately via input_commitment)
• × meta fields other than analyzer outcomes, usage - latency and billing metadata
• × verification - the receipt itself (contains the fingerprint; circular dependency)
• × request_id, latency, timestamps - volatile operational metadata

Because outcomes is authenticated, an empty signals array is unambiguous: {"trust-safety":"completed"} with no signals fingerprints differently from {"trust-safety":"failed"} - "completed with no signals" can never be confused with "never completed." Scores are authenticated fields, not derived: the emitted score (and any confidence band in reduced responses) is hashed verbatim, so tampering with a score fails fingerprint verification.

Every 2xx analysis response carries a receipt, including a response where every requested analyzer reported not_applicable - the outcomes map binds each analyzer's status, so "valid request, nothing applicable ran" is itself a signed, replayable result distinct from any execution.

2. Serialization - RFC 8785 (JCS)

The payload is serialized to a single canonical byte sequence per RFC 8785, JSON Canonicalization Scheme. Any conformant JCS implementation in any language produces identical bytes:

• → Object keys sorted lexicographically by UTF-16 code units; arrays keep their order
• → No insignificant whitespace; strings in UTF-8 with minimal escaping (only \b \t \n \f \r \" \\ and control characters < 0x20 escaped)
• → Numbers encoded per ECMAScript Number::toString - 1.0 becomes 1, 1e-7 becomes 1e-7, 0.30000000000000004 keeps its shortest round-trip form

// Example hashed payload (v2) - canonical bytes actually hashed:
{"analyzers":["trust-safety"],"configuration":"sqcfg_ZZW77NM9","language":"en","outcomes":{"trust-safety":"completed"},"signals":[{"analyzer":"trust-safety","code":"insults_derogation","label":"Insults & Derogation","score":0.86,"level":"category"},{"analyzer":"trust-safety","code":"insult","label":"Insult","score":0.99,"level":"label","parent":"insults_derogation"},{"analyzer":"trust-safety","code":"belittling","label":"Belittling","score":0.99,"level":"label","parent":"insults_derogation"}]}

3. Digest, commitment, signature

• → Fingerprint = "fp2_" + hex(SHA-256(canonical_payload)[0:16]) - 16-byte truncation, 32 lowercase hex chars. Identical in v2 and v3 over the same payload.
• → Binding key (v3) = "bk_" + hex(HKDF-SHA256(IKM = UTF-8(API credential), salt = absent, info = "sentiqra/input-binding/v3", L = 32)) - derived once, purpose-separated, kept in your vault. It verifies input commitments but can never authenticate requests.
• → Input commitment (v3) = "ic3_" + hex(HMAC-SHA256(key = binding_key, JCS({"language":lang,"text":text}))[0:16]) - same truncation as v2, keyed by the derived binding key.
• → binding_key_id (v3) = "bk_" + hex(SHA-256(binding_key)[0:8]) - the opaque identifier on the receipt; selects the right vault entry without revealing which credential derived it.
• → Signature = "sig_ed25519_" + hex(Ed25519_sign(ASCII(fingerprint + "|" + input_commitment))) - the signed message is the two values joined by a literal |; independently verifiable offline with the published public key.

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 reproduce

Complete worked example - v3 vector from the published set (values are complete, signed with the public development key):

// Canonical payload bytes (JCS):
{"analyzers":["trust-safety"],"configuration":"sqcfg_TESTVCT0","language":"en","outcomes":{"trust-safety":"completed"},"signals":[{"analyzer":"trust-safety","label":"Insults & Derogation","score":0.93,"type":"insults_derogation"}]}

fingerprint      = fp2_b6e445c291ed0a4ab6a89b854f4adfcb
binding_key      = bk_720b80b4cfb315b880c5d8fb4b9d3b4bed13e74086ff8b7c50f65b33aaa46264  // HKDF("sq_live_vector_key")
binding_key_id   = bk_bc54a32479185739
input_commitment = ic3_e4b7fb90768764c6ccc3a1d635062c27  // text "you are a worthless idiot"
signed message   = "fp2_b6e445c291ed0a4ab6a89b854f4adfcb|ic3_e4b7fb90768764c6ccc3a1d635062c27"
signature        = sig_ed25519_409782bb75344f91ef78dac56cfffc23c8d2b1cdf3d78c7111b8bf70457816318aede14948c06ef10f1c91e5f5f7e323d98e700f512048712f6ba4fe27d54401
key_id           = edk_56475aa7  // development key - production receipts carry the live key_id

All seven vectors (v3 and preserved v2: partial failure, empty signals, not_applicable outcome, non-ASCII input, score edge encodings) are published in receipt-test-vectors.json and embedded in the standalone verifier - a single-file WebCrypto implementation you can download and run offline to cross-check your own implementation.

4. Malformed-data rejection

Verification rejects a payload rather than silently normalizing it - normalization would let a tampered payload still match. POST /v1/verify reports each check independently:

• → signature_valid - Ed25519 verification over fp|ic with the published key
• → fingerprint_match - recomputed fp2_ over the submitted payload equals the receipt's
• → input_commitment - recomputed over {language, text} with the submitted key material (ic3_: API credential or bk_ binding key; ic2_/ic_: raw credential)

Rejected as malformed (no partial verification)

• × Any top-level field outside {analyzers, configuration, language, outcomes, signals}
• × Empty or non-string analyzer entries; outcome values outside completed|failed|overloaded|not_applicable
• × Signal rows missing label (string) or score (finite number); NaN/Infinity can never appear (unencodable in JCS)
• × Unknown fingerprint prefix - only fp2_ (v2) and fp_ (v1) are recognized

Signal fields beyond the mandatory pair (analyzer, code, level, parent, confidence) are hashed, not dropped - extra fields change the fingerprint, so appended data cannot hide tampering.

The fingerprint intentionally excludes timestamps and request IDs — that is what makes it stable. But a stable fingerprint is result identity, not event evidence: an identical fingerprint on two occasions proves the same input produced the same result under the same configuration and output profile. It does not prove a unique transaction, a submission time, or any action taken afterward.

When you need "this specific analysis was bound to an event," mint an event record — a separately versioned (sentiqra/event/v1), signed object issued on demand:

POST /v1/event
{
  "receipt":  { "fingerprint": "fp2_…", "input_commitment": "ic3_…",
                "signature": "sig_ed25519_…", "key_id": "…", "configuration": "…" },
  "scope":    "tenant:acme/support-queue",     
  "customer": { "policy_version": "policy-2026-09",
                "action": "queue_review", "reference": "case-1234" }
}

The minted record carries a fresh event_id (random per issuance — identical receipts mint distinct IDs), the bound receipt, your scope, issued_at, an opaque issued_to marker derived from your credential, a digest over the signed core, and an Ed25519 signature from the same key family as receipts. Minting only binds authentic receipts — a forged fingerprint or signature is rejected.

• → The customer block is declared, not attested. Your policy version and action are signed into the record — proving what you asserted at issuance — but Sentiqra does not observe actions performed in your systems.
• → issued_at is signer-supplied. It records when Sentiqra issued the binding. For independent proof-of-existence by a particular time, timestamp the record's digest with an RFC 3161 timestamp authority — a TSA's signed token is a different assurance than the issuer's own clock.
• → POST /v1/verify/event reports the four dimensions separately: result integrity (bound receipt signature), event identity (record signature + unique event ID), input binding (caller-keyed commitment), and timestamp assurance (none / signer-asserted / RFC 3161 with digest-match).

curl -O https://sentiqra.tech/eval-toolkit/sentiqra-event.py
python3 sentiqra-event.py mint --receipt receipt.json --scope "tenant:acme/queue-7" --customer ctx.json
python3 sentiqra-event.py timestamp --record event.json --tsa <rfc3161-tsa-url>   # openssl ts
python3 sentiqra-event.py verify --record event.json --cafile tsa-ca.pem

Configuration pinning

Can you pin the complete analysis behavior to an immutable identifier - and does the vendor commit to output identity under it? Pinning a prompt or model name constrains inputs to the model; it does not by itself commit to identical output.

Historical replay availability

Can you re-run last quarter's input against the exact configuration that produced the original result? Check the vendor's documented deprecation windows - pinned versions are often available only for a limited period.

Output semantics

Do output identifiers carry stable, versioned meaning tied to a documented taxonomy - or labels whose interpretation depends on the prompt and model revision that produced them?

Verification tooling

Does the vendor return a reproducible result identity - a fingerprint or hash over the analysis payload - plus a signature you can verify offline, or a response you can only store?

Lifecycle guarantees

Is there a published support policy covering how long a pinned version stays available, what notice precedes changes, and whether fixes create new versions rather than silently altering existing ones?

A configuration ID identifies a complete version of analysis behavior - not a model version alone. Reproducibility depends on every element that can change a result, so the ID is backed by private release evidence covering all of it; what those elements are is not part of the public contract. What the ID guarantees publicly:

• → Equality condition: the same accepted input under the same configuration ID, language, analyzer set, and output profile produces the same canonical result while the configuration is in a supported lifecycle state.
• → Immutability: a change to any covered element produces a new configuration ID - never an edit to an existing one.
• → Explicit failure: an unsupported, retired, unknown, out-of-scope, or suspended pin fails the request with a documented error - a different configuration is never silently substituted (see the lifecycle and error table above).

The backing record is an operational artifact, not a public document - it exists so that "the same ID" provably means the same behavior. A request either executes the supported configuration the caller specified or returns a documented error; there is no third outcome.

Runtime enforcement - fail closed, not fail silent

A deployment serves a configuration only under an ID whose behavior it can reproduce exactly. If the behavior the runtime would produce does not match what the deployed configuration's ID promises - because an artifact, a dependency, or the execution environment moved outside the validated scope - the runtime refuses to serve that configuration rather than silently substituting behavior under an existing ID. A runtime or library upgrade may keep an existing configuration ID only after identical behavior is demonstrated within the promised execution scope; otherwise it is served under a new ID.

Reproducibility is additionally evidenced by a test matrix run per deployment environment: repeat calls, segmented inputs, concurrent execution, restarts, boundary-adjacent scores, and tied rankings are checked for byte-identical canonical output. The reports are retained as release evidence - they record scope, environment, and results so the guarantee is measured, not assumed.

Scope of the guarantee

The byte-identical promise applies within the configuration's stated execution scope:

• → Covered: the canonical analysis payload - the fields the fingerprint hashes - on validated platforms and runtimes.
• × Not covered: volatile operational metadata (request IDs, timestamps, latency, ordering of unrelated response metadata), and environments outside the validated scope. Byte-identity across platforms is claimed only where a reproducibility report records it.

A configuration pins behavior, not a permanently running build. If a dependency, runtime, or deployment component serving a configuration becomes unsafe, execution of the affected scope can be suspended under a confirmed security incident - requests fail explicitly with configuration_suspended and no different detector answers in its place. Execution resumes only after the patched build proves identical behavior through the compatibility-attestation path; verification of existing receipts is cryptographic and never depends on the suspended execution path.