Evaluation Framework

How to evaluate any of the products that overlap with not.bot™, across the categories described in "The field" below. Names no companies. Defines the criteria any buyer can apply to any vendor, including not.bot™.

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).

The field

The products a buyer weighs against not.bot fall into 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, for sybil resistance, one-person-one-vote, and abuse rate-limiting, 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.

A buyer's obligations often reach across more than one of these. 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 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 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 one-person-one-vote, anti-Sybil membership, and abuse rate-limiting 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 18. 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 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. 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.

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. Each alias a user presents to a site 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. Recognition is a capability the user grants per site: a Site Pass, created only with consent, lets one site recognize a returning person without learning who they are, and Site Passes for different sites do not match even when those sites compare them. 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, and each method carries a privacy cost:

A biometric held centrally. One enrollment per body, enforced against a central biometric set. Implication: strong duplication resistance, and a central biometric database that becomes a target.
A phone number or document. Uniqueness tied to a SIM or an ID number. Implication: low friction, but cheap to defeat, since numbers and documents can be bought or reused.
Per-site, consensual uniqueness. The user proves one-per-human to a site when it asks, with nothing shared across sites. Implication: duplication resistance without a global identifier or a central registry, at the cost of work at each site that needs it.

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 resists duplication at two points without a global identifier or a central registry. At enrollment, a passport that has enrolled before is rejected by a stored hash, so one passport yields one identity. 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.

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 device biometric, 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 Signer, 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:

Offline and face-to-face. Does it 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.

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, or only as the vendor's cloud service?"

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. A model the buyer runs in their own infrastructure, on-premise or in their own cloud tenant, keeps the data inside the buyer's control and compliance regime. For a buyer under HIPAA, FedRAMP, or financial-services rules, that control 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 runs in the operator's own infrastructure, on-premise or in the operator's own cloud tenant, so identity data stays inside the operator's control and compliance regime; 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. 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.

not.bot's position. A buyer pays for not.bot in ordinary currency. 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. See Why Chia?.

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.

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. The multiparty-computation protocols have not yet had an independent security audit, and one is planned. See did:julia Technical Specification, Privacy Architecture, and Enrollment and Identity Proofing.

View this page as Markdown