An open, agent-ready standard for professional profiles.
The Open Talent Protocol is an open, machine-first data standard for representing a person's professional profile. It defines a single JSON document format that any platform, tool, or autonomous agent can read, write, and reason over — without depending on a specific vendor.
Think of it as a resume designed to be read by software first, and rendered for humans second.
This repository contains:
- The JSON Schema defining the format (
schema/) - Example documents for three different professions (
examples/) - Documentation including design principles and migration guides (
docs/) - A validator CLI for checking documents against the schema (
tools/validator-cli/)
Existing resume formats — PDF, Word, LinkedIn exports, even JSON Resume — were designed for humans reading documents or for single-platform use. As autonomous hiring agents and career assistants become real, we need a format that:
- Encodes job preferences as first-class structured data, not cover letter prose
- Carries verification and provenance metadata so agents can weight claims
- Includes privacy controls so candidates decide what to share and with whom
- Is owned by the candidate, importable anywhere, and exportable everywhere
The Open Talent Protocol is that format.
The Open Talent Protocol is the canonical profile format for the JobGrow agentic career marketplace, but it is deliberately designed to be vendor-neutral. Any platform can implement it. Any candidate can export a conforming document and import it elsewhere without data loss.
The standard builds on prior art:
- JSON Resume — vocabulary and field naming; OTP is a superset. See
docs/migration-json-resume.md. - schema.org — OTP fields map naturally to
Person,Occupation, and related types, enabling JSON-LD compatibility. - HR-XML / HR Open Standards — reference for enterprise HR data modeling; OTP covers the candidate-facing slice. See
docs/migration-hrxml.md.
v0.2 is proposed in this repo alongside v0.1. It restructures OTP for agent-to-agent exchange transactions where token cost and data privacy are the primary constraints.
The key addition is progressive disclosure — three tiers that control how much data agents see at each stage:
| Tier | Name | ~Tokens | Use case |
|---|---|---|---|
| 1 | metadata |
~100 | Initial screening (80% of traffic) — name, title, location, salary |
| 2 | profile |
~500–800 | Deep matching — full skills, experience, education |
| 3 | deep |
~2,000+ | Final evaluation — work samples, references, assessments |
The schema enforces tier boundaries: a metadata payload cannot contain skills or experience.
v0.2 schema: schema/v0.2/otp.schema.json
v0.2 examples:
| File | Tier | Profile |
|---|---|---|
software-engineer.json |
profile | Lena Müller — Senior Backend Engineer, Berlin |
sales-manager.json |
metadata | Markus Weber — Sales Manager DACH, Munich |
nurse-practitioner.json |
deep | Fatima Al-Rashid — ICU Nurse Practitioner, Hamburg |
Migration guide: docs/v0.2-migration.md — full field mapping from v0.1 to v0.2.
The v0.1 schema is at schema/opentalent-protocol.schema.json.
It is a JSON Schema (draft 2020-12) document describing an object with these top-level sections:
| Section | Required | Description |
|---|---|---|
meta |
Yes | Schema version, language, source. |
identity |
Yes | Name, contact details, profiles, work authorization. |
summary |
No | Plain-text professional summary. |
work |
No | Chronological work history with highlights and impact metrics. |
education |
No | Formal education history. |
skills |
No | Normalized skill inventory with levels and categories. |
projects |
No | Selected projects with technologies and links. |
credentials |
No | Certifications and regulated licenses. |
languages |
No | Human language proficiencies (CEFR). |
preferences |
No | Agent-facing job search preferences and constraints. |
evidence |
No | Portfolio artifacts linked to skills and experience. |
verification |
No | Document provenance and integrity hash. |
visibility |
No | Privacy controls: default level and per-field overrides. |
custom |
No | Extension namespace for platform-specific fields. |
Three complete example documents are in examples/:
| File | Profile |
|---|---|
developer-junior.json |
Lukas Bauer — junior frontend developer in Berlin |
product-manager-senior.json |
Sofia Marchetti — Head of Product in EU fintech |
nurse-midcareer.json |
Marta Kowalczyk — mid-career oncology nurse in Warsaw |
These examples illustrate how preferences, verification, and visibility work in practice, and demonstrate that the schema is not developer-centric.
- Node.js 18+
- npm or a compatible package manager
# From the repo root
cd tools/validator-cli
npm install
npm run build
# Validate one of the example documents
node dist/index.js ../../examples/developer-junior.json
# Or validate your own document
node dist/index.js /path/to/your/profile.jsonSuccessful output:
✓ Valid Open Talent Protocol document
On failure, the validator prints a list of specific errors with JSON Pointer paths.
See docs/migration-json-resume.md for a field-by-field mapping. All core JSON Resume fields map to OTP; OTP adds preferences, verification, and visibility which must be populated separately.
See docs/migration-hrxml.md. The mapping is many-to-one in some areas and intentionally lossy for internal ATS fields (recruiter notes, workflow state, compensation history) that do not belong in a candidate-controlled document.
- Validate incoming documents with the validator CLI or by embedding
ajvin your application. - Index the
preferencessection first for matching; it is designed to be the primary filter. - Use
visibilityto enforce access controls before returning data to any consumer. - Use
customfor any platform-specific fields, namespaced as"yourplatform:fieldName".
| Document | Description |
|---|---|
docs/overview.md |
High-level explanation of goals and design. |
docs/design-principles.md |
Principles behind schema decisions. |
docs/migration-json-resume.md |
JSON Resume → OTP field mapping. |
docs/migration-hrxml.md |
HR-XML → OTP migration guide. |
docs/v0.2-migration.md |
v0.1 → v0.2 field mapping and migration guide. |
v0.1 is the current stable release — minimal but opinionated.
v0.2 is proposed alongside v0.1 as an RFC. It adds progressive disclosure tiers for exchange-based matching. See docs/v0.2-migration.md.
Planned for future versions:
- Extension schemas for specific verticals (healthcare, academia, legal)
- JSON-LD context document for schema.org compatibility
- Verifiable credentials integration (W3C VC)
The schema_version field in every document determines which schema applies.
The Open Talent Protocol is an open standard, not a product. JobGrow and neogene.ai are its initial sponsors and maintainers, but the specification is intended for broad ecosystem adoption. No single company has veto power over the spec, and the MIT license ensures that any organization can implement, fork, or build on OTP without asking permission.
Governance details — how decisions are made, how maintainers are added, and how conflicts are resolved — are documented in GOVERNANCE.md.
If the project gains adoption across multiple organizations, the intention is to move it under a neutral foundation or working group — for example, within the Linux Foundation AI & Data ecosystem, a future Agentic AI working group, or a similar open governance body. This is a direction, not a promise, but it is the direction we are building toward.
The spec will always be MIT-licensed. There will never be a "commercial version" of the core schema.
Owners, not renters. Individuals and organizations should own their profile data and their agents. The Open Talent Protocol exists to prevent lock-in: a conforming document can move between platforms without data loss and without negotiating with a vendor.
Privacy and fairness. The visibility section is first-class, not an afterthought. Candidates decide what to share, with whom, and when. Agents and platforms that consume OTP documents are expected to respect these controls.
Transparency. The verification and meta sections make the provenance of data explicit: who wrote it, when, and how it was verified. In an agentic world where software is making decisions about people's careers, opacity is a bug.
Interoperability. OTP maps to JSON Resume, HR-XML, and schema.org. It should be straightforward to bring data in from existing systems and to export it back out. Walled gardens are anti-features.
Issues and pull requests are welcome. Please open an issue before submitting a large change. See GOVERNANCE.md for how decisions are made and CODE_OF_CONDUCT.md for community standards.
MIT — Copyright (c) 2026 neogene.ai