RFCs 0008–0014: how they fit together

[fraywing]

Kicking this off given the big change coming for 0.4.

Seven RFCs are open for comment together: #40, #46, #41, #42, #43, #44 and #45. Each is small enough to land on its own, but they're designed as one set, and several only make sense next to the others. This page is the map. Please comment on the individual PRs; use this thread for questions about how they fit together.

The problem they solve together

Candidates already send AI agents to apply for jobs. Today those agents scrape career sites and submit forms like a browser: no identity, no limits, no proof a person asked, and no way for an employer to tell which agent sent what. Employers experience that as noise.

OJCP's answer isn't "more automation". It's the opposite: automation that is identified, scoped, capped and attributed, and that employers can decline. Version 0.3 already covers part of that. These RFCs complete it.

How the pieces fit

Concern	What answers it	Where
Which agent sent this, and can I block a bad one?	Every agent signs its requests with a verifiable identity; providers can rate-limit or block a specific agent	RFC 0001, in 0.3
Can I limit which agents see my jobs?	Jobs can be public, restricted or private, enforced against the verified agent identity	RFC 0004, in 0.3
Are these agents worth it?	Every application is credited to the agent that sent it, so employers can see results per agent	RFC 0007, in 0.3
Unqualified applications	Hard requirements (sponsorship, relocation, clearance) and screening questions visible before applying	RFC 0006, in 0.3
Did a person ask for this application?	One-time approval for one application	RFC 0003, in 0.3
"Apply for me within these limits"	Standing mandates: one approval with a scope, salary floor, per-employer cap and end date, checked against each job	RFC 0008, #40
Is scope meaningful, and what does a submission commit the candidate to?	Occupation codes on jobs, which scope is checked against; binding actions listed before submission, which a standing mandate can never sign	RFC 0009, #46
Is this employer real, without one gatekeeper deciding?	Decentralized provider trust: grades derived from independent attestations under trust lists each agent chooses	RFC 0010, #41
Can a domain hijacker impersonate an employer?	Key transparency log: a public, witnessed history of employers' keys	RFC 0011, #42
Is this posting genuine and current?	Signed job postings that stay verifiable when boards and agents pass them along	RFC 0012, #43
Is the candidate's claimed experience real?	Wallet credential presentation: the candidate shows a signed record from their phone, directly to the employer	RFC 0013, #44
Who can issue those records, and how?	Hiring credentials and issuer profile: employment, education, licence and certification records, issuable from standard parts an HR system already runs	RFC 0014, #45

flowchart LR
  U[Candidate] -->|0003 / 0008<br/>one-time or standing mandate| A[Candidate's agent]
  A -->|0001 signed agent identity| P[Provider / employer]
  P -->|0004 visibility · 0006 gates<br/>0009 job codes + binding actions| A
  P -->|0007 attribution:<br/>results per agent| E[Employer decides<br/>which agents to welcome]
  T[0010 / 0011 / 0012<br/>provider, key and posting trust] -.-> A
  C[0013 / 0014<br/>verified candidate records] -.-> P

Loading

Reading order and dependencies

1. 0009 occupation codes and binding actions. Useful on its own; 0008 depends on it.
2. 0010 decentralized trust, then 0011 key transparency and 0012 signed postings, which build on it.
3. 0008 standing mandates. Depends on 0009 (scope and binding actions) and 0010 (the trust floor).
4. 0014 hiring credentials and 0013 wallet presentation. They go together, and use 0010 for trust and 0008's candidate binding.

Employers stay in control

Users can delegate; employers can decline. Across the set, an employer can refuse standing mandates, cap them, require a fresh one-time approval for every submission, restrict which agents see its jobs, block a specific agent, and see which agents produce results. Where any of that isn't explicit enough yet, say so on the relevant PR. That's what the comment period is for.

Hope this helps :-)

The idea isn't "slow down agents" it's that we're fixing the fundamental signal problem.