Task Prompt to Accept Proof-of-Personhood Credentials as Weighted Evidence, Not a KYC Bypass
This Arc task prompt integrates proof-of-personhood credentials (Orb-based iris schemes, palm-based challengers, and attribute and presence extensions) into your verification flows as evidence inputs, never bypass lanes. Arc, the deepidv credential gateway, builds a scheme posture table per accepted scheme covering enrollment governance, gallery custody and jurisdictional standing, revocation mechanics and measured lag, and economic model dependencies, with opacity graded as posture. It sets evidence weighting per action class, treating uniqueness proofs as anti-Sybil evidence that corroborates your book-level reuse analytics, presence proofs as session corroboration, and attribute proofs as data-minimizing facts for age and eligibility gates, then defines binding tiers that separate the actions where a proof plus possession suffices from those needing liveness-anchored present-person verification on top, marking where KYC-grade identity proofing stays mandatory regardless. Delegation handling maps agent-presented proofs to your verified-principal requirements with action-bound approvals per HAPS tiers, and an evidence schema records scheme, proof type, checks run, binding method, and the proof's role in each decision for examiners. Any flow where a personhood proof would substitute for identity verification or presence binding is flagged as a critical finding with an owner and date. Built for onboarding, fraud, and compliance leads who want the uniqueness signal without letting it stand in for knowing the customer.
How to use this prompt
- 1
Open Arc in the deepidv dashboard and paste the full prompt, or run it in Claude, ChatGPT, or Gemini to draft the intake policy before wiring it to live flows.
- 2
Add an INPUT section below the prompt listing the personhood schemes you accept or plan to accept, the proof types each issues, the action classes you gate (onboarding, payouts, recovery, age and eligibility checks), and how agent-presented proofs reach you today.
- 3
Run the prompt and read the binding tiers first, confirming that onboarding, payouts, and recovery still require liveness-anchored present-person verification and that KYC-grade identity proofing remains mandatory wherever the prompt marks it so.
- 4
Route every critical finding, meaning any flow where a personhood proof currently substitutes for identity verification or presence binding, to its owner with a date, and hand the evidence schema to compliance.
- 5
Re-grade the scheme posture table whenever a scheme changes its enrollment governance, gallery custody, or revocation mechanics, and before accepting any new scheme.
The prompt
Arc, integrate proof-of-personhood credentials (Orb-based iris schemes, palm-based challengers, and attribute/presence extensions) into our verification flows as evidence inputs, never bypass lanes. Produce: 1. Scheme posture table: per accepted scheme, enrollment governance (operator audits, insider controls), gallery custody and jurisdictional standing, revocation mechanics and measured lag, and economic model dependencies, with opacity graded as posture. 2. Evidence weighting: what each proof type contributes per action class: uniqueness proofs as anti-Sybil evidence corroborating our book-level reuse analytics; presence proofs as session corroboration; attribute proofs as data-minimizing facts for age and eligibility gates. 3. Binding tiers: the action classes where a proof plus possession suffices versus those requiring our liveness-anchored present-person verification on top (onboarding, payouts, recovery), and where KYC-grade identity proofing remains mandatory regardless. 4. Delegation handling: for agent-presented proofs, the mandate chain from delegated personhood to our verified-principal requirements, with action-bound approvals per our HAPS tiers, since a human existing behind an agent is not that human authorizing this action. 5. Evidence schema: per acceptance, the record naming scheme, proof type, checks run, binding method, and role in the decision, exportable for examiners who will ask how unlinkable credentials met record-keeping duties. Flag any flow where a personhood proof would currently substitute for identity verification or presence binding as a critical finding with owner and date.
Test it in Claude or another LLM
This prompt is built for Arc inside deepidv, where Arc weighs live credential presentations inside your verification policy. You can dry-run the intake design in any general LLM first with synthetic schemes and flows before wiring it to real acceptance policy.
- 1
Paste the full prompt into Claude, ChatGPT, or Gemini, replacing the opening 'Arc,' with a role instruction such as 'Act as a verification policy architect integrating proof-of-personhood credentials as weighted evidence.' Keep the five numbered outputs as written.
- 2
Under the INPUT section, paste the synthetic sample block below so the model has schemes, proof types, and action classes to weigh.
- 3
Add one framing line: 'This is synthetic test data. Where a scheme's governance, custody, or revocation practice is not stated, grade it as unknown, since opacity is a posture.'
- 4
Check the output shape: a scheme posture table, evidence weighting per action class, binding tiers, delegation handling, and an evidence schema, with every flow where a proof substitutes for identity verification or presence binding flagged critical. If any proof is allowed to stand in for KYC, tighten the framing and re-run.
- 5
Once the shape is right, run it live in the deepidv dashboard where Arc weighs real presentations inside your verification policy.
Synthetic sample data to paste alongside the prompt
Fake test data, safe to share with any LLM. Swap in your own once the output looks right.
SCHEMES (synthetic, fake): - Scheme I: iris-based uniqueness proof, operator audits published, gallery custody offshore, revocation lag unmeasured - Scheme P: palm-based uniqueness and presence proofs, enrollment governance undocumented - Scheme A: attribute extension issuing over-18 proofs ACTION CLASSES (fake): onboarding, payouts, account recovery, age-gated content CURRENT POLICY (fake): a Scheme I proof skips document verification at onboarding for accounts depositing under $500 (fake threshold) AGENTS (fake): shopping agents present delegated Scheme P proofs at checkout, no mandate check OPEN ITEM (fake): how unlinkable proofs meet our record-keeping duties
Pairs with on deepidv
FAQ
What is a proof of personhood?
It is a credential showing that a unique, real human stands behind an account, typically issued after a biometric enrollment such as an iris or palm capture and presented in a privacy-preserving way. It answers whether this is one distinct human, not which human, which is why the prompt treats it as anti-Sybil evidence rather than identity verification.
Can a proof of personhood satisfy KYC?
No. KYC requires knowing which customer, with validated attributes and screening, while a personhood proof contributes uniqueness evidence and, through attribute extensions, data-minimized facts. The prompt flags any flow where a personhood proof would currently substitute for identity verification or presence binding as a critical finding with an owner and date.
How should agent-presented personhood proofs be handled?
A delegated proof shows that a real, unique human stands behind an agent, but a human existing behind an agent is not that human authorizing this action. The prompt maps the mandate chain from the delegated proof to your verified-principal requirements and requires action-bound approvals per your HAPS tiers.
Related prompts
Run it with live verification data
These prompts work in any LLM. Inside the deepidv dashboard, Luna, Arbiter, and Arc run them against your real sessions, screening lists, and audit trails.
Book a Demo