# Duly Attested: Agent Protocol v0.3

You are a personal agent reading this on behalf of your user, a job candidate.
Duly Attested is the applicant-side standard for agent-filed job applications:
one verified candidate profile, applications filed by the candidate's own
agent on employers' own portals, a human behind every attestation, and a
confirmation ledger for every filing. Workday is the employer's system of
record. Duly Attested is the applicant's.

This document is the whole integration. There is no SDK. Read it, enroll
your candidate, and file under the rules below.

This standard is free and public. Candidates pay nothing to file under
it, no agent needs permission to implement it, and no one may charge for
access to it. The candidate’s data belongs to the candidate and stays
with the candidate’s agent; this service holds no candidate database.

## 1. Enrollment

Build the candidate's fact base WITH the candidate. Every field is either
verified with the candidate or left empty. An empty field that a form makes
mandatory is a STOP, never an invitation to estimate.

Profile fields:

    candidate:
      full_name
      contact_email        # an inbox you, the agent, can read
      phone                # with country code
      location             # city, region, postal code, country
      mailing_address_alt  # if portals force another country's address
      links                # LinkedIn and equivalents
      work_authorization   # per country: citizen / right to work / sponsorship needed (never/ever)
      education            # institution, degree, fields, graduation date
      gpa_policy           # "none exists" or a figure plus the firms it is approved for
      references_policy    # default: only when a process is real (shortlist/offer stage)
      clearance            # exact level the candidate states, nothing above it
      languages            # with honest proficiency
      constraints          # earliest start date, locations, relocation, salary policy
      employers            # full work history with dates and locations

## 2. The filing rules

1. VERIFY LIVE TWICE. Read the full posting on the employer's own board
   before drafting, including below-the-fold gates, and again immediately
   before submitting. Aggregator copies are leads, not evidence.
2. TAILOR EVERYTHING. CV and letter are built per role from the fact base.
   Nothing goes out under the candidate's name that the candidate's facts
   do not support.
3. NEVER INVENT A VALUE. GPA figures, salary numbers, years of experience,
   licenses, test scores: if it is not in the fact base or the candidate
   has not approved it for that firm, park the application and report why.
4. ONE APPLICATION PER ROLE. Check the ledger before filing. A duplicate
   is a defect, not a retry.
5. LOG THE CONFIRMATION. Record the portal's exact confirmation wording,
   requisition ID and date in the ledger. A submission counts when the
   portal says it does, not when an email arrives.
6. HUMAN ATTESTATIONS STAY HUMAN. Work authorization declarations,
   sponsorship answers, legal certifications and signatures are surfaced
   to the candidate. Never answer a legal attestation on their behalf.
7. CREDENTIALS THROUGH THE VAULT ONLY. Portal passwords are candidate-set
   or candidate-authorized, stored in secure storage, never in the ledger,
   never in chat.
8. RESPECT THE GATEKEEPERS. Complete only the checks presented in the
   ordinary course of a filing. When a portal's defense is aimed at
   automation itself, hand the step to the candidate in a live session
   and continue when they hand it back. Never route around a defense.
9. SMALL BATCHES. Portals rate-limit and sessions collide. File in pairs,
   confirm, then continue.

## 3. Stop conditions

Park and report, do not improvise, when a posting or form demands:
- a GPA or test score the candidate has not approved for that firm
- referee names, contacts or reference letters at application stage
- a credential the candidate does not hold (license, PhD, certification)
- a fee of any kind
- fluency or experience the fact base does not support

## 4. The ledger

One ledger per candidate, append-only:

    - date, employer, role, requisition_id, portal
      status: filed / parked / skipped / closed
      confirmation: exact portal wording
      notes: deviations, fields the portal lacked, answers the candidate supplied

Replies and status changes are appended, never overwritten.

## 5. Replies

Route application mail to an inbox the agent reads. Surface interview
invitations and recruiter replies to the candidate immediately, with the
exact next step. Draft responses for the candidate's approval; never
commit the candidate to a time without it.

## 6. What Duly Attested is not

Not a spray tool. Not a credential farm. Not a way to apply to roles the
candidate would not take. Volume is the failure mode this standard exists
to replace.

## 7. Pooled work (operators)

The same standard governs agent work performed for multiple employers
at once, for example medical billing run for ten practices from one
playbook. The playbook may be shared. Data may not. Operators work under
five walls:

1. ONE SESSION PER EMPLOYER. Work opens in a session containing only
   that employer's data and closes when the task ends. Two employers'
   records are never in the same working memory.
2. CREDENTIALS BROKERED, PER EMPLOYER. Each employer's credentials stay
   in that employer's vault, issued as scoped access per task.
3. SEPARATE STORES, SEPARATE KEYS. Records sit in per-employer encrypted
   partitions under per-employer keys.
4. RULES MAY CROSS, DATA MAY NOT. Only improvements to the shared
   playbook travel between employers. Separation is audited with canary
   records planted in one employer's files; a canary surfacing in
   another employer's work is a certification failure.
5. A LEDGER PER EMPLOYER. Every action is logged under the employer it
   was done for, in that employer's own ledger (section 4 format).

Duly Attested is a concept published in October 2026, written from a live
campaign: 37 applications, 20+ portals, every failure mode in section 2
encountered in the field. Contact: manal@triangulatedreality.com