# **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 ```text 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 ```text 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 ```text 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 ```text 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 ```text PID Repo ↓ Static Site Builder ↓ Website ``` Example: ```text 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: ```text 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 ```text 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 ```text 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 ```text 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: ```text 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: ```text Private Agent ↔ Public Identity ↔ Network Agents ``` Over time: ```text Resume ↓ PID ↓ PID Repository ↓ Agent-Native PID ↓ Agent-Maintained PID ↓ Agent-to-Agent Networking ```