Two visually identical ships diverge from a shared luminous wake, representing canonical lineage and fork divergence.
Individual Entity Proof Protocol

Identity is not structure.

Identity is continuity.

IEPP is a registry-relative protocol for testing whether an AI agent or other digital entity presents the next policy-authorized continuation of a previously accepted execution lineage.

Evidence L1 software prototype
Readiness Not production ready
Patent PCT application filed

The Ship of Theseus, reframed: identical parts do not determine which execution remains on the accepted lineage.

Explore

A visual intuition for IEPP continuity

A still glass of water before an event
A visual intuition for IEPP · 01

Every present
has a past.

현재는 우연히 놓인 한 장면이 아닙니다.

01 / Why IEPP

A valid credential does not tell you which copied execution may continue.

AI agents can be snapshotted, rolled back, restored, migrated, and forked. After copying, two branches may share the same model, identifier, signing key, and saved state.

Conventional authentication can confirm possession of a credential. It does not, by itself, decide which competing branch is permitted to resume a protected workflow.

IEPP asks a narrower, operational question: Is this candidate the next continuation accepted by the declared registry and governance policy?
Same key Same state Two branches
Credential authentication Both can appear valid
IEPP policy decision One successor is accepted

02 / How it works

Four steps turn lineage into an enforceable decision.

The L1 reference path combines fresh challenges, authenticated transition evidence, and atomic single-successor acceptance.

  1. 01

    Fresh challenge

    The verifier issues a single-use, entity-bound challenge.

  2. 02

    Bound evidence

    The agent signs the challenge, counter, predecessor, candidate state, runtime commitment, and declared entropy source.

  3. 03

    Atomic registry

    The registry advances its canonical head only when the presented predecessor is still current.

  4. 04

    Policy gate

    The protected action proceeds only after canonical acceptance. A losing fork is rejected.

Canonical lineage after a shared predecessor The registry’s compare-and-swap decision—not entropy alone—selects the accepted successor.
Canonical lineage and competing fork A shared sequence branches into one canonical successor accepted by the registry and one competing successor rejected because its predecessor is no longer current. SHARED HISTORY CURRENT HEAD R1 R2 R3 R4 R5 accepted protected action R5′ competing fork rejected
Complement, not replacement.

IEPP is designed to work alongside signatures, IAM, agent identity, provenance, and future TPM/TEE attestation.

03 / Evidence

What the public L1 software experiments actually observed.

Every number below is tied to a published test model. None is presented as universal hardness, certification, or production assurance.

50,000/ 50,000

Valid transitions accepted

Ed25519 reference core under the declared L1 model.

0/ 10,000

False accepts per tested class

Replay, rollback / losing-fork, and signed-field substitution trials.

0/ 1,000

Double accepts in fork races

In-memory, atomic, single-registry trials.

0/ 100

Double accepts in A3 loopback

Signed HTTP-registry races; exactly one cooperative protected action per trial.

Evidence ladder

Label the trust basis before stating the result.

The current public implementation is L1. L2–L4 remain research and engineering targets unless a specific result says otherwise.

L1Current
Experimental

Software state, OS entropy, authenticated transcript

Research and low-risk tests
L2Future
Protected runtime

Isolated key/state plus TPM, TEE, or secure-element attestation

Hosted and device-bound agents
L3Future
Witnessed registry

Quorum, transparency gossip, or external anchoring

Split-view and equivocation detection
L4Future
Physical binding

Evaluated hardware identity plus PUF or protected physical entropy

Robots and safety-critical systems

IEPP does not claim

No metaphysical shortcut.

  • Consciousness, personhood, intention, or legal identity
  • A physically unique or metaphysically “original” clone
  • Entropy quality or unpredictability certification
  • Production readiness or universal attack resistance

Known failure boundaries

The policy and trust anchors matter.

  • An attacker with the current key and state may win the registry race
  • Isolated registries can accept conflicting branches
  • A malicious runtime is outside the present L1 protection boundary
  • Entropy is a policy and audit hook, not the canonical selector

04 / Research

One current claim. A complete, preserved research trail.

The current specification governs interpretation. Earlier versions remain accessible as dated evidence of how hypotheses were tested, narrowed, or rejected.

CURRENT CANONICAL REFERENCE

Manuscript · September 2026

IEPP: Policy-Relative Canonical Continuation for Copyable AI Agents

Authenticated predecessor-bound transitions, fresh single-use challenges, atomic single-successor acceptance, explicit trust assumptions, and reproducible L1 evaluation.

Read manuscript source arXiv public link pending moderation

Research evolution

Negative results changed the protocol.

  1. v0.2 — Experimental validation

    Entropy-bound response uniqueness and replay observations.

  2. v0.3 — Trajectory continuity

    Statistical original/fork discrimination was tested and found insufficient.

  3. v0.4 — Canonical lineage

    The project moved from statistical resemblance to explicit lineage comparison.

  4. v0.5 — Policy layer

    Registry governance, alerting, hardware anchors, and deployment questions.

  5. Current — Registry-relative continuation

    A narrow single-registry L1 claim with explicit failure boundaries.

Historical archive

Original pages remain evidence—not current specification.

Each archived page should retain its original URL and content, with a visible “historical / superseded” notice linking back to the current evidence map.

Preservation check: The former v0.1 navigation link now resolves to the rewritten homepage. Before the live redesign, recover the original v0.1 content from WordPress revisions or backup and assign it a permanent archive URL.
v0.1Recovery check

Initial AI Existence Proof concept

Original homepage record. Preserve from revision history before migration.

Archive URL pending recovery
v0.2Historical

Experimental Validation

Early uniqueness, replay, entropy-source, and scalability observations.

Read preserved page
v0.3Historical

Trajectory Continuity

Includes the negative statistical-discrimination result and later clarification.

Read preserved page
v0.4Historical

Entropy Lineage & TRP

Canonical-lineage framing and conjectured TRP-hardness direction.

Read preserved page
v0.5Historical

Policy & Deployment

Multi-proof, continuous verification, reporting, registry, and hardware proposals.

Read preserved page
Adjacent conceptPaused

Intrinsic Fingerprint

A preserved fingerprint / watermark direction outside the current IEPP L1 claim.

Read status page

05 / Origin & IP

An independent research project with a traceable origin.

Individual Entity Proof Protocol (IEPP) was conceived and developed by Woocheol Seo, independent researcher, Republic of Korea.

The website, manuscript, GitHub repository, experiments, and historical whitepapers should cross-link as one canonical evidence chain.

Patent status

PCT/IB2026/051545
Filed
18 February 2026
Status language
Application filed
Does not imply
Grant, certification, or independent validation

한국어 1분 요약

IEPP는 “진짜 원본”을 선언하는 기술이 아닙니다.

IEPP는 복제·스냅샷·롤백이 가능한 AI 에이전트가 보호 작업을 다시 시작할 때, 등록된 단일 레지스트리와 정책을 기준으로 그 후보가 이전에 승인된 실행 계보의 다음 연속인지 검사하는 연구 프로토콜입니다.

현재 공개 증거는 소프트웨어 키·상태와 단일 레지스트리를 사용하는 L1 실험에 한정됩니다. 의식·법적 신원·물리적 유일성·형이상학적 원본·엔트로피 품질·상용 안전성을 증명하지 않습니다.

핵심은 “같은 구조인가?”가 아니라 “정해진 정책 아래에서 승인된 계보를 이어가는가?”입니다.

논문·백서·실험 자료 보기

06 / Collaboration

Reproduce it. Critique it. Try to break the assumptions.

Independent reproduction, protocol review, adversarial analysis, implementation, standardization, and bounded industry pilots are welcome.

Research validation Security review Implementation Standards Industry pilot