added

2026-06-15 12:14:26 -06:00 · 2026-06-15 12:14:26 -06:00 · abae43dc91
commit abae43dc91
parent d24a2be42a
1 changed files with 488 additions and 0 deletions
--- a/PID-Maturity-Model-Roadmap.md
+++ b/PID-Maturity-Model-Roadmap.md
@ -0,0 +1,488 @@
 # PID Maturity Model & Roadmap
 ## From Resume to Agent-Native Identity
 # 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
 ```