Applicant Profile Protocol (APP)

Version: 1.0.0 (Draft) Status: Draft Authors: Community-driven

1. Overview

The Applicant Profile Protocol (APP) is an open, JSON-based specification for representing a job applicant's professional profile in a structured, interoperable, and extensible manner.

APP is designed to act as a canonical source of truth for applicant data, enabling lossless export to existing formats such as ATS schemas, HR-XML, Europass, JSON Resume, and document-based formats (PDF, DOCX).

Key properties:

1.1 Why APP? (Motivation)

The Problem

Existing standards for representing applicant/resume data are fragmented, outdated, or locked to specific vendors:

StandardLimitation
HR-XMLHeavyweight XML, enterprise-focused, not developer-friendly
EuropassEU-specific, tied to government infrastructure, not AI-ready
JSON ResumeDeveloper-friendly but limited: no confidence metrics, no semantic layer, no evidence support
ATS Vendor APIsProprietary, fragmented, no interoperability between platforms

How APP Solves This

APP combines the best ideas from all existing standards into one modern, open protocol:

  1. Canonical Source of Truth — APP is the master format; export to HR-XML, Europass, JSON Resume, or any ATS without data loss.
  2. AI & ML Ready — Built-in support for skill confidence scores (0.0–1.0), usage recency, embedding references, and JSON-LD semantic layer.
  3. Verifiable Evidence — Optional evidence layer supports credential URLs, hashes, and W3C Verifiable Credentials.
  4. Developer-First — JSON format, readable schema, simple validation, modern tooling.
  5. Enterprise-Ready — Layered architecture scales from simple profiles to rich enterprise data.
  6. Open Governance — Community-driven, no vendor lock-in, Apache-2.0 license.

2. Definitions

Normative keywords: MUST, SHOULD, MAY follow RFC 2119 semantics.

2.1 Namespace and Identifiers

The canonical namespace for the Applicant Profile Protocol (APP) is:

https://app-protocol.org/

All specifications, schemas, and extensions MUST use this namespace.

3. Design Goals

Non-goals:

4. Protocol Architecture

Applicant Profile Protocol (APP) uses a layered model:

Only the Core Layer is required for protocol compliance.

5. Core Layer (Required)

5.1 Top-Level Structure

{
  "protocol": {
    "name": "ApplicantProfileProtocol",
    "shortName": "APP",
    "version": "1.0.0",
    "uri": "https://app-protocol.org/spec/1.0",
    "id": "urn:app-protocol:profile:<uuid>"
  },
  "basics": {},
  "experience": [],
  "education": [],
  "skills": [],
  "projects": [],
  "credentials": [],
  "languages": [],
  "preferences": {},
  "metadata": {},
  "semantic": {},
  "enrichment": {},
  "evidence": []
}

5.2 basics

{
  "name": { "given": "First", "family": "Last", "middle": "Optional" },
  "headline": "Professional title",
  "summary": "Short professional summary (max 2000 chars)",
  "location": {
    "country": "US",
    "region": "Texas",
    "city": "Austin",
    "remote": true
  },
  "contact": {
    "email": "user@example.com",
    "phone": "+1-555-555-5555",
    "website": "https://example.com",
    "social": [
      { "label": "GitHub", "url": "https://github.com/username" }
    ]
  }
}

5.3 experience

{
  "role": "Job title",
  "organization": { "name": "Company", "industry": "Technology" },
  "start": "YYYY-MM",
  "end": "YYYY-MM",
  "current": true,
  "employmentType": "Full-time",
  "highlights": ["Key achievement"],
  "technologies": ["Tech used"]
}

5.4 education

{
  "institution": "University name",
  "area": "Field of study",
  "degree": "Degree or certification",
  "start": "YYYY",
  "end": "YYYY",
  "completed": true,
  "grade": "GPA or classification"
}

5.5 skills

{
  "name": "Skill name",
  "category": "ProgrammingLanguage | Framework | Tool | SoftSkill | Domain",
  "level": "Beginner | Intermediate | Advanced | Expert",
  "years": 5,
  "confidence": 0.85,
  "usage": { "lastUsed": "YYYY-MM", "contexts": ["Backend"] },
  "evidenceRef": ["cred:aws-sa-2024"]
}
Note: confidence is self-reported or computed (0.0–1.0). Exporters MAY ignore unsupported fields.

5.6 projects

{
  "name": "Project name",
  "description": "Short description",
  "role": "Contributor role",
  "stack": ["Technologies"],
  "links": { "website": "https://...", "repository": "https://..." },
  "highlights": ["Impact or result"]
}

5.7 credentials

{
  "name": "Credential name",
  "issuer": "Issuing organization",
  "date": "YYYY-MM",
  "id": "Credential identifier",
  "url": "https://issuer.example/verify/123"
}

5.8 languages

{
  "name": "Language name",
  "proficiency": "Basic | Conversational | Professional | Fluent | Native"
}

5.9 preferences

{
  "employmentType": ["Full-time", "Contract"],
  "workMode": ["Remote", "Hybrid"],
  "relocation": false,
  "preferredLocations": ["US-CA", "US-TX"]
}

5.10 metadata

{
  "created": "ISO-8601 timestamp",
  "updated": "ISO-8601 timestamp",
  "source": "SelfReported | Imported | Generated",
  "tags": ["keyword-1", "keyword-2"]
}

6. Enrichment Layer (Optional)

The enrichment layer adds analytical or AI-oriented data:

This layer MUST NOT alter core semantics.

7. Semantic Layer (Optional)

APP supports JSON-LD for semantic interoperability:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Example Person",
  "knowsAbout": [
    { "@type": "DefinedTerm", "name": "TypeScript", "inDefinedTermSet": "ESCO" }
  ]
}

The semantic layer MAY reference: Schema.org, ESCO, O*NET, or custom vocabularies.

8. Evidence Layer (Optional)

Evidence provides verifiable backing for claims:

9. Export Layer

APP is designed to export into:

Exporter guidance: Preserve meaning, gracefully degrade unsupported fields, avoid lossy round-trips. APP JSON is the source of truth.

10. Versioning

11. Security & Privacy Considerations

12. Governance (Proposed)

13. Future Extensions (Non-Normative)

14. Examples

See examples/minimal.json and examples/full.json.

15. Changelog