Kaizen Approach
Sign in
Back to docs

Source of truth

Recruiting process

The recruiter-facing lifecycle from inbound prime request through candidate search, candidate communication, RTR lock-in, package generation, internal approval, prime submission, and post-submit tracking.

First-class stage

Stage 3: Candidate search / sourcing

Search starts from a requisition, creates SourcingRun records, persists discoveries, ranks matches, and writes audit events.

First-class stage

Stage 5: Candidate communication / outreach

Outreach is drafted, reviewed, sent in-app, audited, and tracked through reply state before RTR.

Scope

Applies to recruiter-led and autonomous intake.

The process covers the flow from prime intake through sourcing, engagement, RTR, package prep, internal approval, submission, and lifecycle tracking. Automation can start the flow, but the same lifecycle boundaries stay visible to the app.

Manual recruiter flow

A recruiter opens a requisition and runs sourcing and engagement from /requisitions/[id].

Autonomous intake flow

/watch-inbox or /api/cron/auto-ingest processes pending prime messages and runs configured portions of the same pipeline.

Process overview

Lifecycle stages

Each stage names the user surface, implementation surface, data ownership, and expected output where the source document identifies them.

Stage 1

Prime request intake

1

Turn a SOW email, RFQ, pasted SOW text, or manual requisition into structured recruiting work.

  • Input can arrive from inbound prime messages, manual SOW intake, or manually created requisitions.
  • The intake creates contract, labor category, clearance, location, deadline, and headcount context.

User surfaces

  • /watch-inbox
  • /intake
  • /requisitions

Core code

  • src/lib/auto-ingest.ts
  • src/lib/ai-parse-sow.ts
  • src/app/watch-inbox/actions.ts

Data

  • PrimeInboxMessage
  • Contract
  • Requisition
  • RequisitionVersion
  • ParseRun

Output

One or more open requisitions with structured contract, LCAT, clearance, location, and deadline context.

Stage 2

Requisition normalization

2

Convert the raw opportunity into a usable requisition profile before candidate work starts.

  • AI extracts labor categories, clearance requirements, must-haves, risk flags, headcount, location, and remote or onsite expectations.
  • Recruiters can review parsed requisition context before sourcing and outreach.

Output

A normalized requisition profile that downstream sourcing and outreach can reason over.

Stage 3

Candidate search / sourcing

3

This is where actual candidate search happens, and it remains an explicit lifecycle stage.

  • Manual trigger: Run AI sourcing on /requisitions/[id].
  • Autonomous trigger: auto-ingest calls runAutoPipelineAction, which calls runSourcingAction.
  • The orchestrator queries sources in parallel, dedupes hits, and prefers known in-pool candidates when duplicates collide.
  • New discoveries are persisted as Candidate rows before ranking, so the active candidate pool grows over time.
  • Sources currently modeled: ClearanceJobs, LinkedIn, Dice, and Internal DB.

User surfaces

  • /requisitions/[id]

Core code

  • src/app/requisitions/[id]/SourcingPanel.tsx
  • src/app/requisitions/[id]/sourcing-actions.ts
  • src/lib/sourcing-orchestrator.ts
  • src/lib/sourcing-connectors/*
  • src/lib/ai-sourcing.ts

Data

  • Candidate
  • SourcingRun
  • CandidateMatch
  • AuditEvent

Output

Ranked candidate matches with score, reasons, risks, and fit dimensions.

Stage 4

Candidate ranking and match explanation

4

Prioritize candidates against the requisition context and explain why each person is or is not worth engaging.

  • rankCandidates evaluates candidates against the requisition context.
  • Clearance is treated as non-negotiable where required.
  • Recruiters see rank, score out of 100, clearance fit, years-of-experience fit, skills fit, location fit, reasons, and risks.

Output

A prioritized list of candidates worth engaging.

Stage 5

Candidate communication / outreach

5

This is where candidate communication enters the process, as its own inspected stage.

  • AI drafts a first-touch email.
  • Recruiter reviews and edits subject and body.
  • Recruiter sends outreach.
  • System marks the candidate contacted.
  • Candidate reply is recorded. In demo mode this can be simulated as positive, decline, or needs-more-info.
  • Current demo send records state in-app; no live external email or LinkedIn send happens without an explicit production integration and approval gate.

User surfaces

  • /requisitions/[id]

Core code

  • src/app/requisitions/[id]/EngagementPipeline.tsx
  • src/app/requisitions/[id]/outreach-actions.ts
  • src/lib/ai-outreach.ts

Data

  • OutreachAttempt
  • Candidate.engagementState
  • AuditEvent

Output

Candidate moves from cold or search result into an active communication state.

Stage 6

Reply handling and follow-up

6

Keep the lifecycle moving after outreach instead of stopping at sent email.

  • A positive reply unlocks RTR.
  • A decline marks the candidate declined for that engagement.
  • A needs-more-info reply keeps the candidate in responded or follow-up mode.
  • Recruiter Auto-Plan flags stale outreach when sent messages have no reply after the configured threshold.

User surfaces

  • /inbox
  • /requisitions/[id]

Core code

  • src/lib/recruiter-auto-plan.ts
  • src/lib/inbox-counts.ts
  • src/app/inbox/*

Data

  • OutreachAttempt.sentAt
  • OutreachAttempt.repliedAt
  • OutreachAttempt.replySentiment

Output

Reply state and next action are tracked for each candidate engagement.

Stage 7

Candidate lock-in / RTR

7

Convert positive candidate interest into Right-to-Represent authorization for the opportunity.

  • Positive candidate interest enables RTR.
  • Demo mode can auto-sign RTR to show the end-to-end lifecycle.

Core code

  • requestRtrAction in src/app/requisitions/[id]/outreach-actions.ts

Data

  • RightToRepresent
  • Candidate.engagementState

Output

Candidate is locked to the opportunity and can move into package generation.

Stage 8

Tailored package generation

8

Prepare a submission package from the candidate record and requisition context.

  • AI generates a tailored resume and cover letter and surfaces gap analysis.
  • The system should not fabricate missing candidate experience.

Core code

  • src/app/requisitions/[id]/package-actions.ts
  • src/lib/ai-resume-tailor.ts
  • src/lib/package-html.ts
  • src/lib/package-docx.ts

Data

  • Submission
  • SubmissionPackage
  • ScoreRun

Output

Package-ready submission for internal review.

Stage 9

Internal approval

9

Require manager or approver review before prime submission by default.

  • Managers and approvers review package-ready submissions.
  • Review outcomes are approved, rework-requested, or still pending.

User surfaces

  • /admin
  • /notifications

Core code

  • src/app/admin/*
  • src/lib/approval-chain.ts
  • src/lib/notifications.ts

Data

  • ApprovalAction
  • Notification
  • ContractReviewer

Output

Approved, rework-requested, or pending submission.

Stage 10

Prime submission

10

Submit approved packages to the prime while preserving the human gate by default.

  • Approved packages can be submitted to the prime.
  • Per-contract automation can enable auto-submit, but it is intentionally marked dangerous and audited.

Core code

  • submitToPrimeAction in src/app/requisitions/[id]/package-actions.ts
  • forceAutoSubmitToPrime in src/app/requisitions/[id]/auto-actions.ts

Data

  • Submission.state
  • SubmissionPackage.primeSubmittedAt
  • SubmissionPackage.primeAck

Output

Prime acknowledgement and stopped time-to-first-submission timer.

Stage 11

Post-submit lifecycle

11

Track what happens after the package reaches the prime through placement or rejection.

  • States include submitted, prime-acked, interviewing, offer-extended, placed, and rejected.

User surfaces

  • /admin
  • /placements
  • /dashboard

Data

  • SubmissionLifecycleEvent
  • Submission.placedAt

Output

Placement and revenue metrics.

Candidate search: implementation contract

  • Search starts from a requisition, not from a generic candidate database screen.
  • Every search creates a SourcingRun with source, model, pool size, match count, and notes.
  • Every ranked candidate creates or updates a CandidateMatch.
  • Every run writes an AuditEvent summarizing source counts, unique hits, new candidates, and ranking output.
  • New external hits are persisted before ranking so the active candidate pool grows over time.
  • Dedupe should avoid creating duplicate people across connectors.
  • Source connectors can be mocked in demo mode, but the process boundary should stay the same when real connectors replace them.

Candidate communication: implementation contract

  • Outreach is attached to both requisition and candidate.
  • Drafts are editable before sending.
  • Sent outreach records subject, body, channel, sent time, and audit trail.
  • Replies record sentiment and text.
  • Candidate engagement state advances from cold -> contacted -> responded / qualified / declined -> locked-in.
  • Stale outreach is actionable in Recruiter Auto-Plan.
  • No live external email or LinkedIn send should happen without an explicit production integration and approval gate; current demo send records state in-app.

Automation rules

Automate search, drafting, and prep; gate prime submission.

Per-contract automation controls how much of the lifecycle runs without a human click. The default posture keeps final prime submission human-gated unless a contract rule intentionally says otherwise.

autoExtract
Create requisitions from inbound messages.
autoSource
Run candidate search after requisitions are created.
autoOutreachTopN
Choose how many ranked matches receive outreach.
autoLockIn
Simulate or perform reply-to-RTR advancement.
autoTailor
Generate packages after RTR.
autoSubmitToPrime
Bypass approval and submit to prime; dangerous and audited.
maxConcurrentReqs
Cap requisitions from one inbound SOW automation run.

Board-stage mapping

The board should show search and communication health.

Manager summaries and board briefs should report sourcing and outreach state, not just final submissions.

new

New

Open requisition with no candidate matches yet.

sourced

Sourced

Candidate search produced matches, with no outreach yet.

engaging

Engaging

Outreach sent; waiting on reply or RTR.

locked-in

Locked-in

RTR signed; package not sent to prime yet.

submitted

Submitted

Package reached the prime; waiting on prime decision.

placed

Placed

Candidate accepted or revenue event recorded.

closed

Closed

Filled, rejected, or otherwise closed.

Documentation gaps this closes

  • A single process map from intake through placement.
  • An explicit answer to where candidate search happens.
  • An explicit answer to where candidate communication happens.
  • Data-model ownership for each phase.
  • Automation boundaries and human gates.
  • Source files to inspect when the process changes.

Maintainer checklist for future changes

  • Name the affected user surface.
  • Name the server action or library file.
  • List the data model writes.
  • Keep audit events meaningful.
  • Separate demo-mode behavior from future real external sends.
  • Preserve human approval gates for prime submission unless a contract automation rule intentionally changes them.

Source file

This in-app rendering follows docs/recruiting-process.md. Update that source document and this route together when the recruiting lifecycle changes.