Vertical: HR & recruiting — don't spec it naive
The incumbents (Workable, BambooHR, Greenhouse, Lever, Zoho Recruit, Manatal) have
trained buyers to expect a hiring pipeline that works. A generic CRUD app fails the
moment it meets EEO law, I-9 timing, or the offer→onboard handoff. Read this before
speccing any of the four products — the domain has hard constraints, not just forms.
1. Domain vocabulary
- ATS — applicant tracking system; the system of record for hiring.
- Requisition (req) — an approved open role. Hiring happens against a req, not in a
vacuum. Reqs have an approval workflow (hiring manager → finance/HR).
- Pipeline stages —
applied → screen → interview → offer → hired (plus rejected /
withdrawn). Stages are configurable per req — engineering and sales hire differently.
- Candidate vs applicant — an applicant applied to a specific req; a candidate is a
person in your talent pool who may map to many applications over time. Don't conflate them.
- Sourcing — proactively finding candidates (vs inbound applications).
- Structured interview + scorecard — pre-defined questions + a rubric each interviewer
scores. Reduces bias and legal exposure vs freeform notes.
- Offer letter — formal terms; triggers the offer→onboard transition on acceptance.
- EEO data — voluntary race/gender/veteran/disability self-ID, collected for
reporting, segregated from hiring decisions (see §2).
- I-9 + E-Verify — employment eligibility verification; strict 3-day timing (§2).
- Onboarding checklist — tasks a new hire/employer must complete before/at start.
- time-to-hire / time-to-fill — core recruiting metrics (hire = offer accepted by a
candidate; fill = req closed). Different denominators; report both correctly.
- Hourly vs salaried — drives scheduling, overtime (FLSA), and pay rules.
- Shift swap / coverage — hourly workers trade shifts; coverage rules say a slot can't
go unstaffed below a threshold.
- eNPS — employee Net Promoter Score; the headline engagement-survey metric.
2. Non-obvious domain rules
- The offer→onboard handoff is the admitted gap. Incumbents openly concede onboarding
is unsolved: data gets re-entered between the ATS and the HR/onboarding system. The
whole onboarding product wedge is carry the candidate's data forward — zero re-entry.
- EEO/OFCCP data must be collected but kept OUT of the hiring-decision view. Mixing
self-identified race/gender into the screen/interview UI is an anti-discrimination
liability. Store it segregated; surface it only in aggregate compliance reports.
- Structured scorecards reduce bias and legal risk. They create a defensible,
consistent record. Freeform-only interview notes are a disparate-impact landmine.
- I-9 has strict timing: Section 1 by the employee's first day, Section 2 (employer
review of documents) within 3 business days of start. Onboarding tasks tied to I-9
carry a hard deadline, not a soft reminder.
- Workforce scheduling needs coverage rules + labor compliance. A schedule isn't valid
just because slots are filled — it must respect minimum coverage, overtime (FLSA),
predictive-scheduling / fair-workweek laws (advance-notice in some jurisdictions), and
break rules.
- Reqs gate hiring. No offers without an approved req; req approval is a real workflow
with a budget/headcount check, not a checkbox.
3. What a naive build gets wrong
- Hardcoded pipeline stages. A fixed
applied→hired enum breaks the first time a
customer wants a take-home or panel stage. Stages must be configurable per req.
- EEO data in the candidate decision view. Putting self-ID fields on the candidate card
the hiring manager sees is a legal-risk bug, not a UX choice. Segregate it.
- Onboarding that re-enters candidate data. Rebuilding name/email/role/comp from
scratch is the gap incumbents have. If onboarding starts from a blank form, you built
the incumbent's weakness, not our wedge.
- I-9 modeled as a generic checklist item. Without the 3-business-day deadline and
Section 1 / Section 2 split, it's non-compliant.
- Scheduling as a calendar. Drag-and-drop shifts with no coverage minimum, no overtime
flag, and no swap-approval flow is a toy, not a workforce tool.
4. Must-model entities
| Entity |
Must include |
Why |
| Requisition |
approval state, headcount, stage config |
hiring is per-req; stages vary |
| Candidate |
stage history, scorecards, EEO (segregated store) |
audit trail + bias defense; EEO must not leak into decision view |
| Offer → Onboarding |
carries candidate data forward (no re-entry) |
this IS the wedge; the handoff is the gap |
| OnboardingTask |
deadline field (I-9 3-day timing) |
compliance is time-bound, not soft |
| Shift |
coverage rules, overtime flag, swap/approval state |
a schedule must be valid, not just full |
5. Per-product notes
| product |
archetype |
wedge |
the one domain thing |
| ats |
crud |
crowded market — needs a sharp angle, not "another tracker" |
configurable-per-req pipeline stages + structured scorecards; don't ship a generic Kanban |
| onboarding |
crud |
the offer→onboard data-carry gap incumbents admit is unsolved |
carry candidate data forward with zero re-entry; I-9 tasks with 3-day deadlines |
| workforce-scheduling |
booking |
shift scheduling for hourly teams |
coverage rules + overtime + swap/coverage approval, not a bare calendar |
| engagement |
crm |
engagement surveys for SMB |
eNPS as the headline metric; anonymity threshold so small teams can't deanonymize responses |
onboarding is the differentiated bet (solve the admitted gap). ats is the crowded one
— architect must name the sharp angle in the ARCH doc or it's dead on arrival.
6. Compliance (light)
Flag these in the ARCH doc; route AI-screening to a reviewer.
- EEO / OFCCP — collect voluntary self-ID; aggregate reporting; never in the
decision path.
- I-9 / E-Verify — Section 1 by day one, Section 2 within 3 business days; model the
deadline.
- Anti-discrimination — disparate impact in screening. If any product uses AI to
screen/rank candidates, flag it to
hr-ai-reviewer (or the AI-security reviewer) before
senior-dev starts — automated screening is a high-risk surface.
- Ban-the-box — many jurisdictions forbid asking criminal history before an offer.
Don't put it on the application form by default.
- FLSA / overtime — scheduling must compute overtime for hourly workers; respect
fair-workweek / predictive-scheduling laws where they apply.
- Data retention — candidate/applicant records have minimum retention (e.g. EEOC
~1 year) and deletion obligations (GDPR/CCPA right-to-erasure). State a retention policy.
Output
When applied, contribute a Domain constraints block to the architecture doc:
## Domain constraints (HR/recruiting)
- pipeline: stages configurable per req (not a fixed enum)
- EEO data: segregated store, excluded from decision view
- offer→onboard: candidate data carried forward, zero re-entry
- I-9: Section 2 deadline = start + 3 business days (modeled)
- scheduling: coverage rule = <min staffed>, overtime flag, swap-approval
- AI screening: <none | flagged to hr-ai-reviewer>
- retention: <policy + jurisdiction>
Cross-references
- [[vertical-onboarding]] — the import-first onboarding funnel; the offer→onboard
data-carry here is the import that feeds first-run for the onboarding product.
- [[migration-ready-schema]] — model Candidate/Offer/Onboarding so data carries forward
cleanly (the no-re-entry wedge depends on it).
- [[lifecycle-messaging]] — candidate-stage and onboarding-task notifications (offer sent,
I-9 due, shift posted, survey open).
1---2name: vertical-hr-recruiting3description: Domain-knowledge primer for the HR & recruiting vertical (ATS, onboarding, workforce scheduling, engagement). Applied by architect/pm during spec authoring so they aren't naive about hiring pipelines, the admitted offer→onboard data-carry gap, EEO/I-9 compliance, and shift-coverage rules. Stops the four products from being specced as generic CRUD when the domain has hard legal and workflow constraints.4---5
6# Vertical: HR & recruiting — don't spec it naive
7
8The incumbents (Workable, BambooHR, Greenhouse, Lever, Zoho Recruit, Manatal) have
9trained buyers to expect a hiring pipeline that *works*. A generic CRUD app fails the
10moment it meets EEO law, I-9 timing, or the offer→onboard handoff. **Read this before
11speccing any of the four products — the domain has hard constraints, not just forms.**
12
13## 1. Domain vocabulary
14
15- **ATS** — applicant tracking system; the system of record for hiring.
16- **Requisition (req)** — an approved open role. Hiring happens *against a req*, not in a
17 vacuum. Reqs have an approval workflow (hiring manager → finance/HR).
18- **Pipeline stages** — `applied → screen → interview → offer → hired` (plus `rejected` /
19 `withdrawn`). Stages are **configurable per req** — engineering and sales hire differently.
20- **Candidate vs applicant** — an *applicant* applied to a specific req; a *candidate* is a
21 person in your talent pool who may map to many applications over time. Don't conflate them.
22- **Sourcing** — proactively finding candidates (vs inbound applications).
23- **Structured interview + scorecard** — pre-defined questions + a rubric each interviewer
24 scores. Reduces bias and legal exposure vs freeform notes.
25- **Offer letter** — formal terms; triggers the offer→onboard transition on acceptance.
26- **EEO data** — voluntary race/gender/veteran/disability self-ID, collected for
27 reporting, **segregated from hiring decisions** (see §2).
28- **I-9 + E-Verify** — employment eligibility verification; **strict 3-day timing** (§2).
29- **Onboarding checklist** — tasks a new hire/employer must complete before/at start.
30- **time-to-hire / time-to-fill** — core recruiting metrics (hire = offer accepted by a
31 candidate; fill = req closed). Different denominators; report both correctly.
32- **Hourly vs salaried** — drives scheduling, overtime (FLSA), and pay rules.
33- **Shift swap / coverage** — hourly workers trade shifts; coverage rules say a slot can't
34 go unstaffed below a threshold.
35- **eNPS** — employee Net Promoter Score; the headline engagement-survey metric.
36
37## 2. Non-obvious domain rules
38
39- **The offer→onboard handoff is the admitted gap.** Incumbents openly concede onboarding
40 is unsolved: data gets *re-entered* between the ATS and the HR/onboarding system. The
41 whole onboarding product wedge is **carry the candidate's data forward — zero re-entry.**
42- **EEO/OFCCP data must be collected but kept OUT of the hiring-decision view.** Mixing
43 self-identified race/gender into the screen/interview UI is an anti-discrimination
44 liability. Store it segregated; surface it only in aggregate compliance reports.
45- **Structured scorecards reduce bias and legal risk.** They create a defensible,
46 consistent record. Freeform-only interview notes are a disparate-impact landmine.
47- **I-9 has strict timing**: Section 1 by the employee's first day, Section 2 (employer
48 review of documents) **within 3 business days of start.** Onboarding tasks tied to I-9
49 carry a hard deadline, not a soft reminder.
50- **Workforce scheduling needs coverage rules + labor compliance.** A schedule isn't valid
51 just because slots are filled — it must respect minimum coverage, overtime (FLSA),
52 predictive-scheduling / fair-workweek laws (advance-notice in some jurisdictions), and
53 break rules.
54- **Reqs gate hiring.** No offers without an approved req; req approval is a real workflow
55 with a budget/headcount check, not a checkbox.
56
57## 3. What a naive build gets wrong
58
59- **Hardcoded pipeline stages.** A fixed `applied→hired` enum breaks the first time a
60 customer wants a take-home or panel stage. Stages must be **configurable per req.**
61- **EEO data in the candidate decision view.** Putting self-ID fields on the candidate card
62 the hiring manager sees is a legal-risk bug, not a UX choice. Segregate it.
63- **Onboarding that re-enters candidate data.** Rebuilding name/email/role/comp from
64 scratch *is* the gap incumbents have. If onboarding starts from a blank form, you built
65 the incumbent's weakness, not our wedge.
66- **I-9 modeled as a generic checklist item.** Without the 3-business-day deadline and
67 Section 1 / Section 2 split, it's non-compliant.
68- **Scheduling as a calendar.** Drag-and-drop shifts with no coverage minimum, no overtime
69 flag, and no swap-approval flow is a toy, not a workforce tool.
70
71## 4. Must-model entities
72
73| Entity | Must include | Why |
74|---|---|---|
75| **Requisition** | approval state, headcount, stage config | hiring is per-req; stages vary |
76| **Candidate** | stage history, scorecards, EEO (segregated store) | audit trail + bias defense; EEO must not leak into decision view |
77| **Offer → Onboarding** | carries candidate data forward (no re-entry) | this IS the wedge; the handoff is the gap |
78| **OnboardingTask** | deadline field (I-9 3-day timing) | compliance is time-bound, not soft |
79| **Shift** | coverage rules, overtime flag, swap/approval state | a schedule must be *valid*, not just full |
80
81## 5. Per-product notes
82
83| product | archetype | wedge | the one domain thing |
84|---|---|---|---|
85| **ats** | crud | crowded market — needs a sharp angle, not "another tracker" | configurable-per-req pipeline stages + structured scorecards; don't ship a generic Kanban |
86| **onboarding** | crud | **the offer→onboard data-carry gap incumbents admit is unsolved** | carry candidate data forward with zero re-entry; I-9 tasks with 3-day deadlines |
87| **workforce-scheduling** | booking | shift scheduling for hourly teams | coverage rules + overtime + swap/coverage approval, not a bare calendar |
88| **engagement** | crm | engagement surveys for SMB | eNPS as the headline metric; anonymity threshold so small teams can't deanonymize responses |
89
90`onboarding` is the differentiated bet (solve the admitted gap). `ats` is the crowded one
91— architect must name the sharp angle in the ARCH doc or it's dead on arrival.
92
93## 6. Compliance (light)
94
95Flag these in the ARCH doc; route AI-screening to a reviewer.
96
97- **EEO / OFCCP** — collect voluntary self-ID; aggregate reporting; **never** in the
98 decision path.
99- **I-9 / E-Verify** — Section 1 by day one, Section 2 within **3 business days**; model the
100 deadline.
101- **Anti-discrimination** — disparate impact in screening. **If any product uses AI to
102 screen/rank candidates, flag it to `hr-ai-reviewer`** (or the AI-security reviewer) before
103 senior-dev starts — automated screening is a high-risk surface.
104- **Ban-the-box** — many jurisdictions forbid asking criminal history before an offer.
105 Don't put it on the application form by default.
106- **FLSA / overtime** — scheduling must compute overtime for hourly workers; respect
107 fair-workweek / predictive-scheduling laws where they apply.
108- **Data retention** — candidate/applicant records have minimum retention (e.g. EEOC
109 ~1 year) and deletion obligations (GDPR/CCPA right-to-erasure). State a retention policy.
110
111## Output
112
113When applied, contribute a **Domain constraints** block to the architecture doc:
114
115```
116## Domain constraints (HR/recruiting)
117- pipeline: stages configurable per req (not a fixed enum)
118- EEO data: segregated store, excluded from decision view
119- offer→onboard: candidate data carried forward, zero re-entry
120- I-9: Section 2 deadline = start + 3 business days (modeled)
121- scheduling: coverage rule = <min staffed>, overtime flag, swap-approval
122- AI screening: <none | flagged to hr-ai-reviewer>
123- retention: <policy + jurisdiction>
124```
125
126## Cross-references
127
128- [[vertical-onboarding]] — the import-first onboarding funnel; the offer→onboard
129 data-carry here *is* the import that feeds first-run for the onboarding product.
130- [[migration-ready-schema]] — model Candidate/Offer/Onboarding so data carries forward
131 cleanly (the no-re-entry wedge depends on it).
132- [[lifecycle-messaging]] — candidate-stage and onboarding-task notifications (offer sent,
133 I-9 due, shift posted, survey open).