Zero-Data-Access Evidence Architecture

What Signatrust provides

What Signatrust does not claim

• Correctness — a signed receipt does not prove the underlying decision was right.
• Fairness — cryptography cannot decide whether a decision was fair.
• Legal compliance — policy binding proves a reference, not lawfulness.
• Real-world completeness — coverage is declared by DBD/DEP, not by us.

Architecture at a glance

Customer Environment
    ↓ raw input/output stays local
Local Hashing (SHA-256 profile)
    ↓
Sector Schema
    ↓
Deployment Evidence Profile
    ↓
Decision or Action Event
    ↓
Evidence Composition
    ↓ input/output commitments · DBD · policy bindings
      human-review commitment · attestations · metadata
Canonical Signed Body
    ↓ SHA-256 → receipt_hash
    ↓ Ed25519 → signature
Decision Receipt
    ↓
Ledger Epoch (append-only, epoch-anchored)
    ↓
Online Verification  /  Offline Verification
Trust Bundle · Historical Keys · Recovery Manifest

Detailed sections follow. Each system property in the status matrix declares whether it is IMPLEMENTED, DOCUMENTED, RESEARCH, or FUTURE — no hidden limitations.

1. Framing

Signatrust is an Evidence Architecture. It is not:

• an AI Governance platform
• an AI auditor
• an AI judge
• an AI correctness validator
• a fairness engine
• an explainability framework
• a legal certification system

The single research premise:

Can AI decisions be accompanied by cryptographically verifiable evidence that enables independent verification without requiring trust in the party that issued the receipt, and without requiring that party (Signatrust) to receive or retain the underlying raw decision content or direct subject identity?

Signatrust protects the evidence that describes a decision. It does not prove that the decision itself was correct, fair, lawful, complete, safe, or free from bias.

2. Zero-Data-Access, not Zero-Knowledge

We deliberately do not use the term Zero-Knowledge Architecture. "Zero-Knowledge" is a well-defined term in cryptography (ZKP) with a specific meaning that we do not implement.

The property Signatrust does provide is:

Signatrust is designed so that cryptographic evidence can be generated and verified without requiring Signatrust to receive or retain the underlying raw decision content or direct subject identity.

We call this Zero-Data-Access Evidence Architecture. The engineering objective is: verify without unnecessary disclosure.

3. End-to-end data flow

The target model (already implemented in the JavaScript and Python SDKs):

Customer Environment
        │
        │  raw input
        │  raw output
        │  subject / patient / customer identity
        │  raw prompts, model output, PII, PHI, PAN, medical record
        ▼
Local Signatrust SDK
        │
        │  local SHA-256 hashing (hashLocally: true is the default)
        ▼
input_hash    (sha256:<hex>)
output_hash   (sha256:<hex>)
metadata required for evidence (business_event, risk_level, permissions)
optional scope_declaration (Decision Boundary Disclosure)
        │
        │  HTTPS → /api/v1/receipts
        ▼
Signatrust Evidence Service
        │
        │  RFC 8785–style deterministic canonicalization
        │  receipt_hash = SHA-256(canonical(body))
        │  Ed25519 signature over receipt_hash
        │  chain linkage to previous_hash
        ▼
Decision Receipt (signed, chained)
        │
        ▼
Receipt ID returned to customer
        │
        ▼
Customer stores Receipt ID in their own system
alongside their internal Patient / Case / Transaction record.

The customer's internal system holds the mapping Subject → Receipt ID. Signatrust does not need — and by design does not receive — that mapping.

4. What Signatrust does not receive by default

Under the data-minimized default (SDK hashLocally: true), the following never leave the customer's environment:

• Raw model prompt / raw model output
• Patient name, medical record, diagnosis text
• Customer name (of the customer's own end-customer), phone, address
• Email addresses of decision subjects
• Banking details, PAN / card details
• Full application content (loan, insurance, employment)
• Personally identifying case content

What Signatrust does receive is limited to:

• input_hash and output_hash (SHA-256 commitments)
• Non-sensitive decision metadata: business_event, risk_level, human_review (boolean), optional human_review_attestation_hash (SHA-256 commitment to reviewer identity/specialty; the reviewer's actual name and role never travel to Signatrust), permissions, policies, optional scope_declaration
• Agent identity (the system that made the decision, not the subject of the decision)
• Model provider/name/version (if the customer chooses to disclose)
• Optional metadata chosen by the customer (customer decides what to include)

Note. Any regulatory scope (GDPR, HIPAA, PCI-DSS, DNB) depends on the deployment and applicable legal context. Data-minimization is an engineering property of the receipt payload and not, on its own, a certification claim.

5. Local hashing contract

Local hashing is a first-class, documented pathway in both official SDKs.

• Algorithm: SHA-256 (FIPS 180-4).
• Encoding: UTF-8 bytes of the string content.
• Serialization: the caller passes a string; if the payload is a structured value the caller is responsible for producing a stable string encoding (typically JSON.stringify with fixed key ordering, or a canonicalizer).
• Wire format: hashes are transmitted as sha256:<lowercase-hex> (the prefix identifies the algorithm so future algorithm agility does not silently mis-verify).
• Recomputation: feeding the same original content through the same SDK produces the same sha256:<hex>. Recomputation later — even years later — must produce a byte-identical fingerprint to match the historical commitment.

SDK reference:

// TypeScript / JavaScript SDK
const str = new Signatrust({ apiKey: process.env.SIGNATRUST_API_KEY });
// hashLocally defaults to true — the following two lines do NOT send raw content
const receipt = await str.sign({
  decision: {
    type: 'loan_rejection',
    input: sensitivePrompt,
    output: sensitiveModelOutput,
    business_event: 'CREDIT_DECISION',
    risk_level: 'high',
  },
});
// Also available: pre-computed hashes
const receipt2 = await str.sign({
  decision: {
    input_hash:  Signatrust.fingerprint(sensitivePrompt),
    output_hash: Signatrust.fingerprint(sensitiveModelOutput),
    business_event: 'CREDIT_DECISION',
  },
});

6. What a Receipt contains

The signed body of a Decision Receipt includes only:

• version, id, type, sequence, timestamp
• agent — the issuing system, not the subject
• model — provider/name/version (optional)
• decision — input_hash, output_hash, business_event, risk_level, human_review, human_review_attestation_hash (optional), permissions, policies
• scope_declaration — Decision Boundary Disclosure (optional, sector-schema-pinned)
• metadata — customer-chosen non-sensitive attributes
• previous_hash — link into the append-only chain

Attached to (but not part of) the signable body:

• receipt_hash — SHA-256 of the canonicalized body
• signature.algorithm — ed25519
• signature.public_key — base64 SPKI/DER of the Ed25519 verification key, embedded in the receipt for immediate self-contained verification
• signature.value — the Ed25519 signature over receipt_hash

A separate signature.key_id field for explicit historical-resolution / rotation is on the research list — see LONG_TERM_VERIFICATION_AND_CRYPTO_AGILITY.md. Today the embedded public key already lets an offline verifier check the signature; long-term rotation and revocation are handled through the external trust bundle rather than a receipt-side identifier.

The SDK returns to the customer:

{
  "receipt": { ... },
  "verify_url": "https://signatrust.net/api/v1/receipts/STR-.../verify",
  "share_url":  "https://signatrust.net/verify?id=STR-..."
}

7. Storing Receipt References in Your Own System

Signatrust does not maintain a central patient / customer discovery index. The subject identity belongs to the customer's domain; the evidence identity belongs to the Signatrust evidence domain.

The recommended pattern for any sector — healthcare, credit, insurance, employment, government benefits, industrial safety — is symmetric:

Customer Internal System
──────────────────────────────────────────────
Internal Subject ID   84721
Case / Encounter ID   E-2027-551
AI Decisions
    receipt_id: STR-A1B2C3...
    receipt_id: STR-D4E5F6...
    receipt_id: STR-G7H8I9...

Do not send Patient 84721 to Signatrust merely to locate a Receipt later. The customer's own system is the discovery layer.

Sector examples (all follow the same pattern):

Both SDKs ship with a small, dependency-free ReceiptReferenceStore helper that persists these rows locally with restrictive permissions and offers attach, findBySubject, findByCase, and findByReceiptId. It's optional — most customers plug the same fields into their existing record system — but it gives a working reference for the exact multi-year retrieval story: Storing Receipt References in Your Own System →

8. Discovery vs Verification

These functions are deliberately separated. Signatrust never merges them into a "receipt lookup by patient name" API.

9. Decision Boundary Disclosure (DBD)

DBD is an independent architectural feature that pins each receipt to a versioned sector schema and declares, per receipt:

• domains_evaluated — the schema domains the system actually considered
• domains_excluded — the schema domains the system did not consider, with a machine-readable reason and excluded_by classification

The server enforces a hard union rule:

domains_evaluated ∪ domains_excluded = all domains defined by the referenced sector schema.

If any schema domain is present in neither list, the server refuses to sign. This eliminates silent omission: a developer must actively say not evaluated — they cannot leave a domain out and hope nobody notices.

DBD data is part of the signed envelope:

scope_declaration → canonicalization → receipt_hash → Ed25519 signature

Tampering with domains_excluded after signing breaks verification.

DBD does not prove:

• that every factor relevant in reality was considered — only every factor in this version of this schema was addressed;
• that the evaluation of any given domain was correct — only that the domain was reported to have been evaluated;
• that the sector schema itself is complete or fair — the schema is a living, versioned, human-authored artifact.

10. Integrity ≠ Correctness

The single most important boundary in this project:

Decision Integrity ≠ Decision Correctness.

Cryptographic verification of a Signatrust receipt can prove:

• the receipt was signed by the stated key,
• the signed body has not been altered since,
• the receipt is properly linked into the append-only chain.

It cannot prove that the underlying AI decision was:

• correct
• fair or unbiased
• lawful under a specific jurisdiction
• medically, financially, or ethically safe
• complete with respect to reality

The verification page makes this boundary explicit in the result panel.

11. Completeness (open research)

Hash chaining and signing prove that a given receipt has not been altered and is linked to its predecessors. They do not automatically prove that the issuing organization submitted every relevant decision — the receipts we can see are only the ones we were shown.

We treat selective omission / completeness verification as an open research question. It is not implemented and is not claimed as a property of the current system.

12. Long-term retention

A receipt carries what it needs for later verification: schema version, algorithm identifier (ed25519), signing public key, chain identifier, timestamp, receipt hash, signature, and previous hash. However, long-term verification also depends on infrastructure we have not yet productionised: an archived public-key registry, a key-rotation history, and versioned canonicalization profiles. We are aware of the dependency and are not claiming it is solved.

13. Architecture status matrix

Each capability is placed in exactly one status category. Categories are:

• IMPLEMENTED — present in production code and covered by tests;
• DOCUMENTED — designed and specified but not fully proven end-to-end;
• RESEARCH — open question or active study;
• FUTURE — on the roadmap, not started.

14. Open research questions

1. Completeness verification. How does an external verifier detect selective omission of receipts by a cooperating issuer?
2. Horizontal write scaling across hosts. The current write path is safe under concurrent processes on a single host via a filesystem advisory lock. Extending safe append across multiple hosts (each with its own writer) requires an external sequencer — a Postgres advisory lock, a Redis SETNX pattern with fencing tokens, or a consensus system such as etcd/Raft. The right choice depends on the deployment's failure model and is deliberately deferred rather than implemented pre-maturely.
3. Long-term key resolution. How is a receipt signed under a key that has since been rotated verified five, ten, or twenty years later, without either party trusting a central registry unconditionally?
4. Post-quantum migration. What is the transition strategy from Ed25519 to a hybrid or PQ-only signature envelope that preserves verifiability of receipts issued under legacy algorithms?
5. Runtime attestation. How does a receipt bind to evidence that a specific model version, running on a specific execution environment, actually produced the output the hash covers?
6. Sector-schema governance. Who authors and versions sector schemas so that coverage_classification: full carries external meaning across organisations?
7. Canonicalization conformance. Formal test suite proving byte-for-byte agreement with RFC 8785 across all JSON edge cases (numeric edge cases, string escape edge cases, key ordering with Unicode code points).

These questions define our research agenda. They are deliberately not solved by adding claims to the marketing site.