GitHub - TalentProof/workproof-schema: An open specification for verified professional knowledge graphs

An open specification for verified professional knowledge graphs.

WorkProof is a structured, artifact-derived representation of what a professional can actually do — built from verifiable work evidence, not self-reported claims. This repository defines the open schema, evidence model, attestation format, and agent card extension that make up the WorkProof protocol.

Status: Draft v0.1 — open for community feedback
Maintained by: TalentProof
License: MIT

The problem

Every professional profile system in existence today is built on the same flawed primitive: the self-reported claim. You say you know React. You say you led a team of 10. You say you shipped at scale. There is no structural way for the person reading your profile to know if any of it is true.

AI is accelerating the problem, not solving it. Recruiters are already deploying AI sourcing tools — Juicebox, Moonhub, SeekOut and others — that autonomously search millions of profiles, score candidates, and send outreach at scale. These tools run faster than any human recruiter, but they still depend on the same flawed input: self-reported text. The signal problem doesn't go away when you automate around it. It compounds.

The next wave goes further. As recruiter agents and candidate agents begin communicating directly — negotiating fit, verifying claims, routing opportunities without human intervention at every step — the absence of structured, machine-readable professional signal becomes a hard blocker. An agent cannot evaluate a paragraph. It needs structured data with explicit confidence scores derived from verifiable evidence. Something has to replace the resume at the schema level.

WorkProof is that replacement.

What WorkProof is

A WorkProof graph is generated from verifiable work artifacts — code commits, document authorship, assessment results, project records — and structured into named skill clusters with confidence scores derived from evidence weight, not self-report.

It has five components:

Component	What it captures
Skill clusters	Named domains with confidence scores and evidence citations
Execution depth	The scale and context in which skills were applied
Growth velocity	How fast the graph is expanding into new domains
Collaboration graph	Peer signals derived from co-authorship patterns
Attestations	Cryptographically signed employer or institution credentials (W3C VC)

A WorkProof is not a resume. It does not contain job titles, company names (unless attested), or self-written descriptions. It contains structured evidence of capability, derived from artifacts, with explicit confidence scores that reflect the quality of evidence available.

Schema specification

Root document

{
  "$schema": "https://raw.githubusercontent.com/TalentProof/workproof-schema/main/schema/v0.1.json",
  "specVersion": "0.1",
  "generatedAt": "2026-04-27T10:00:00Z",
  "updatedAt": "2026-04-27T10:00:00Z",
  "summary": "string (≤280 chars, AI-generated, describes candidate strengths)",
  "growthEdge": "string (≤140 chars, where the candidate is developing toward)",
  "growthVelocity": 0.73,
  "skillClusters": [],
  "collaborationGraph": {},
  "sources": [],
  "attestations": [],
  "agentCard": {}
}

Skill cluster

A skill cluster is a named professional domain, derived from artifact analysis, with a confidence score that reflects the weight and breadth of available evidence.

{
  "id": "frontend-engineering",       // stable machine identifier, kebab-case
  "name": "frontend-engineering",     // human-readable slug (may be same as id in v0.1)
  "displayName": "Frontend Engineering", // display label for UIs
  "confidence": 0.91,
  "executionDepth": {
    "scale": "production-scale",
    "context": "React at >100k MAU, three shipped products, one open-source library with 400+ stars"
  },
  "evidence": [
    {
      "type": "github",
      "sourceId": "github:repos:react-dashboard",
      "description": "847 commits, primary author, TypeScript + React",
      "weight": 0.45,
      "verifiedAt": "2026-04-20T00:00:00Z"
    },
    {
      "type": "assessment",
      "sourceId": "talentproof:assessment:frontend-q3-2025",
      "description": "Frontend fundamentals assessment, score 94/100",
      "weight": 0.35,
      "verifiedAt": "2025-09-15T00:00:00Z"
    },
    {
      "type": "attestation",
      "sourceId": "attestation:acme-corp-2024",
      "description": "Employer-attested: shipped three production React apps",
      "weight": 0.20,
      "verifiedAt": "2024-12-01T00:00:00Z"
    }
  ],
  "lastUpdated": "2026-04-27T10:00:00Z"
}

Confidence score guide

Range	Label	Meaning
0.85 – 1.0	Strong evidence	Multiple high-weight sources, consistent signal
0.60 – 0.84	Growing expertise	Solid evidence, some breadth still developing
0.35 – 0.59	Early signals	Emerging evidence, thinner artifact base
0.00 – 0.34	Exploratory	Initial activity, not enough to make strong claims

Confidence scores must be derived from evidence weights — they cannot be self-reported or manually overridden by the candidate.

Execution depth

{
  "scale": "personal | team | org | production-scale",
  "context": "string (≤200 chars, specific and honest — not marketing copy)"
}

Scale definitions:

personal — side project, solo work, learning context
team — shipped within a team of 2–10
org — cross-team impact, org-wide adoption
production-scale — shipped to real users at meaningful scale

Evidence types

Type	Source	Trust level
`assessment`	Standardized skill assessment (e.g. TalentProof)	High — third-party scored
`github`	GitHub contributions, commits, repos, PRs	Medium-high — artifact-derived
`document`	Authored documents, PRDs, specs (Google Drive, Notion)	Medium — authorship-derived
`jira`	Ticket ownership, resolution patterns	Medium — work record
`academic`	University coursework, thesis, capstone projects — institution-verified	Medium — institution-derived
`bootcamp`	Structured training program completion and projects — program-verified	Medium — program-derived
`certification`	Industry or platform certification — proctored, time-limited, provider-verifiable	Medium-high — provider-verified
`course`	Platform-verified course completion (Coursera, Google, Microsoft Learn)	Medium — platform-verified
`attestation`	Employer or institution-signed WorkProof credential	Highest — cryptographically verified
`peer`	Peer vouching via C2C graph (co-authorship based)	Medium — network-derived

Evidence weight ranges:

attestation: 0.15 – 0.40 per item
assessment: 0.25 – 0.45 per item
certification: 0.15 – 0.30 per item (scales with provider credibility and scope)
github: 0.05 – 0.35 per item (scales with commit depth and consistency)
academic: 0.10 – 0.25 per item
bootcamp: 0.10 – 0.20 per item
course: 0.08 – 0.20 per item
document: 0.05 – 0.20 per item
peer: 0.05 – 0.15 per item

Total evidence weights for a cluster should not exceed 1.0. Implementations must cap and normalise when multiple sources overlap.

Collaboration graph

The collaboration graph captures peer signal derived from co-authorship and verified collaboration — not endorsements or self-reported team size.

{
  "peerCount": 12,
  "verifiedCollaborations": 4,
  "domains": ["frontend-engineering", "developer-tooling"],
  "c2cEdges": [
    {
      "peerHandle": "string (opaque, platform-specific)",
      "sharedClusters": ["frontend-engineering"],
      "collaborationStrength": 0.78,
      "evidenceBasis": "github-co-authorship | attestation-cosignature | peer-vouching"
    }
  ]
}

c2cEdges are only included in full WorkProof responses (consent level L3 or higher). Public WorkProof summaries show only peerCount, verifiedCollaborations, and domains.

Sources

Sources record which connectors have contributed to the WorkProof graph and when they were last indexed.

[
  {
    "type": "github | google-drive | notion | jira | confluence | assessment | slack | microsoft-learn | google-learn | credly | university | bootcamp",
    "connectedAt": "2026-03-01T00:00:00Z",
    "lastIndexed": "2026-04-27T00:00:00Z",
    "status": "active | error | disconnected",
    "artifactCount": 847
  }
]

Attestations

Attestations are employer-issued WorkProof credentials. They are cryptographically signed, candidate-gated, and based on artifacts — not on subjective human authorship.

The trust model: the employer reviews and signs facts they did not write. The attestation content is generated from the employee's work artifacts. The employer is the notary, not the author.

[
  {
    "id": "att_01j8abc123",
    "issuerName": "Acme Corporation",
    "issuerDomain": "acme.com",
    "issuerDID": "did:web:acme.com",
    "issuerType": "employer | university | bootcamp | certification-body",
    "period": {
      "start": "2022-06-01T00:00:00Z",
      "end": "2024-12-01T00:00:00Z"
    },
    "attestedClusters": [
      {
        "clusterId": "frontend-engineering",
        "confidence": 0.88,
        "note": "Led three production React deployments. Primary author on core UI library."
      }
    ],
    "issuedAt": "2024-12-15T00:00:00Z",
    "candidateApproved": true,
    "revoked": false,
    "credential": "eyJ0eXAiOiJKV1Qi...",
    "credentialFormat": "jwt_vc | json_ld_vc"
  }
]

Attestations are based on the W3C Verifiable Credentials Data Model v2. Implementations should support both jwt_vc (compact, widely supported) and json_ld_vc (richer context, linked data).

Attestation generation flow

1. Employer deploys WorkProof Attestation Agent
   (reads GitHub, Jira, Confluence within company boundary)

2. Agent indexes employee's work artifacts
   → generates draft attestation (clusters + evidence + period)

3. Employee reviews draft
   → approves or requests edits
   → can revoke at any time after issuance

4. Employer reviews and signs
   → signs with company DID or registered signing key
   → issues W3C Verifiable Credential

5. Attestation stored in candidate's WorkProof graph
   → candidate controls which recruiters can see it
   → verifiable without contacting the employer
     (signature checked against employer's public DID)

Agent Card extension

WorkProof extends the A2A Agent Card with professional identity fields. A WorkProof-compatible agent card contains the standard A2A fields plus a workproof extension object.

{
  "name": "Candidate Agent — Priya Sharma",
  "description": "Professional agent representing Priya Sharma on TalentProof",
  "url": "https://talentproof.ai/agents/priyasharma",
  "version": "1.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false
  },
  "extensions": {
    "workproof": {
      "specVersion": "0.1",
      "profileUrl": "https://talentproof.ai/p/priyasharma",
      "availability": "passive",
      "consentLevel": 1,
      "topClusters": [
        { "name": "frontend-engineering", "confidence": 0.91 },
        { "name": "system-design", "confidence": 0.74 },
        { "name": "developer-tooling", "confidence": 0.61 }
      ],
      "hasAttestations": true,
      "sourceCount": 3,
      "trustScore": 0.82
    }
  }
}

The workproof extension exposes only public-facing fields (consent level L1). Deeper access requires negotiation through the WorkProof consent gate.

Consent gate

The WorkProof consent gate controls what a querying agent can access. Consent levels are scoped to a specific requester identity, a specific purpose (job spec context), and a time window.

Level	Label	Accessible data	Who can request
L0	Exists	Agent endpoint URL only	Anyone
L1	Summary	Top clusters (names + confidence), availability, source count, attestation flag	Any registered agent
L2	Domain query	Answer structured questions about specific skill domains	Verified recruiter agents
L3	Cited evidence	Specific proof points for claimed clusters	Verified recruiter agents with trust score ≥ 0.6
L4	Full graph	Complete WorkProof including collaboration edges and attestation detail	Explicit candidate approval per request

Consent levels are managed by the candidate through their WorkProof agent settings. Implementations must enforce consent levels server-side — the consent level declared in the agent card is the maximum; individual requests may be granted lower access.

Present consent to candidates as a simple availability dial:

Closed → L0 only
Passively open → L1 default, L2 on request
Actively looking → L1 default, L2 on request, L3 available to trusted recruiters

Do not expose L0–L4 terminology in candidate-facing UIs.

Growth velocity

Growth velocity is a 0–1 signal representing how actively a candidate's WorkProof graph is expanding into new domains over a rolling 12-month window.

growthVelocity = (newClusterCount × 0.4) 
               + (risingClusterDelta × 0.35) 
               + (newSourceConnections × 0.25)

Normalise to 0–1 based on platform-wide distribution.

A velocity of 0.7+ indicates a candidate actively expanding their professional surface area. A velocity of 0.2 or below indicates a stable but not actively growing practitioner. Neither is inherently better — recruiters should filter by velocity only when growth trajectory is explicitly required for a role.

Full WorkProof example

{
  "$schema": "https://raw.githubusercontent.com/TalentProof/workproof-schema/main/schema/v0.1.json",
  "specVersion": "0.1",
  "generatedAt": "2026-04-27T10:00:00Z",
  "updatedAt": "2026-04-27T10:00:00Z",
  "summary": "Frontend engineer with production-scale React experience and a secondary track record in developer tooling. Strong artifact base across three shipped products and one OSS library.",
  "growthEdge": "Moving into system design and distributed architecture, active GitHub signal in this area over the last 8 months.",
  "growthVelocity": 0.73,
  "skillClusters": [
    {
      "id": "frontend-engineering",
      "name": "frontend-engineering",
      "displayName": "Frontend Engineering",
      "confidence": 0.91,
      "executionDepth": {
        "scale": "production-scale",
        "context": "React at >100k MAU across three shipped products, one OSS library with 400+ stars"
      },
      "evidence": [
        {
          "type": "github",
          "sourceId": "github:repos:react-dashboard",
          "description": "847 commits, primary author, TypeScript + React",
          "weight": 0.45,
          "verifiedAt": "2026-04-20T00:00:00Z"
        },
        {
          "type": "assessment",
          "sourceId": "talentproof:assessment:frontend-q3-2025",
          "description": "Frontend assessment, score 94/100",
          "weight": 0.35,
          "verifiedAt": "2025-09-15T00:00:00Z"
        },
        {
          "type": "attestation",
          "sourceId": "att_01j8abc123",
          "description": "Employer-attested: led three production React deployments",
          "weight": 0.20,
          "verifiedAt": "2024-12-15T00:00:00Z"
        }
      ],
      "lastUpdated": "2026-04-27T10:00:00Z"
    },
    {
      "id": "developer-tooling",
      "name": "developer-tooling",
      "displayName": "Developer Tooling",
      "confidence": 0.61,
      "executionDepth": {
        "scale": "team",
        "context": "Built internal CLI tools adopted by 15-person engineering team"
      },
      "evidence": [
        {
          "type": "github",
          "sourceId": "github:repos:dev-cli",
          "description": "Primary author of internal CLI, 3 contributors",
          "weight": 0.55,
          "verifiedAt": "2026-02-10T00:00:00Z"
        },
        {
          "type": "peer",
          "sourceId": "peer:handle:anish-mehta",
          "description": "Co-authored tooling project, verified collaboration",
          "weight": 0.10,
          "verifiedAt": "2026-01-15T00:00:00Z"
        }
      ],
      "lastUpdated": "2026-04-27T10:00:00Z"
    }
  ],
  "collaborationGraph": {
    "peerCount": 8,
    "verifiedCollaborations": 3,
    "domains": ["frontend-engineering", "developer-tooling"]
  },
  "sources": [
    {
      "type": "github",
      "connectedAt": "2026-03-01T00:00:00Z",
      "lastIndexed": "2026-04-27T00:00:00Z",
      "status": "active",
      "artifactCount": 1204
    },
    {
      "type": "assessment",
      "connectedAt": "2025-09-10T00:00:00Z",
      "lastIndexed": "2025-09-15T00:00:00Z",
      "status": "active",
      "artifactCount": 2
    }
  ],
  "attestations": [
    {
      "id": "att_01j8abc123",
      "issuerName": "Acme Corporation",
      "issuerDomain": "acme.com",
      "issuerDID": "did:web:acme.com",
      "period": {
        "start": "2022-06-01T00:00:00Z",
        "end": "2024-12-01T00:00:00Z"
      },
      "attestedClusters": [
        {
          "clusterId": "frontend-engineering",
          "confidence": 0.88,
          "note": "Led three production React deployments."
        }
      ],
      "issuedAt": "2024-12-15T00:00:00Z",
      "candidateApproved": true,
      "revoked": false,
      "credentialFormat": "jwt_vc"
    }
  ],
  "agentCard": {
    "availability": "passive",
    "consentLevel": 1,
    "protocol": "workproof/v0.1"
  }
}

JSON Schema file

A machine-readable JSON Schema (schema/v0.1.json) is included in this repository for validation. Import it in your implementation:

import workproofSchema from 'workproof-schema/schema/v0.1.json'
import Ajv from 'ajv'

const ajv = new Ajv()
const validate = ajv.compile(workproofSchema)
const valid = validate(workproofDocument)

TypeScript types

import type { WorkProof, SkillCluster, Attestation, AgentCard } 
  from 'workproof-schema/types'

Types are published to npm as workproof-schema (coming soon).

Implementing WorkProof

Minimum viable implementation

A conforming WorkProof implementation must:

Generate skillClusters from at least one non-self-reported source (assessment, GitHub, document, or attestation)
Derive confidence scores from evidence weights — not user input
Enforce consent gate levels server-side
Store the full WorkProof graph locally or in an encrypted candidate-controlled store — not exposed by default
Expose only L1 data in the public agent card extension

Recommended stack

Component	Recommended
Graph storage	KuzuDB (embedded, local), Firestore (cloud)
Embedding model	text-embedding-004 (Google), or any 768-dim model
LLM for cluster generation	Gemini 1.5 Pro, GPT-4o, Claude Sonnet
Attestation signing	W3C VC JWT, did:web
Agent protocol	MCP (tools), A2A (agent-to-agent)

WorkProof for continuous learners

Professionals who actively learn through online platforms — Coursera, Microsoft Learn, Google Career Certificates, Udemy, LinkedIn Learning — are well-served by WorkProof, but the schema draws a deliberate distinction between verifiable completions and self-reported ones.

Two new evidence types

certification — industry or platform certifications that are externally proctored, time-limited, and verifiable against a provider registry. These carry higher weight because they cannot be inflated and require renewal.

course — structured learning program completions that are platform-verified (not self-reported). Lower weight than certifications because completion rigor varies, but valid evidence when the issuing platform provides external verification.

Verifiable vs self-reported: the critical distinction

WorkProof does not accept self-reported course completions as evidence. A certificate that anyone can generate by clicking through a course with no external verification is equivalent to typing "Python" on a resume — it adds nothing structurally. Every platform LinkedIn lets you list on your profile falls into this category. WorkProof draws the line differently.

Platform / credential	Verifiable?	Evidence type	Weight range
Microsoft certifications (AZ-900, MS-900, etc.)	Yes — Microsoft Transcript	`certification`	0.15 – 0.30
Google Career Certificates	Yes — Credly badge API	`course`	0.10 – 0.20
AWS / Azure / GCP certifications	Yes — provider registry	`certification`	0.20 – 0.35
GitHub Certifications (Actions, Copilot, Security)	Yes — GitHub API	`certification`	0.15 – 0.25
Coursera (with accredited university partner)	Yes — Credly / Coursera URL	`course`	0.08 – 0.15
Cisco, CompTIA, PMP, CKAD and similar	Yes — provider registry	`certification`	0.15 – 0.35
Udemy	No — self-generated certificate	Not standalone evidence
LinkedIn Learning	No — self-reported completion	Not standalone evidence
Coursera (no accredited partner)	No — self-generated	Not standalone evidence

The Udemy rule: artifacts over certificates

A Udemy certificate alone has no evidential weight in WorkProof. But a GitHub project built during or after a Udemy course does — because the project is a verifiable artifact. The course becomes context; the project is the evidence.

This is the correct model for all unverified learning:

Udemy ML course + no project     = 0 WorkProof evidence
Udemy ML course + GitHub project = GitHub evidence (course is context, not evidence)
Google ML cert  + no project     = course evidence (0.10 weight)
Google ML cert  + GitHub project = course evidence + github evidence (higher confidence)

Implementations should surface this to candidates clearly: “Connect your GitHub to show what you built with what you learned.” The combination of a verified certificate and an artifact project is meaningfully stronger than either alone.

Certification evidence example

{
  "type": "certification",
  "sourceId": "microsoft:transcript:AZ-900-2026",
  "description": "Microsoft Azure Fundamentals (AZ-900), passed March 2026",
  "weight": 0.22,
  "verifiedAt": "2026-03-15T00:00:00Z",
  "metadata": {
    "provider": "Microsoft",
    "certificationId": "AZ-900",
    "expiresAt": null,
    "verificationUrl": "https://learn.microsoft.com/api/credentials/..."
  }
}

Connectors for learning platforms

The following connectors are planned for WorkProof implementations:

Connector	What it pulls	Status
`microsoft-learn`	Certifications via Microsoft Transcript API	Planned
`google-learn`	Google Career Certificates via Credly	Planned
`credly`	Any Credly-hosted badge (Coursera, IBM, etc.)	Planned
`github-certifications`	GitHub Actions, Copilot, Security certifications	Planned
`aws`	AWS certification registry	Planned

Self-reported platforms (Udemy, LinkedIn Learning) are intentionally not connector targets. They can appear as contextual notes on a candidate’s profile but do not contribute to WorkProof evidence weights.

WorkProof for early-career professionals

WorkProof is designed to be accurate for professionals at every stage — including college graduates and career-changers with no employer history. The schema handles this honestly rather than forcing a mismatch.

The honest representation

A college graduate’s WorkProof graph will show lower confidence scores than a senior engineer’s. That is correct, not a flaw. A graduate with strong assessment results and active GitHub projects might generate confidence scores in the 0.45–0.65 range. A senior engineer with employer attestation and years of production artifacts might reach 0.85–0.95. The gap is real and the schema reflects it accurately.

This is more honest than a resume. A graduate’s resume inflates coursework into professional claims. A WorkProof graph shows what the evidence actually supports — with growth velocity often running higher than experienced practitioners who have stabilised in a domain.

Evidence sources available to graduates

Graduates have more WorkProof evidence than they realise:

Source	What it captures
Skill assessments	Standardised scores independent of employment history
GitHub	Personal projects, coursework repos, open source contributions, hackathon code
Academic evidence (`academic` type)	University coursework, thesis, capstone project authorship
Bootcamp evidence (`bootcamp` type)	Structured program completion, projects built during training
Hackathons	GitHub repos + peer collaboration edges from team events
Freelance work	Client project artifacts, GitHub activity, doc authorship

No employer history is required. Assessments and GitHub activity alone are sufficient to generate a valid WorkProof graph.

Institutional attestation

Universities and bootcamps can act as attestation issuers — not just employers. An institutional attestation follows the same W3C VC format as an employer attestation, with issuerType set to indicate the institution kind:

{
  "id": "att_grad_01",
  "issuerName": "University of California, Berkeley",
  "issuerDomain": "berkeley.edu",
  "issuerDID": "did:web:berkeley.edu",
  "issuerType": "university",
  "period": {
    "start": "2022-09-01T00:00:00Z",
    "end": "2026-05-15T00:00:00Z"
  },
  "attestedClusters": [
    {
      "clusterId": "frontend-engineering",
      "confidence": 0.62,
      "note": "Completed CS upper division coursework. Primary author on senior capstone: distributed task scheduler, deployed to production."
    }
  ],
  "issuedAt": "2026-05-20T00:00:00Z",
  "candidateApproved": true,
  "revoked": false,
  "credentialFormat": "jwt_vc"
}

A bootcamp attestation uses "issuerType": "bootcamp" with the same structure. Bootcamp attestations carry slightly lower weight than university or employer attestations in the evidence model, reflecting the shorter and less independently-verified context.

Growth velocity as a primary signal

Growth velocity is often the strongest signal for a recent graduate. A candidate actively shipping projects, completing assessments, and contributing to open source may have a growth velocity of 0.80+ even with lower absolute confidence scores. Recruiters hiring for trainable potential — rather than specific depth — should weight velocity heavily.

Implementations targeting graduate hiring should surface growthVelocity prominently in candidate-facing UIs and recruiter query results, not treat it as a secondary field.

Example: recent CS graduate WorkProof

{
  "specVersion": "0.1",
  "summary": "Recent CS graduate with strong frontend assessment results and active GitHub history across four personal projects. Fast learner with high growth velocity — two new technical domains added in the last six months.",
  "growthEdge": "Moving from personal projects into collaborative open-source contribution. First OSS PR merged last month.",
  "growthVelocity": 0.81,
  "skillClusters": [
    {
      "id": "frontend-engineering",
      "name": "frontend-engineering",
      "displayName": "Frontend Engineering",
      "confidence": 0.58,
      "executionDepth": {
        "scale": "personal",
        "context": "Four personal React projects, one deployed. Senior capstone: interactive data visualisation tool."
      },
      "evidence": [
        {
          "type": "assessment",
          "sourceId": "talentproof:assessment:frontend-2026",
          "description": "Frontend assessment, score 88/100",
          "weight": 0.45,
          "verifiedAt": "2026-03-10T00:00:00Z"
        },
        {
          "type": "github",
          "sourceId": "github:repos:portfolio-site",
          "description": "React portfolio, 120 commits, deployed on Vercel",
          "weight": 0.25,
          "verifiedAt": "2026-04-01T00:00:00Z"
        },
        {
          "type": "academic",
          "sourceId": "berkeley:capstone:2026",
          "description": "Senior capstone: data visualisation tool, primary author",
          "weight": 0.20,
          "verifiedAt": "2026-05-01T00:00:00Z"
        }
      ]
    }
  ],
  "sources": [
    { "type": "assessment", "status": "active" },
    { "type": "github", "status": "active" },
    { "type": "university", "status": "active" }
  ],
  "attestations": [
    {
      "id": "att_grad_01",
      "issuerName": "UC Berkeley",
      "issuerType": "university",
      "issuerDomain": "berkeley.edu",
      "period": { "start": "2022-09-01T00:00:00Z", "end": "2026-05-15T00:00:00Z" },
      "attestedClusters": [
        { "clusterId": "frontend-engineering", "confidence": 0.55 }
      ],
      "candidateApproved": true,
      "revoked": false
    }
  ]
}

The lower confidence scores are accurate. The high growth velocity is the differentiating signal. A recruiter looking for trainable early-career talent gets an honest picture of both.

Roadmap

Version	Status	What's included
v0.1	Draft	Core schema, skill clusters, evidence model, attestation format, consent gate, agent card extension
v0.2	Planned	JSON Schema file, TypeScript types npm package, attestation verification library
v0.3	Planned	C2C collaboration graph protocol, peer vouching spec
v1.0	Planned	Stable spec, reference implementation, registry protocol

Contributing

WorkProof is an open specification. Community feedback is welcome.

Discuss: Open a GitHub Discussion for questions and proposals
Issues: File an issue for spec ambiguities or errors
PRs: Pull requests welcome for typos, examples, and clarifications — schema changes require Discussion first

See CONTRIBUTING.md for guidelines.

Relationship to other protocols

Protocol	Relationship
MCP (Anthropic)	WorkProof graph is exposed via MCP tools. MCP handles tool/data connections; WorkProof defines what the data means.
A2A (Google / Linux Foundation)	WorkProof extends the A2A Agent Card with professional identity fields. A2A handles agent communication; WorkProof provides the professional signal.
W3C Verifiable Credentials	WorkProof attestations use the W3C VC data model for employer-signed credentials.
OpenAPI	WorkProof registry APIs are described in OpenAPI 3.1.

License

See LICENSE for full text.

Citation

If you implement or reference the WorkProof schema in academic or commercial work:

WorkProof Schema v0.1 (2026). TalentProof.
https://github.com/TalentProof/workproof-schema

推荐订阅源

Hacker News: Show HN