Trust should travel with the record.

Once a record leaves its issuing institution, trust is often rebuilt through calls, emails, registry searches, or checks that can be skipped. ANANKE is built to give authorized verifiers the evidence they need without recreating that process for every request.

Nine questions. A single checkmark is not enough.

Every meaningful verification interaction needs answers to all nine of these. Most approaches address one or two.

Question	Lookup / plain QR	ANANKE
Does this record exist? The baseline — answered by most lookup approaches.	Often	Yes
Was it created by the actual issuer? Requires authenticated issuer identity, not just a URL.	Rarely	Yes
Has the content changed since issuance? Requires cryptographic binding between the content and the record.	No	Yes
Does the presented evidence match what the issuer protected? For a digital original, this can cover the exact artifact. For printed records, verification covers protected fields or a configured digital-twin comparison.	No	Yes
Is the record still active — not revoked, suspended, or expired? Requires a live, authoritative lifecycle state — not a stale database snapshot.	Sometimes	Yes
Is the person presenting it entitled to use it? Partial — ANANKE provides context but cannot verify physical identity.	No	Partial
Is there relevant context about why this record was issued? Structured metadata: issuer, date, programme, valid period.	No	Yes
Would changes within the protected scope be detectable? Requires integrity evidence bound to the protected artifact, payload, or fields — not just a URL.	No	Yes
Does it satisfy the requirements of this specific context? Partial — ANANKE provides evidence; compliance interpretation is the verifier's role.	No	Partial

Does this record exist?

The baseline — answered by most lookup approaches.

Lookup / plain QR

ANANKE

Was it created by the actual issuer?

Requires authenticated issuer identity, not just a URL.

Lookup / plain QR

ANANKE

Has the content changed since issuance?

Requires cryptographic binding between the content and the record.

Lookup / plain QR

ANANKE

Does the presented evidence match what the issuer protected?

For a digital original, this can cover the exact artifact. For printed records, verification covers protected fields or a configured digital-twin comparison.

Lookup / plain QR

ANANKE

Is the record still active — not revoked, suspended, or expired?

Requires a live, authoritative lifecycle state — not a stale database snapshot.

Lookup / plain QR

ANANKE

Is the person presenting it entitled to use it?

Partial — ANANKE provides context but cannot verify physical identity.

Lookup / plain QR

ANANKE

Is there relevant context about why this record was issued?

Structured metadata: issuer, date, programme, valid period.

Lookup / plain QR

ANANKE

Would changes within the protected scope be detectable?

Requires integrity evidence bound to the protected artifact, payload, or fields — not just a URL.

Lookup / plain QR

ANANKE

Does it satisfy the requirements of this specific context?

Partial — ANANKE provides evidence; compliance interpretation is the verifier's role.

Lookup / plain QR

ANANKE

Why existing approaches leave gaps.

Different verification approaches address different threats and leave others open. Here are the most common ones used in institutional document verification.

Visual / manual inspection

Whether the document looks authentic at first glance

Cannot detect digital alterations, verify current status, or confirm the issuer's identity

Manual issuer confirmation

The issuer has a matching record — at the moment of the call

Slow, not scalable, gives no tamper evidence, and the caller cannot verify they reached the real issuer

QR / URL pointing to a lookup page

A code opens a page or reference

The result may not be bound to the record being presented. A copied code, altered document, or lookalike portal can still mislead the verifier

QR with opaque reference to a database record

A reference ID matches a database entry

The reference can be copied onto a different document; the resolver is a single point of failure and trust

Hash registry / file-upload comparison

This file's hash matches a stored hash

Proves the file is unchanged — not that the original was legitimate or that it is still active

Digitally signed PDF

The PDF content was signed by the key at signing time

Printing destroys the cryptographic mechanism; cannot verify current lifecycle status after signing

Signed 2D barcode (traditional)

The encoded fields were signed — offline-capable

Only the encoded fields are protected; additional document content is unprotected

Transparency logs / distributed ledger

A hash was appended to an append-only log

Proves the hash was recorded — not that the original content was truthful or that the record is still authoritative

ANANKE separates who can create a record from who gets to decide what the current authoritative truth is.

A QR code, URL, or barcode can make verification convenient, but it is only a carrier. ANANKE binds protected evidence to the record and returns its current lifecycle status through a shared infrastructure layer for issuers and authorized verifiers.

Eight layers. Each closes a specific gap.

ANANKE Trust and T-CODE are built on a shared infrastructure. Each layer addresses a weakness that simpler approaches leave open.

Layer	Closes	How
Authoritative lifecycle chain	Stale-but-valid results	Every status change (issue, suspend, revoke, reactivate, replace) is an authoritative event — verifiers query the live chain, not a database snapshot
Consistent content fingerprint	Mismatched interpretation across environments	Content is standardized before the fingerprint is computed — the same text always produces the same cryptographic fingerprint regardless of formatting or encoding
Protected integrity evidence	Insider-tampering and hash-recompute attacks	Evidence is computed using keys held outside the product database — modifying the record requires access to both, raising the cost of undetected tampering
Linked event history	Quietly deleting or reordering history	Each lifecycle event references the previous — gaps or reordering break the chain and are detectable at verification time
Current-version check	Presenting old, since-superseded records as current	Verifiers confirm not just that a record exists, but that this is the current active version — not a superseded or replaced record
Continuous integrity monitoring	Tampering that sits undetected until verification	Integrity evidence is checked continuously — not only at the moment a verifier requests it
External accountability evidence	Rewriting history using a compromised platform alone	Audit records are published on external registries outside our platform — compromising our infrastructure alone is not enough to silently rewrite the history
Structured verifier response	The misleading single green checkmark	Verifiers receive a structured result: issuer authenticated, content integrity confirmed, lifecycle state, context metadata — not a binary pass/fail

Authoritative lifecycle chain

Closes

Stale-but-valid results

How

Every status change (issue, suspend, revoke, reactivate, replace) is an authoritative event — verifiers query the live chain, not a database snapshot

Consistent content fingerprint

Closes

Mismatched interpretation across environments

How

Content is standardized before the fingerprint is computed — the same text always produces the same cryptographic fingerprint regardless of formatting or encoding

Protected integrity evidence

Closes

Insider-tampering and hash-recompute attacks

How

Evidence is computed using keys held outside the product database — modifying the record requires access to both, raising the cost of undetected tampering

Linked event history

Closes

Quietly deleting or reordering history

How

Each lifecycle event references the previous — gaps or reordering break the chain and are detectable at verification time

Current-version check

Closes

Presenting old, since-superseded records as current

How

Verifiers confirm not just that a record exists, but that this is the current active version — not a superseded or replaced record

Continuous integrity monitoring

Closes

Tampering that sits undetected until verification

How

Integrity evidence is checked continuously — not only at the moment a verifier requests it

External accountability evidence

Closes

Rewriting history using a compromised platform alone

How

Audit records are published on external registries outside our platform — compromising our infrastructure alone is not enough to silently rewrite the history

Structured verifier response

Closes

The misleading single green checkmark

How

Verifiers receive a structured result: issuer authenticated, content integrity confirmed, lifecycle state, context metadata — not a binary pass/fail

Trust and T-CODE share the same infrastructure.

ANANKE Trust handles digital records and PDFs. ANANKE T-CODE connects physical and printable documents to the same evidence layer through a secure DataMatrix marker. Both share the same trust foundation, while the verification result remains specific to the artifact and verification mode.

ANANKE Trust

Digital records and PDF documents — issued, protected, and verified through ANANKE's trust layer.

Explore Trust →

ANANKE T-CODE

Physical and printable documents — connected to the digital evidence layer through a T-DOC DataMatrix stamp. Scan to verify protected evidence and current status.

Explore T-CODE →

What this does not solve.

ANANKE is designed to reduce the risk of specific classes of attack. It does not eliminate all possible threats. Here is what remains outside the model.

Issuer honesty

ANANKE cannot verify that an authorized issuer was being truthful when they created the record. We can verify that the record was created by an authenticated issuer — not that the issuer's claims were accurate.

High-privilege account compromise

A compromised high-privilege issuer account can create legitimate-looking records until detected and revoked. ANANKE provides audit trails that support detection — not prevention.

Stolen signing key

An actively compromised signing key can produce valid-looking evidence until it is detected and the key is rotated. Key management discipline is a prerequisite — ANANKE does not replace it.

Perfect physical clones

An exact physical photocopy of a T-CODE document can pass a visual check. Digital verification can confirm protected evidence, but cannot by itself distinguish an original physical copy from a perfect clone.

Offline is bounded assurance

Offline T-CODE verification confirms that encoded fields are cryptographically valid. It does not confirm current lifecycle status — that requires a live authoritative check.

Who is this for?

ANANKE serves different audiences at different stages of evaluation. Find the path that fits your role.

Institutions & Issuers

Universities, banks, certification bodies — organizations that issue documents and need their recipients to be able to verify them.

Discuss a pilot

Developers & Integrators

Engineering teams planning document workflows who want to discuss Integration Layer and REST API access at launch.

Explore the API

Security reviewers

Technical evaluators assessing the threat model, key management approach, and architectural constraints before recommending adoption.

Read the security architecture

Investors & Evaluators

Investors and ecosystem evaluators assessing the differentiation thesis, market timing, and architectural moat.

About ANANKE Labs