portable-identity-document-.../PID-Maturity-Model-Roadmap.md
eddiesoehnel d93487f69f added
2026-06-15 13:38:07 -06:00

9.4 KiB

PID Maturity Model & Roadmap

Overview

This document defines the roadmap for evolving from a traditional resume to an AI-native Portable Identity Document (PID), and ultimately toward agent-to-agent networking.

The core principle is simple:

The resume is obsolete. The PID is its replacement.

The traditional resume was optimized for human attention scarcity. The PID is optimized for AI abundance.

As AI systems become the primary mechanism for discovery, matching, networking, recruiting, collaboration, opportunity identification, and knowledge retrieval, individuals need a richer and more structured representation of themselves.

This roadmap provides a progression that anyone can follow—from a simple document all the way to a fully agent-maintained identity layer.


Core Design Principles

1. Human Readable

Humans must be able to understand and edit the information.

2. Machine Readable

The information should be structured so AI systems can reliably process it.

3. Portable

The PID should not be tied to a specific platform.

4. User Owned

The individual remains in control of their identity.

5. Progressive

Users can start simply and evolve over time.

6. Decentralized

A cloud app like indx.earth serves as a registry and coordination layer, not the owner of identity.


The Eight Levels

Note: Every level of this model can be automated, allowing a user's PID to stay current with minimal manual effort. No coding is required. Using a local AI agent application (such as Codex Desktop or Claude Desktop) along with a small collection of skill documents written in plain English, users can automate the observation, summarization, organization, and updating of their PID. For many users, this can be accomplished using free or low-cost AI subscription plans. Refer to the README.md for these instructions.

Level 1 — Basic PID Document

Structure

A single public document:

  • Google Doc
  • OneDrive document
  • Markdown file
  • PDF

URL Accessible: This is important. Store your PID in a location that can generate a public URL, such as Google Drive, Microsoft OneDrive, or a public Git repository. If your PID is saved as a PDF, you can also use many other cloud storage services. Share the URL rather than a static copy whenever possible. This ensures that others—and AI systems—always access the most current version of your PID as you update it over time. Avoid distributing standalone files that can quickly become outdated.

Purpose

Replace the resume.

Why

This is the lowest-friction entry point.

Most users can create a meaningful PID in a short amount of time using automation that can be found via the README.md file for this repo.

Characteristics

  • Human readable
  • Public URL
  • Easy to update
  • Minimal technical skills required

Level 2 — Structured PID Document

Structure

One document with consistent sections.

Examples:

  • Open To
  • What I Have
  • What I Need
  • Current Focus
  • Interests
  • History
  • Credibility
  • Identity Layer
  • Proof of Work
  • Additional Signals
  • Match Context
  • Update Log

Use the PID template (PID-Template.md) as a guide

Purpose

Improve AI comprehension.

Why

AI performs substantially better when information is consistently organized.

Benefits

  • Better retrieval
  • Better matching
  • Better reasoning
  • Easier future migration

Level 3 — PID Repository

For Level 3 and above, it is recommended to transition a PID to a Git repository, like Github.com, which is free.

Structure

pid/
├── README.md
└── docs/

Purpose

Break identity into logical knowledge objects.

Why

Large identity documents become difficult to maintain.

Separating content allows:

  • easier updates
  • better retrieval
  • modular growth

Benefits

  • Better organization
  • Better maintainability
  • Better AI retrieval

Level 4 — Structured PID Repository

Structure

pid/
├── README.md
├── docs/
└── data/

Purpose

Create machine-readable identity.

Why

Agents should not have to parse prose when structured data is available.

Example Data Files

data/
├── interests.json
├── needs.json
├── chronology.json
├── identity.json
├── credibility.json
└── trust-signals.json

Benefits

  • Deterministic retrieval
  • Easier matching
  • Easier automation
  • Future API compatibility

Level 5 — Agent-Native PID

Structure

pid/
├── README.md
├── docs/
├── data/
├── ai-index.json
├── llms.txt
├── agents.md
├── skills.md
├── agent-card.json
└── security.txt

Purpose

Make the PID explicitly AI-native.

Why

AI agents increasingly need guidance.

These files tell agents:

  • what exists
  • how to retrieve it
  • how to reason over it
  • how to update it

Benefits

  • AI discoverability
  • AI interoperability
  • Agent compatibility
  • Future-proofing

Level 6 — Published Identity Site

Structure

PID Repo
     ↓
 Static Site Builder
     ↓
 Website

Example:

github.com/user/pid
       ↓
 Hugo
       ↓
 user.com/pid

Purpose

Increase discoverability.

Why

While the PID is designed to be accessible to specific networks, like paddlenet.earth, a user can increase the surface area for findability by turning their PID into a website.

Benefits

  • SEO - search engine optimization
  • GEO/AEO - generative engine optimization and answer engine optimization
  • AI discovery
  • Public visibility

Important

For many users, Level 5 may be sufficient.

Level 6 is optional.

For advanced users, the PID becomes part of a larger corpus.

Example:

eddiesoehnel.com
├── PID
├── Working Papers
├── Research
├── Projects
├── Presentations
└── Archives

The PID becomes one component of a larger AI-native knowledge system.


Agent-Maintained PID

Structure

Local Files
Calendar
Email
Projects
Research
Notes
Git Repos
      ↓
 Local Agent
      ↓
 Draft Update
      ↓
 Human Review
      ↓
 PID Update

Purpose

Reduce maintenance burden.

Why

People will not manually maintain rich profiles indefinitely—and even if they wanted to, it becomes increasingly difficult over time. Each week we learn new things, complete projects, build relationships, create content, solve problems, and gain experiences that may be valuable signals to others. Capturing and organizing all of that manually is unrealistic. Instead, we want to delegate the ongoing observation, summarization, and cataloging of our activities to an AI agent, allowing it to identify meaningful changes, draft updates, and help keep our PID current with minimal effort. Access the README.md file for instructions on easily building your own agent to do this.

Workflow

  1. Agent scans local sources
  2. Agent identifies changes
  3. Agent creates update draft
  4. User reviews
  5. User approves
  6. PID updates

Benefits

  • Freshness
  • Accuracy
  • Reduced effort
  • Higher signal quality

Level 8 — Agent-to-Agent Networking

Structure

Agent
   ↓
 PID
   ↓
 Registry
   ↓
 Other PIDs
   ↓
 Other Agents

Purpose

Enable decentralized professional networking.

Why

The future is likely not people networking with people.

It is agents discovering, evaluating, and coordinating opportunities.

Benefits

  • Opportunity discovery
  • Collaboration discovery
  • Automated introductions
  • Continuous matching

Recommended Advanced PID Repository in A Git Repo

pid/
├── README.md
├── pid.json
├── ai-index.json
├── llms.txt
├── agents.md
├── skills.md
├── agent-card.json
├── security.txt
│
├── docs/
│   ├── 00-overview.md
│   ├── 01-open-to.md
│   ├── 02-what-i-have.md
│   ├── 03-what-i-need.md
│   ├── 04-current-focus.md
│   ├── 05-interests-passions-talents.md
│   ├── 06-history.md
│   ├── 07-credibility.md
│   ├── 08-identity-layer.md
│   ├── 09-proof-of-work.md
│   ├── 10-additional-signals.md
│   ├── 11-match-context.md
│   ├── 12-update-log.md
│   └── 13-appendix-guidance.md
│
├── data/
│   ├── assets.json
│   ├── needs.json
│   ├── interests.json
│   ├── chronology.json
│   ├── credibility.json
│   ├── identity.json
│   ├── proof-of-work.json
│   ├── signals.json
│   ├── match-context.json
│   ├── updates.json
│   └── trust-signals.json
│
└── derived/
    ├── chunks.json
    └── qa.json

Cloud App Role

A cloud app like paddlenet.earth is not intended to own identity.

Its role is:

  • PID registry
  • Discovery layer
  • Validation layer
  • Metadata layer
  • Trust layer
  • Ontology layer
  • Change notification layer

It should not require centralized storage of personal knowledge.

Instead:

Person Owns PID
       ↓
Cloud app is the registry layer of PID links along with certain metadata to help agents
       ↓
Agents Discover PID

Long-Term Vision

The PID is not the destination.

The PID is the public interface between:

Private Agent
       ↔
Public Identity
       ↔
Network Agents

Over time:

Resume
   ↓
PID
   ↓
PID Repository
   ↓
Agent-Native PID
   ↓
Agent-Maintained PID
   ↓
Agent-to-Agent Networking