How not.bot Compares to Alternatives: An Evaluation Framework

Updated July 8, 2026

How to compare not.bot™ to the alternatives, and how to evaluate any of them, across the categories described in "The field" below. Names no companies. Defines the criteria any buyer can apply to any vendor, including not.bot™, to see where the products differ.

This framework is written for the buyer: the organization evaluating or deploying a system that verifies humans. It refers to the vendor (who sells the system), the operator (whoever runs the deployment, which is the buyer in a self-hosted model and the vendor in a cloud one), the user (the human being verified), and the verifier (whoever checks a proof at the point of use, often the buyer's own site and sometimes a third party).

Last Updated July 2026.

Changelog, July 2026. Added six field categories (platform and OS-level verification, government digital identity, reusable age networks, self-hosted identity engines, agent identity and delegation, verified-agent admission); sharpened the deployment-model criterion (10); upgraded cross-site linkability (5) to the recognition trilemma; extended sybil resistance (6), age assurance (7), reach of use (9), adoption risk (14), and operational assurance (15); added three criteria: population coverage (16), agent readiness (17), and rails interoperability (18); added the summary matrix.

The field

The products a buyer weighs against not.bot fall into fourteen kinds, each sought for a different benefit:

• Bot detection. Keep automated traffic off a service, so real users get through and scripts do not, at scale and with little friction for the user.
• Document-and-selfie verification. Onboard a named customer by confirming a real person matches a real government ID, for cases that need a known individual on file.
• Facial age estimation. Clear users past an age gate from a face alone, with no document to upload and little friction.
• Proof of personhood. Establish one unique human per account — so bans stick to a person rather than an account, reviews and votes count once, and one-per-person offers go to one person each — without collecting a name.
• Federated and platform identity. Let users sign in with an account they already hold, for fast onboarding and fewer credentials to manage.
• Content authenticity. Carry a file's origin and edit history with it, so a viewer can see where a photo, video, or document came from.
• Deepfake detection. Screen incoming media for signs of manipulation before a buyer trusts or publishes it.
• Decentralized identity infrastructure. Issue and check credentials on open standards, for a portable identity layer a buyer can build on without locking into one vendor.
• Platform and OS-level verification. Accept an age range or a document attestation asserted by the phone's operating system or the browser — free, already installed on the user's device, and increasingly what app-store and age-verification laws are satisfied with.
• Government digital identity. Accept identity and age attestations presented directly from a state-issued wallet or mobile driver's license — the highest-authority issuer at zero price, arriving on legal mandates.
• Reusable age networks. Let users verify age once with any member provider, hold a token, and assert it across participating services — age assurance decoupled from any single check.
• Self-hosted identity engines. License document, biometric, and deduplication software and run it entirely in the buyer's own infrastructure — vendor-blind by construction, with the buyer operating the resulting identity database.
• Agent identity and delegation. Give AI agents verifiable identities, scoped authority, and audit trails — and, in some designs, a chain of accountability back to a human.
• Verified-agent admission. Let legitimate automation identify itself cryptographically, so a service can admit good agents rather than gate everything for humans — the inverse of proof of personhood, and increasingly the other half of the same buying decision.

A buyer's obligations often reach across more than one of these, and the categories themselves overlap: buyers increasingly assemble layered stacks — an OS-level age signal here, a document check there, bot detection in front of everything — and the criteria apply per layer. The criteria below apply the same questions to every category, not.bot included.

I. What the verification is built on

1. Trust anchor

"What is the root of trust, and how strong is it?"

The issue. Every verification system roots its trust in something it treats as hard to forge, and the choice decides what can fool the system and what it can never check. The anchors in use:

• A biometric pattern. A face or iris. Implication: proves a live body showed up, not who that body is in any civil record, and ties the user to a stored biometric template the system must then hold and protect.
• A document image. A photo of an ID. Implication: proves a credential was photographed, not that the holder is its subject; a clear photo of someone else's document or a good AI-generated fake can pass.
• A behavioral signal. Interaction patterns. Implication: cheap and frictionless, but it never establishes identity and weakens as bots improve.
• A federated account. Sign-in from a large provider. Implication: inherits whatever the upstream provider checked, which may be nothing, and puts that provider in the loop.
• A hardware token. A device key. Implication: proves possession of a device, not of a person; whoever holds the device passes.
• A government-issued chip. The signed chip in a passport or ID. Implication: carries the issuing authority's signature and ties the credential back to a person that authority vouches for, the strongest anchor, and it requires the user to hold such a document.

The strength question is whether the anchor reaches an authority that stands behind a real person, or only an artifact that can be copied, estimated, or inherited.

not.bot's position. not.bot anchors trust in the government-signed chip of a passport. At enrollment the app reads the chip, and a certified identity-verification partner validates the issuing authority's signatures against the ICAO Public Key Directory and confirms the passport is genuine and unexpired; Julia Social never receives the passport data. The current enrollment level confirms that an authentic, unique passport was present, without a liveness step that binds the document to the person who scanned it; two higher levels that add in-person proofing are planned. See Enrollment and Identity Proofing, Human Verification & not.bot Verify, and Privacy Architecture.

1b. What the proof establishes

"How much does a verification prove about the party, and can the system prove less when less is needed?"

The issue. "Verify a human" hides five different claims, and a buyer who does not separate them can buy proof too weak for the obligation or too strong for the use. From the least to the most a verification can pin down:

• A human. The party is a real person, not a bot or a script. It says nothing about which person, how many accounts they hold, or any trait they carry.
• A human with specific traits. The party holds a proven attribute, over 13, resident of a jurisdiction, a licensed professional, with the rest of their identity withheld. The claim age-verification and eligibility checks need.
• A unique human. The party is a distinct person, one account per body, still with no name attached. The claim durable bans, review and vote integrity, one-per-person offers, and one-person-one-vote membership need, and a harder guarantee to make than a single trait, because it requires the enrollment itself to resist duplication.
• A unique human with specific traits. The party is one account per body and carries a proven attribute, still with no name. The claim a login wants when it needs sybil defense and an age gate at once: one person, one account, over 13, and nothing else disclosed.
• A fully identified human. The party is a specific named person in a civil registry. The claim regulated onboarding, know-your-customer, and accountability for published content need, and the one that discloses the most and creates the largest liability if the data is retained.

Can the system make the claim the use requires, since a unique-but-anonymous token cannot satisfy a know-your-customer rule and an age estimate cannot name a person for accountability. And can it make a weaker claim when a weaker one suffices, proving a single attribute without handing over the whole identity?

Every anonymous proof also comes in two variants, sealed so no party can ever de-anonymize it, or anonymous with a governed path to the identity for lawful process, which criterion 13 evaluates.

not.bot's position. One not.bot enrollment can answer at any level of specificity and discloses only what a request needs. The passport-bound root reaches a fully identified person, available to lawful process. Short of that, the not.bot credential proves a person is human with no name attached, a Site Pass proves one account per person without identifying them, and a name, age, or gender credential proves a single attribute such as over 13. The claims combine: a site that needs one account per person and an age check at once receives a Site Pass and an age credential together, with no name disclosed. See Credentials, Presentations, and Selective Disclosure, Human Verification & not.bot Verify, and Law Enforcement & Accountability.

2. Verifying without the vendor

"To check a proof, must the verifier reach the vendor's servers, or can the proof be verified without the vendor?"

The issue. A proof has to be checked somewhere, and the question is whether checking it requires contacting the vendor. Systems fall into three patterns:

• The vendor answers every check. The verifier sends each verification to the vendor's servers and waits for a yes or no, so the vendor sits in the path of every check. Implication: the vendor accumulates a record of who verified, where, and when: a honeypot that can be breached, mined, or turned to surveillance, and every check is only as fast and as available as those servers, failing when they do.
• Trust the vendor's hardware. The verifier trusts an attestation from the vendor's chip or enclave, with no independent record to consult. Implication: no per-check call home, but trust rests on silicon the buyer cannot audit, and a flaw or a forged attestation is invisible from outside.
• Check independent records. The proof carries its own evidence and verifies against records anyone can read, the vendor never contacted. Implication: no honeypot forms, the check adds no round-trip to the vendor and survives it going dark, but a trustworthy public record has to exist and the verifier must trust its integrity.

The buyer should ask which pattern each verification follows: it decides whether the vendor learns where its users go, and whether each check stays fast and works when the vendor falters.

not.bot's position. A verifier checks a not.bot proof by reading the Chia blockchain: the presenting identity's current state, the issuer key, and the on-chain revocation record. Julia Social is not contacted and need not be available, and no record of who verified what accumulates with the vendor. A not.bot Verify deployment reads its own blockchain nodes inside the operator's infrastructure, so a verification runs between the user's device and the operator's servers. Julia Social is a signatory to the No Phone Home movement. One exception: a QR-code signature stores its payload on Julia Social's servers, so verifying that format retrieves data from there, while a JAB-code signature or a signature presented online is self-contained and contacts no server. See Credentials, Presentations, and Selective Disclosure, Why Chia?, and System Architecture and Degraded-Mode Operation.

II. What the system keeps and who can see it

3. Reusable artifact

"Does a verification leave the buyer a reusable copy of the user's identity or a claim that cannot be replayed?"

The issue. When verification captures the raw inputs that prove identity (e.g. the face image, the document scan, the extracted fields), the buyer is left holding the exact material that document-and-selfie matching consumes: a reusable impersonation kit. It can be replayed to pass verification at another service, and the user cannot see who holds a copy. Each business that runs this kind of check holds a trove of these kits, and a breach of any one spills the verification images as ready-made impersonation material, selfies and government IDs together. The kit exists even when the buyer never downloads it: on a pass-or-fail result it still sits with the operator that ran the match, the vendor in a SaaS deployment. A cryptographic claim leaves nothing replayable: the proof authorizes one check and cannot be re-presented as the user. Whether a kit is replayable at all is a property of the design; retention is only a policy, and policies can be tightened or breached.

not.bot's position. A not.bot verification leaves a claim that cannot be replayed. The signing key stays in the encrypted database on the user's device and is never exported, and each presentation is bound to a fresh nonce so it cannot be lifted and re-presented as the user. No document image or biometric is collected at any point, so an operator running not.bot Verify never holds a face-and-document set; a site may retain the signatures presented to it, but those are single-use claims, not reusable identity material. The fact that a replayable copy does not exist is a property of the design, not a retention setting. See Privacy Architecture, Cryptographic Foundations, and Human Verification & not.bot Verify.

4. Operator blindness

"What do the operator and the vendor learn about who is verifying, and is that limit enforced by architecture or by promise?"

The issue. Every system draws a line between what the user reveals and what the operator and vendor keep, and the buyer has to find where that line sits and what holds it there. Three postures:

• Holds the data, limits itself by policy. The operator keeps the identity data and binds itself with a privacy promise; some let the buyer choose which jurisdiction stores it. Implication: the limit can be revised, misconfigured, or breached, the residency choice moves the honeypot rather than removing it, and the user cannot audit any of it.
• Sees it at enrollment, then deletes. The system captures the passport and selfie, signs a credential, and deletes the originals. Implication: blind at the moment of presentment, but there was a window of full custody and a deletion the user has to take on faith.
• Never receives the data. On-device storage, multi-party computation, or buyer-hosted deployment hold the line by construction. Implication: no policy change or breach can move the line, because the data was never there to take, and the buyer's job shifts from trusting a promise to checking an architecture.

"Cannot" and "promises not to" are different products, and the difference shows only under stress.

not.bot's position. Julia Social never receives passport data, prevented by architecture rather than policy. Every credential is produced by multiparty computation that yields a correct signed result without the signer seeing the inputs: age credentials use a three-party protocol among the app, Julia Social, and the Escrow Server, so neither Julia Social nor the Escrow Server learns the birthdate, and the not.bot identifier uses a two-party protocol between the app and Julia Social that cannot be tied back to the passport data. An operator deploys not.bot Verify in its own infrastructure, so Julia Social has no path into a running deployment. One scope note: a certified identity-verification partner sees the passport at scan time during enrollment, then deletes it within seconds, so the never-receives property describes Julia Social, not every party. See Privacy Architecture, Cryptographic Foundations, and Enrollment and Identity Proofing.

III. How identity behaves across the web

5. Cross-site linkability and recognition

"Can the user be tracked across sites by default, can they choose to be recognized, and can a third party recognize them across the web?"

The issue. A single verified identity used across many sites can link the user's activity into one profile. Underneath that risk, three properties pull against each other in any identity system, and most designs resolve the tension by silently deleting one — or by removing the user's choice:

• Recognizability. A returning person can be recognized across sessions — the property accounts, reputation, bans, and public personas all require.
• Unlinkability. Two services, or a broker between them, cannot join their records on one person into a dossier.
• Sybil resistance. One person cannot appear as many.

Systems built on fresh anonymous proofs keep unlinkability and lose recognizability: every visit is a stranger, so there is no reputation to build and no persona to keep. Systems built on a persistent identifier keep recognizability and sybil resistance and lose unlinkability. Systems built on per-service pseudonyms can reach all three — but in most designs the pseudonym is simultaneously the recognition handle and the uniqueness token, fused: the user gets exactly one persona per service, recognition is mandatory because the same person can never present fresh to the same service, and being the same chosen persona across services is impossible by construction — the math that prevents tracking also prevents wanted recognition.

Linkability itself is not uniformly bad; sometimes it is the point. A public persona — a byline, a brand, a maintainer handle — wants to be linkable: the same identity, recognized deliberately across many services, accumulating one reputation. The design question is therefore not "linkable or unlinkable" but which is the default, and who elects the exception. The desirable shape is unlinkable by default, with linkability as a per-persona choice the user makes — and, in the strongest designs, a choice that is contained: opting one persona into cross-service recognition exposes only that persona's trail, never the person's other contexts. A system with a single identifier per person cannot offer this: its one handle is either linkable everywhere or nowhere, and any dossier built on it is a dossier on the whole person.

In practice, systems sit at points on a continuum from covert tracking to consensual recognition:

• Covert cross-web recognition. A third party embedded across many sites recognizes the same user on all of them with no disclosure. Implication: verification becomes web-wide tracking the user never sees.
• A shared persistent identifier. Every site sees the same value for the user. Implication: no embedded observer is needed; any two sites, or a broker between them, can link their records.
• Unlinkable by default. Each site sees a different value. Implication: no two sites and no broker can tell their visitors are the same person.
• Unlinkable with consensual recognition. Unlinkability is the floor, and recognition is a capability the user grants per site and can withdraw. Implication: the user can choose to be recognized again, or prove they are the same human without revealing which human, so recognition is opt-in rather than a default they cannot escape.

The buyer should ask not just which properties a system has, but who holds the dials: Can a user maintain several personas at one service while the service still counts them as one person? Can a user choose to be recognized across services — a public byline, a portable reputation — without that choice being made for everyone? When a user does elect linkability for one persona, is the exposure contained to that persona? Is recognition something the user grants, or something the system imposes? And whether the private end holds by architecture or only by the vendor's policy is the buyer's last question here.

not.bot's position. The three properties are decoupled into mechanisms the user controls independently, so none is silently deleted. Unlinkability is the default: the app presents a fresh alias for every new site, each alias is an independent identifier, so two sites, or a broker between them, cannot determine that their visitors are the same person; the same value issued to two aliases produces uncorrelatable credentials, and Julia Social cannot link a user's aliases. Sybil resistance is consent-scoped and per site: a Site Pass, created only with consent, lets one site recognize one person behind several accounts without learning who they are, and Site Passes for different sites do not match even when those sites compare them. Recognition runs at whatever granularity the user chooses: one persistent alias at a site, several distinct personas at one site each with its own history, or a deliberately reused alias as a public persona across services, made recognizable on sight by a reserved name or a Verified Signer badge. That election is contained: the public alias's cross-service trail aggregates around that alias alone and stays uncorrelatable with the user's other aliases — with two disclosed exceptions: an alias holding a Verified Signer badge has a retained root-to-alias mapping so Julia Social can revoke the badge if the subscription lapses (a reserved-name persona carries no such mapping), and during a recovery or rekey the Recovery Server, which Julia Social operates today, transiently observes the identity's complete alias set. Uniqueness and recognition stay separate throughout — a site can learn "one human, three accounts" while the three personas remain distinct — and every configuration sits in front of the governed accountability path of criterion 13, so no setting is an accountability dead end. Unlinkability is the default and holds by architecture. See Identity Architecture, Privacy Architecture, and Credentials, Presentations, and Selective Disclosure.

6. Sybil resistance

"How does the system stop one human from minting many identities, and at what privacy cost?"

The issue. Any system that grants one identity per human has to stop a single person from minting many. Uniqueness is always deduplication against something, and the target determines both strength and cost:

• Against a body. An iris, palm, or face, checked against every prior enrollment. Implication: the strongest resistance, one enrollment per living person, and it requires a biometric database or biometric multiparty computation to exist somewhere.
• Against a document. A passport or national ID that can enroll only once. Implication: one enrollment per authentic document; a person holding two differently-issued documents can enroll twice, and no biometric ever needs to exist.
• Against an account. An email address, phone number, or federated login. Implication: cheap, and cheaply defeated, since accounts and numbers can be bought in bulk.
• Against a graph. Vouching by existing members. Implication: no data collection at all, but assurance decays as the graph grows, and it has historically failed at scale.

Separate from the target is where the resistance is applied: enforced globally, so every user carries one identifier everywhere, or offered per site, where the user proves one-per-human to a site when it asks and nothing is shared across sites. The buyer should ask not just how well a system resists duplication, but what it had to centralize or expose to get there, and whether the resistance is forced on every interaction or offered per site when a site needs it.

not.bot's position. not.bot deduplicates against a passport's identity fields, and offers the resistance per site. At enrollment, a peppered hash of the passport's personal-information fields — not the document number — is checked against every prior enrollment, so one person's passport data yields one identity even across reissued documents, and no biometric ever needs to exist. That sits on the per-document rung of the ladder, with edges that run both ways: a legal name change produces a new hash and allows a fresh enrollment, and two passports carrying differing fields could each enroll. At a site, a Site Pass lets that site recognize one person behind two accounts when it asks for one, computed by a three-party protocol so Julia Social does not learn which site asked and the site does not learn who the user is. There is no central biometric store to target, and a Site Pass is per-site and created with the user's consent, so the resistance is offered where a site needs it. See Enrollment and Identity Proofing, Human Verification & not.bot Verify, and Credentials, Presentations, and Selective Disclosure.

IV. What it can prove

7. Age assurance

"Does the system estimate age or prove it, can it disclose only what is needed, and what happens to users near the threshold?"

The issue. An age check needs only a yes-or-no answer, yet it is where systems over-collect the most. Three approaches:

• Estimate age from a face. Implication: no document needed, but it returns a probability, not a fact, and forces a safety buffer: to clear "over 18" the estimator rejects anyone who reads under 25, funneling marginal adults into the document upload they were trying to avoid.
• Check age against a full identity. Implication: accurate, and it discloses name, date of birth, and document number to answer a yes-or-no question.
• Return a single attested bit. Over-18 true, derived from a verified credential. Implication: answers the question and reveals nothing else, but it needs a credential issued ahead of time.

Regulators are beginning to grade age assurance by effectiveness rather than effort — as of this writing that shift has already landed in one national regime — and where it lands, estimation methods with published error margins face a bar that attested booleans clear by construction.

The related question is threshold flexibility: can the system answer over-13, over-18, over-21, and support users under 18 at all, or does it assume every subject is an adult. Age is where regulators are most active and where the gap between answering the question and harvesting an identity to answer it is widest.

not.bot's position. not.bot returns a single attested value. An over-18 or over-21 credential is a boolean derived from the passport's date of birth by multiparty computation, so a site receives true or false and learns no birthdate, name, or document number. Thresholds run from over-13 through over-25, with ranges, so the system supports users under 18 and a site requests the one threshold it needs. The credential is issued ahead of time and refreshes monthly, with every threshold reissued each time so the set requested never reveals which one applies to the user. See Human Verification & not.bot Verify, Credentials, Presentations, and Selective Disclosure, and Enrollment and Identity Proofing.

8. Content authenticity

"Can a human bind their identity to content they create, does that binding survive the open internet, and does it prove authorship or only guess at forgery?"

The issue. When content can be generated and altered at scale, the question shifts from "is this real" to "who stands behind this." Systems answer in different layers:

• Bind content to the device or software. Implication: proves a camera or an app touched the file, says nothing about the human, and the binding often lives in metadata that strips away the moment the file is re-encoded or screenshotted.
• Detect forgery after the fact. Score how likely a file is to be fake. Implication: a probabilistic arms race re-won every time the generators improve, and it never establishes who made the file.
• Bind a human identity to the content. A signature from a human's verified identity. Implication: survives the open internet, including screenshots and forwarding, and proves who authored or vouched for the item, but only for content someone chose to sign.

The buyer should ask whether the system proves human authorship or only attests to a device, and whether the proof survives contact with real-world distribution.

not.bot's position. not.bot binds a human identity to content. A signer composes content, authenticates with their biometric or device passcode, and produces a visible signature, a QR or JAB code (patent pending), carrying the signer's alias and the not.bot credential that proves a passport-verified human signed it. Because the signature is part of the visible image, it survives screenshots, forwarding, re-encoding, and printing, where embedded metadata strips away on upload, and the visible code also tells a viewer that verification is available. The proof exists for content a person chose to sign. See Content Provenance & Digital Signatures, Content Signing & not.bot Sign My Work, and The not.bot App.

V. Where and how it runs

9. Reach of use

"Does it work face-to-face and offline, and does the user's verified status travel with them or get re-checked from scratch at every site?"

The issue. A verification system is useful only where it works, and two limits decide its reach:

• Where a check can run. Does verification work at a door, a checkout, a polling place, with no network, or only inside a web request?
• Portability. Does verified status travel with the user, or is each check a one-off transaction re-run at every site? In the portable model the user verifies once, holds a credential, and presents proofs that any verifier with a reader can check, so the credential reaches everywhere a reader exists, like an ID in a wallet. In the per-site model there is no credential to carry: each business re-runs the whole verification from scratch, and the result is bound to that business and reaches nowhere else.

Reach is not a headline feature, but it decides whether a credential is something a person uses across their life or only on the handful of sites that wired it in. This criterion is about where verification works for a user who already holds it; who can enroll at all is a separate question — see Population coverage (16).

not.bot's position. A user verifies once at enrollment, holds the credential, and presents proofs that any verifier with a reader can check; both not.bot Verify and the not.bot app are readers, so a check does not re-run the whole verification at each site. Presentations work on-chain, online against the blockchain, and offline against a stored snapshot of issuer state, which covers a door or a checkout. A JAB-code signature verifies its embedded content with no network, while checking current key state and revocation needs the blockchain or a snapshot; offline signing and verification in the app are on the roadmap. See Credentials, Presentations, and Selective Disclosure, System Architecture and Degraded-Mode Operation, and Roadmap.

10. Deployment model

"Can the buyer run it in their own infrastructure — and when they do, what does the buyer become?"

The issue. Identity data lives somewhere, and the buyer's exposure depends on whether they control that somewhere. A cloud-only service concentrates every buyer's verifications in the vendor's infrastructure, where one breach reaches all of them, so the first question is whether the buyer can run the system in their own infrastructure at all. But self-hosting is no longer rare, so on its own it no longer separates the field. Self-hosting moves the data inside the buyer's boundary; what data arrives there differs by architecture:

• The buyer becomes an identity custodian. The self-hosted stack captures documents and biometric templates and runs deduplication against a database the buyer now owns. Implication: the vendor is blind, but the honeypot did not disappear — it moved in-house: biometric-privacy statutes, health-data rules where applicable, breach liability, and per-service re-enrollment all land on the buyer.
• The buyer becomes a verifier only. The self-hosted stack checks presentations against credentials the user holds. Implication: the buyer retains per-site tokens and the specific claims users consented to share; no document images, no biometric templates, and no identity database accumulate anywhere — not at the vendor, and not at the buyer either.

The first model answers the compliance question "does my data leave my boundary." The second also answers "what liability accumulates inside it." For a buyer under biometric-privacy statutes, the difference is the difference between avoiding a vendor risk and avoiding the risk class.

For a buyer under HIPAA, FedRAMP, or financial-services rules, control over where the system runs is a gate, not a preference: federal use can require a FedRAMP-authorized boundary or an air-gapped install, HIPAA turns on a business associate agreement and where protected health data sits, and financial regulators press for data residency, dedicated tenancy, and a workable exit plan. Deployment is often how a buyer meets those obligations, which ties this criterion to regulatory alignment.

not.bot's position. not.bot Verify is the second model: the buyer becomes a verifier, not a custodian. A Verify deployment runs in the operator's own infrastructure, on-premise or in the operator's own cloud tenant, and what accumulates there are Site Passes and the specific claims users consented to share — never document images, biometric templates, or an identity database, because identity proofing happened once at enrollment, elsewhere, against a credential the user carries. The operator runs its own blockchain nodes and key store, and no user data flows to Julia Social during verification. This supports buyers whose rules require it, including HIPAA, FedRAMP, and data-residency obligations. One honest scope note: self-hosted identity engines legitimately serve buyers who need to verify populations not.bot cannot yet enroll — see Population coverage (16) — or whose policy requires running their own one-to-many biometric deduplication. See Human Verification & not.bot Verify and System Architecture and Degraded-Mode Operation.

VI. When things go wrong, and who answers to whom

11. Recovery and reclaim

"Is the identity long-lived, and if so, how does the true owner recover it when the device is lost, sold, or shared?"

The issue. In transactional proofing the user re-verifies from scratch each time, so there is nothing to recover, and also nothing that persists: every re-proof repeats the cost and the data exposure. A long-lived identity, a credential or key the user holds over time, raises the harder question, and the recovery path is where it gets attacked. The login is seldom the breach; the support agent who restores a lost account to whoever sounds convincing is. For long-lived identity, recovery models fork:

• Help-desk or fallback channel. Recovery runs through a support agent, an email reset, or an SMS code. Implication: the recovery path is the weakest link, socially engineerable, and a convincing call can hand the identity to the wrong person.
• Platform-account re-provisioning. Recovery inherits the device platform's account recovery. Implication: as strong or weak as that platform account, and it leashes the identity to the platform.
• Re-anchor to the human root. The true owner re-proves against the still-attached anchor, a government document or biometric, and reclaims the identity on their own. Implication: no help desk to talk into anything, and a lost, stolen, sold, or shared identity can be reclaimed by the real owner, because the anchor stays with them. It needs a re-provable human anchor to work.

Sharing is the same story from the other side: a re-anchored system does not stop a user from enrolling for someone else, but the real owner can always reclaim, so a shared or sold identity never stays gone. The buyer should ask whether the identity is long-lived, and if so, whether recovery is the user re-proving against a root or a help desk that can be talked into anything.

not.bot's position. A not.bot identity is long-lived and recovers by re-proving against the human root rather than through a help desk. The identity persists on the blockchain, and the owner reclaims it by re-proving with the passport and a recovery password; a recovery agent and the Escrow Server hold an encrypted recovery bundle they cannot read, a 48-hour delay lets the owner cancel a malicious recovery, and even a completed theft can be reversed because the anchor stays with the owner. Recovery does not prevent a user from enrolling on someone else's behalf; the reclaim path resolves a shared or sold identity. Today Julia Social is the only recovery agent and Recovery Server operator, with multi-agent arrangements planned. See Recovery, The not.bot App, and Security Model & Known Weaknesses.

12. Regulatory alignment

"Does the system satisfy the regulations the buyer must follow, and does it comply by collecting more data or by collecting less?"

The issue. The buyer often has regulatory obligations to meet, and the system has to satisfy them to be acceptable: COPPA and the GUARD Act and KOSA for minors, GDPR for European users, HIPAA where health data is near, data-residency rules for where identity data may be stored. Some systems satisfy a regulation by collecting more, building the identity dossier the rule assumes, while others satisfy it by collecting less, proving the required fact without retaining the data that creates the liability. Complying by collecting less is the counterintuitive option, and the one that leaves nothing to breach.

not.bot's position. not.bot satisfies a requirement by collecting less. It proves the required fact without retaining the data that creates the liability: an age gate receives a single attested value, a proof of personhood receives a boolean, and an operator under HIPAA, FedRAMP, or a data-residency rule runs Verify inside its own boundary so identity data does not leave its control. Credentials are computed by multiparty computation that signs without the signer seeing the inputs, so minimization is built into issuance. See Privacy Architecture, Cryptographic Foundations, and Human Verification & not.bot Verify.

13. Lawful access and unmasking

"When a proof is anonymous, can a lawful authority ever reach the identity behind it, and can the buyer accept a system where the answer is a permanent no?"

The issue. Most privacy-preserving verification is anonymous by design: a zero-knowledge proof shows the claim is true and keeps no link between the credential and the civil identity, so no party, and no court, can connect them. That is a feature for the user and a problem for the buyer who answers to a regulator, a safety obligation, or a court. Can the buyer's setting accept a proof that no lawful authority can ever de-anonymize, behind which a serious abuser stays out of reach for good? Some settings can, many cannot. Three postures answer it:

• Unmasking is impossible. No party holds the link between the credential and the civil identity. Implication: maximal privacy, and no lawful path, so a serious abuser stays out of reach for good.
• Unmasking is mandatory. The operator always holds the link. Implication: serves regulated and safety-critical uses, and exposes every user to whoever can breach the operator.
• Unmasking is governed. Anonymity for everyday use, and a deliberate, auditable path to unmask the identity exists for lawful process. Implication: lawful reach without standing exposure, but only if the governance is real and not a backdoor by another name.

This cuts both ways by reader: an enterprise in a regulated sector wants a lawful path, a privacy-maximalist wants it impossible. The capability that lets anonymity and lawful reach coexist is rare; a buyer should not assume a privacy-preserving system has it.

not.bot's position. not.bot keeps everyday use anonymous and provides a governed path to the identity behind a proof for lawful process. Identification starts from a specific signature, requires a valid US legal demand, needs the cooperation of both Julia Social and the independent escrow agent, and then takes days of per-record computation on air-gapped hardware; no single party holds the link, and bulk identification is not possible, because there is no database mapping users to identities and each request handles one signature. The result is lawful reach without standing exposure. See Law Enforcement & Accountability and Privacy Architecture.

14. Adoption risk

"Once a buyer commits, will the vendor last, what does the system cost, and must the buyer pay in a cryptocurrency?"

The issue. Buying a verification system is a bet on the vendor, not just the technology. A few risks to weigh:

• Durability. Will the vendor still be operating in a few years, and how much of what the buyer builds depends on it continuing to run? An established vendor is sometimes the safer bet.
• Leverage. Once a buyer has built on a system, switching is costly, so the vendor's power to raise prices or change terms has teeth. This risk is much the same across vendors.
• Cost. Per-user pricing runs from commodity bot-checks at the low end to full identity verification at the high end, and the same check can cost many times more under one architecture than another. The cheapest option is not always the right one, but cost belongs on the checklist.
• Token exposure. Some systems require the buyer to pay in a cryptocurrency rather than ordinary money, or pull the buyer into a token economy a crypto-averse board will not accept. A buyer should ask whether adopting the system means participating in cryptocurrency at all.
• Metrics verifiability. Adoption claims in this market are almost universally self-reported and, in documented cases, have been overstated by an order of magnitude until stress revealed it. A buyer should ask what evidence stands behind a user count: a third-party audit, on-chain observability, named production customers, or the vendor's word.
• Treasury stability. Token exposure — does the buyer touch cryptocurrency — is one question; token dependence — does the vendor's runway depend on a token price — is another. The recent record: token-financed verification vendors have destabilized under vesting controversies, treasury hacks, and incentive wind-downs, while subscription- and acquisition-funded vendors held. A crypto-averse buyer should check both.
• Cost model comparability. Pricing in this market comes in incommensurable shapes: per-check, per-monthly-active-user, per-signer, free-with-fees-announced-but-unpriced, and free-at-the-platform-layer. Normalize to expected annual cost at the buyer's volume before comparing, and price the unpriced — "free until fees arrive" — as uncertainty, not zero.

not.bot's position. A buyer pays for not.bot in ordinary currency, against published USD tiers a buyer can compare by arithmetic. A not.bot user holds no token, pays no blockchain fee, and runs no wallet, because Julia Social funds the on-chain operations; adopting not.bot does not require participating in a cryptocurrency, though the identity records sit on a blockchain, and no token exists anywhere in the model, so the vendor's runway does not ride on one. On metrics: not.bot's own adoption figures are not yet third-party verified either, and its on-chain enrollment signal is deliberately obscured by decoy traffic — a privacy feature with a transparency cost. See Why Chia? and Privacy Architecture.

15. Operational assurance

"How much of the vendor's operations and data handling can the buyer verify, and how much must they take on faith?"

The issue. The buyer cannot watch the vendor run, so the real question is how much of its operations and data handling can be checked, and how much rides on the vendor's word. Three postures:

• Trust us. The vendor publishes little and holds few outside attestations. Implication: nothing to verify, so the buyer's only recourse is the vendor's word.
• Certified but closed. The vendor carries third-party audits, SOC 2, ISO 27001, and the like, over a system that stays proprietary and unauditable from outside. Implication: independent proof that controls exist, over a black box the buyer still cannot inspect.
• Open and attested. The protocol or implementation is open and documented, and operations are backed by certification, the vendor's own or its subprocessors'. Implication: the buyer can inspect how the system works and confirm its operations are audited, the strongest assurance and the rarest.

Separately from who audited it, the buyer should ask what stands ready to break it: a continuous public bounty against the system's core security claim, a conformance program with a public registry, and — rarest — a vendor-maintained register of known weaknesses with planned mitigations. Point-in-time audits age; standing adversarial evidence compounds. A vendor that publishes what is wrong with its own system is giving the buyer the one document competitors never provide.

The buyer should weigh how much they can verify against how much rides on faith, and treat "trust us" as the posture that has to be made up for everywhere else.

not.bot's position. not.bot is open and attested. The did:julia method is specified in public, the Chialisp code that implements it is open source, the not.bot Verify SDK is open source, and this documentation set lets a buyer inspect how the system works. Operations rely on certified subprocessors: the identity-verification partner that validates the passport at enrollment holds ISO/IEC 27001:2022 certification and is an eIDAS Qualified Trust Service Provider, and the escrow agent that stores the encrypted records has completed a SOC 2 Type 1 examination. Julia Social holds no certification of its own; the assurance comes from the open protocol, the public documentation, and the certified subprocessors. As standing self-disclosure, the published Security Model maintains a register of known weaknesses with planned mitigations (the SW series), and the Privacy Architecture states, party by party, what each participant can and cannot learn. The multiparty-computation protocols have not yet had an independent security audit; one is planned, and this criterion will be updated when it completes. See Security Model & Known Weaknesses, did:julia Technical Specification, Privacy Architecture, and Enrollment and Identity Proofing.

VII. Who it can verify, and what it connects to

16. Population coverage

"Who can the system verify, today — and does the buyer's use case need everyone, or only the willing?"

The issue. A verification system's assurance means nothing for the people it cannot enroll. The coverage ladder, widest to narrowest:

• Any live face. Biometric enrollment reaches wherever a camera or the vendor's hardware does.
• Any accepted government ID. Document-and-selfie flows and self-hosted engines enroll whoever holds an ID type they support.
• Holders of a chip-enabled document. NFC-based enrollment requires a passport or ID card with a readable chip; in one large market, roughly half of adults hold a passport as of this writing.
• Holders of an already-issued wallet credential. The thinnest rung today, growing on legal mandates.

Every rung excludes someone: the undocumented, the passport-less, minors without documents, people outside supported countries.

The buyer's real question is whether the use case demands mandatory coverage — every user must pass: a patient portal, a statutory age gate on a whole site — or supports opt-in coverage — verified users gain capabilities others do not: badges, trust marks, one-per-person perks, priority access. A mandatory-coverage buyer must match the system's reach to their whole population on day one. An opt-in buyer can adopt a narrower system immediately and grow with its enrollment, and verification offered as a benefit converts better than verification imposed as a wall.

not.bot's position. Enrollment today requires the app from a US app store and an NFC-enabled passport, so not.bot sits on the chip-enabled-document rung, narrowed further by country availability. The published expansion path is additional passport countries and in-person partner enrollment at banks, hospitals, and similar institutions — the planned notbot1 level. not.bot fits opt-in deployments today, human-only capabilities added to an existing site, and fits mandatory-coverage deployments only as enrollment coverage grows. See Enrollment and Identity Proofing and Roadmap.

17. Agent readiness

"When the counterparty is an AI agent acting for a human, what does the system verify — and who answers for the agent?"

The issue. Agents now transact, browse, and negotiate on humans' behalf, and a verification system meets them in one of several postures:

• Blind. The system distinguishes human from automated and treats every agent as an intruder. Implication: it misclassifies the fastest-growing category of legitimate traffic.
• Key- or token-bound agent identity. The agent holds a credential: an API key, an OAuth token, a signed key. Implication: proves an authorized credential is present, but any process holding a copy is indistinguishable from the original, and delegation chains flatten at one hop.
• Account-bound agent identity. The agent is a directory object with an owner. Implication: adds governance and revocation; identity still travels with credentials that copies can share, and the "owner" is an identity-provider account, not necessarily a verified person.
• Process-bound, human-anchored identity. The credential is bound to one running process at issuance, so copies holding identical key material fail verification; authority arrives through an attenuating delegation chain that terminates at a verified human; revocation cascades.

Sub-questions for any vendor: Can two copies of the agent present the same identity? Does the delegation chain end at a person who can bear consequences, or at a key file? Can a grant be narrowed as it is re-delegated, and revoked all at once? What does an auditor reconstruct after the fact?

not.bot's position. honest.bot, built on the same identity infrastructure as not.bot, is the process-bound, human-anchored posture. The core mechanism is in production today: every not.bot Verify signature server acquires an honest.bot credential at startup, bound to that running process by multiparty computation, so no two servers can hold the same credential at once. Authority attenuates along two chains a verifier enforces together — capability credentials narrowed by cryptographic subset, and natural-language mandates narrowed by an intelligent verifier reading the chain — and every chain terminates at a not.bot identity with the governed lawful path of criterion 13 behind it. One honest scope note: the third-party product — the SDK, the appliance, and third parties deploying their own honest.bot-credentialed agents — is targeted for Q4 2026 and has not yet shipped. See Honest.bot Verifiable Agent Identity and Delegation and Organizational Identity.

18. Rails interoperability

"Can the credential surface through channels the buyer's users already have — or only through the vendor's own app?"

The issue. Verification is increasingly consumed through shared rails: operating-system age APIs, browser credential APIs that let any website request an attestation from any wallet, enterprise single sign-on, and content-provenance manifests. A credential that can ride those rails reaches users the vendor never acquired; one that cannot depends entirely on the vendor's own app footprint. The buyer should ask which standards the credential speaks (verifiable-credential formats, DID methods, OpenID Connect), which rails can present it today, and what is roadmap versus shipped. A vendor's standards alignment — the same data model — is not the same as rails presence — actually requestable through the browser API.

not.bot's position. Largely roadmap, stated plainly. not.bot credentials are single-claim W3C Verifiable Credentials by design and combine into standard verifiable presentations, so the data model interoperates with W3C tooling today. DIDComm messaging and third-party credential issuance are on the published roadmap. Presentation today runs through the not.bot app and not.bot Verify deployments, not through OS wallet or browser credential APIs. This criterion matters more than not.bot's current score on it. See Credentials, Presentations, and Selective Disclosure and Roadmap.

The field at a glance

The typical posture of each category on each criterion, in one phrase. Postures are generic to a category — individual vendors vary — and no vendor is named; not.bot's own position on every criterion is stated in the body above.

View this page as Markdown