Open Talent Protocol

Why Open Talent Protocol?

Existing resume formats — PDF, Word, LinkedIn exports — were designed for humans reading documents. As autonomous hiring agents and career assistants become real, we need a format that software can reason over reliably.

Open Talent Protocol (OTP) is that format. v0.2 restructures profiles around progressive disclosure — tiered payloads that control how much data is revealed at each stage of matching, so 80% of agent traffic can run on the cheapest models. OTP is the talent half of a bilateral ecosystem — its companion standard, the Open Job Protocol, handles the employer and job-posting side.

Goal	What it means in practice
Machine-first	JSON is the canonical format. Flat top-level fields, snake_case keys, and strict `additionalProperties: false` for reliable parsing.
Candidate-controlled	The `disclosure_tier` system is first-class. Profiles reveal only what the current matching stage requires — metadata for screening, full profile for deep matching, everything for final evaluation.
Agent-ready	`disclosure_tier`, `salary_band`, `work_model`, and `source` are structured fields agents can act on — not prose to be parsed.
Vendor-neutral	MIT licensed. No required registry, platform, or identity provider.
Interoperable	Clearly mappable to JSON Resume, HR-XML, and schema.org vocabularies. Full v0.1 migration guide included.

Quick start

Validate a document

The validator CLI checks any JSON file against the schema and prints readable errors.

# Install and build the validator
git clone https://github.com/neogene-ai/open-talent-protocol.git
cd open-talent-protocol/tools/validator-cli
npm install && npm run build

# Validate one of the v0.2 example documents
node dist/index.js ../../examples/v0.2/software-engineer.json
✓ Valid Open Talent Protocol document

Minimal valid document

A metadata-tier document needs only the 10 required top-level fields — about 100 tokens. This is enough for initial screening; upgrade to profile or deep as the pipeline progresses.

{
  "schema_version": "0.2.0",
  "otp_id": "550e8400-e29b-41d4-a716-446655440000",
  "created_at": "2026-03-30T10:00:00Z",
  "updated_at": "2026-03-30T10:00:00Z",
  "disclosure_tier": "metadata",
  "name": { "given": "Ada", "family": "Lovelace" },
  "title": "Software Engineer",
  "location": { "country": "GB", "city": "London" },
  "availability": "2_weeks",
  "work_model": ["remote"]
}

Schema reference

The full schema is a JSON Schema (draft 2020-12) document at schema/v0.2/otp.schema.json. Below, each section is documented with its fields, types, and intent.

Progressive disclosure: Every document declares a disclosure_tier (metadata, profile, or deep) that controls which fields are allowed. Start with metadata (~100 tokens) for initial screening; upgrade to profile or deep as the hiring pipeline progresses. The schema enforces tier boundaries with if/then rules.

Looking for v0.1? The v0.1 schema remains available. See the v0.1 → v0.2 migration guide for a full field mapping.

Progressive disclosure tiers

required

The disclosure_tier field controls how much data a profile payload contains. Tier boundaries are enforced by the schema — a metadata payload that includes skills will fail validation.

Tier	Name	Fields included	~Tokens	Use case
1	metadata	name, title, location, availability, work_model, salary_band, visa_status	~100	Initial screening (80% of traffic)
2	profile	All Tier 1 + summary, skills, experience, education, certifications, languages, industries, seniority, notice_period, preferences, relocation, source	~500–800	Deep matching
3	deep	All fields including work_samples, references, extended_history, assessments, europass_credential	~2,000+	Final evaluation

Design note: At the profile tier, skills, experience, and source become required. At the deep tier all fields are permitted, including work samples, references, and assessments.

Top-level fields

required all tiers

Every OTP v0.2 document must include these 10 required fields, regardless of disclosure tier.

Property	Type	Req.	Description
schema_version	string	yes	Must be `"0.2.0"`.
otp_id	uuid	yes	Unique profile identifier for exchange transactions.
created_at	date-time	yes	Profile creation timestamp (ISO 8601).
updated_at	date-time	yes	Last modification timestamp (ISO 8601).
disclosure_tier	enum	yes	Controls progressive disclosure: metadataprofiledeep
name	object	yes	Structured name: `given` (required), `family` (required), `display` (optional).
title	string	yes	Current professional title. Max 200 characters.
location	object	yes	`country` (ISO 3166-1 alpha-2, required), `city`, `region`, `coordinates` (`lat`/`lon`).
availability	enum	yes	immediate2_weeks1_month 3_monthspassiveunavailable
work_model	enum[]	yes	One or more accepted work arrangements: onsitehybridremote

salary_band

optional Tier 1

Desired compensation range. Available at all tiers for screening.

Property	Type	Req.	Description
min	number	yes	Minimum acceptable salary.
max	number	yes	Maximum / target salary.
currency	string	yes	ISO 4217 currency code (e.g. `"EUR"`, `"USD"`).
period	enum	yes	annualmonthlyhourly

visa_status

optional Tier 1

Work authorization status for agent-driven location matching.

Property	Type	Req.	Description
requires_sponsorship	boolean	yes	Whether the candidate requires visa sponsorship.
authorized_countries	string[]	yes	ISO 3166-1 alpha-2 country codes where the candidate is authorized to work.

summary

optional Tier 2+

A short professional summary (max 500 characters). Plain text only — no markup. Agents may use this as context but should rely on structured fields for matching.

skills

optional Tier 2+

Skill inventory with numeric proficiency levels for machine scoring. Required at profile and deep tiers.

Property	Type	Req.	Description
name	string	yes	Canonical skill name (max 100). E.g. `"TypeScript"`, `"Kubernetes"`.
level	integer	yes	Proficiency 1–5. Numeric levels enable scoring without string mapping.
years	number	no	Years of practical experience.
esco_id	string	no	ESCO taxonomy skill identifier (e.g. `"S5.6.1"`).

experience

optional Tier 2+

Work history array. Required at profile and deep tiers.

Property	Type	Req.	Description
company	string	yes	Employer or client name (max 200).
title	string	yes	Job title or role name (max 200).
start_date	date	yes	ISO 8601 date (YYYY-MM-DD).
end_date	date	no	Omit if current position.
location	string	no	Work location (max 200). E.g. `"Berlin, DE"`.
description	string	no	Role description and accomplishments (max 2000).

education

optional Tier 2+

Education history.

Property	Type	Req.	Description
institution	string	yes	Name of the institution (max 200).
degree	string	yes	Degree type (max 100). E.g. `"M.Sc."`, `"Ausbildung"`.
field	string	yes	Field or major of study (max 200).
status	enum	yes	Outcome of the education: completedin_progressincomplete Resolves ambiguity when `graduation_date` is missing.
graduation_date	string	no	Year-month format: `YYYY-MM`.

certifications

optional Tier 2+

Professional certifications and licenses.

Property	Type	Req.	Description
name	string	yes	Certification name (max 200). E.g. `"CKA"`, `"ACLS"`.
issuer	string	yes	Issuing organization (max 200).
date	date	yes	Date of issue (ISO 8601).
credential_id	string	no	Certificate or license ID (max 100).
url	uri	no	Link to the credential record.

languages

optional Tier 2+

Language proficiencies using the CEFR scale.

Property	Type	Req.	Description
language	string	yes	ISO 639-1 language code (e.g. `"de"`, `"en"`).
proficiency	enum	yes	A1A2B1B2C1C2native

industries

optional Tier 2+

Array of industry experience strings (max 100 chars each). E.g. "Healthcare", "B2B SaaS", "Hospital — Acute Care".

seniority

optional Tier 2+

Career level:

internjuniormid seniorleadprincipal directorvpc_level

notice_period

optional Tier 2+

Current contractual notice period.

Property	Type	Req.	Description
days	integer	yes	Notice period in calendar days.
negotiable	boolean	yes	Whether the notice period can be shortened.

preferences

optional Tier 2+

Candidate preferences for agent matching beyond the required top-level fields.

Property	Type	Req.	Description
company_size	enum[]	no	startupscaleupmid_marketenterprise
industries	string[]	no	Preferred industries (max 100 chars each).
tech_stack	string[]	no	Preferred technologies to work with.
culture_values	string[]	no	Valued cultural traits. E.g. `"Work-life balance"`.

relocation

optional Tier 2+

Relocation willingness.

Property	Type	Req.	Description
willing	boolean	yes	Whether the candidate is open to relocating.
target_locations	string[]	no	Preferred relocation destinations (max 100 chars each).

source

optional Tier 2+

Data provenance and GDPR consent tracking. Required at profile and deep tiers. Replaces v0.1's verification section.

Property	Type	Req.	Description
agent_id	string	yes	Identifier of the agent that created or submitted this profile (max 200).
platform	string	no	Platform name (max 200). E.g. `"honeypot.io"`.
consent_type	enum	yes	GDPR legal basis: consentlegitimate_interest
consent_date	date	yes	Date consent was obtained (ISO 8601).

GDPR note: Every profile- or deep-tier payload must include source with a consent basis and date. This ensures agents handling personal data can trace provenance and demonstrate lawful processing.

work_samples

optional Tier 3

Portfolio, code, or writing samples for final evaluation.

Property	Type	Req.	Description
title	string	yes	Sample title (max 200).
url	uri	yes	Link to the work sample.
type	enum	yes	portfoliogithubpublication
description	string	no	What this sample demonstrates (max 1000).

references

optional Tier 3

Professional references.

Property	Type	Req.	Description
name	string	yes	Reference name (max 200).
relationship	string	yes	Professional relationship (max 200). E.g. `"Head of Cardiac ICU, UKE"`.
contact	string	no	Contact information (max 200).
available	boolean	yes	Whether this reference is available to contact.

extended_history

optional Tier 3

Additional history: projects, volunteer, awards, and patents. Each is an array of objects. Provides depth for final-stage evaluation without inflating earlier tiers.

assessments

optional Tier 3

Coding tests, psychometrics, clinical competency assessments, etc.

Property	Type	Req.	Description
type	string	yes	Assessment type (max 100). E.g. `"Clinical Competency Assessment"`.
provider	string	yes	Assessment provider (max 200).
score	string	yes	Result (max 100). E.g. `"Exceeds expectations"`, `"92/100"`.
date	date	yes	Assessment date (ISO 8601).
url	uri	no	Link to assessment results.

Examples

Three schema-conforming v0.2 documents are included in the repository. They demonstrate the three disclosure tiers and show how source, salary_band, and tier-enforced progressive disclosure work in practice.

Backend Engineering

Lena Müller

Profile tier. Senior backend engineer in Berlin with Rust/Go skills, salary band, and ESCO taxonomy IDs.

Sales

Markus Weber

Metadata tier only (~14 lines). Demonstrates the minimal screening payload at ~100 tokens.

Healthcare

Fatima Al-Rashid

Deep tier. ICU nurse with work samples, references, assessments, and extended volunteer history.

Tools

Validator CLI

A Node.js CLI that validates any JSON file against the OTP schema and prints readable errors. Source: tools/validator-cli/

cd tools/validator-cli
npm install && npm run build
node dist/index.js path/to/profile.json

Agent tools

TypeScript stubs for integrating OTP into MCP-compatible agent frameworks. Source: tools/agent-examples/

Provides two composable functions ready to be registered as MCP tools: validateProfile and introspectProfile.

MCP server

A standalone MCP server exposing all 6 OTP/OJP agent tools (validate, introspect, parse for both schemas). Source: tools/mcp-server/

Migration

OTP is designed to be clearly mappable to and from existing formats.

Format	Guide	Notes
OTP v0.1	v0.2-migration.md	Full field mapping, structural changes (flat vs nested, camelCase vs snake_case), and tier system explanation. v0.1 schema remains available.
JSON Resume	migration-json-resume.md	Full field-by-field table. OTP is a superset; mapping is lossless for all core fields.
HR-XML	migration-hrxml.md	High-level conceptual guide. Internal ATS fields (recruiter notes, workflow state) are intentionally dropped.

Ecosystem

OTP defines the talent side of agentic marketplaces. It is designed to work alongside complementary open standards that together cover both sides of the hiring equation.

Open Job Protocol (OJP) is the employer-side counterpart to OTP — a machine-first, vendor-neutral JSON standard for structuring job postings. OJP captures structured requirements (must-have vs nice-to-have skills), compensation transparency, and hiring-process metadata so employer agents can publish opportunities that talent agents can parse without scraping or guesswork.

openjobprotocol.org · GitHub repository

Together, OTP + OJP enable fully structured, agent-driven bilateral matching. Candidates express preferences and constraints in their OTP profile; employers express requirements and offer details in an OJP posting. Agents on both sides can evaluate fit and negotiate programmatically — no unstructured job-board listings or PDF resumes required.

Governance & neutrality

Open Talent Protocol is vendor-neutral. JobGrow and neogene.ai are its initial sponsors, but the spec is designed for broad ecosystem adoption. No single company has veto power over the schema. The same community is developing the Open Job Protocol as a companion standard for the employer side.

The project is governed by a maintainer council using lazy consensus. See GOVERNANCE.md for the full process, and docs/governance-roadmap.md for the long-term direction (including possible neutral foundation hosting).

Licensed under MIT. The spec will always be free to implement.