A plain record, so whoever picks sourcing back up can start from here.
Between your builds and ours, the pilot went from a job pulled out of Ashby, to an ideal profile with weightings and anti-patterns, to a ranked shortlist that showed why each person matched, to candidates pushed back into Ashby.
That includes the July 15 ranking update, where each candidate's recent posts and public mentions get checked before anyone is scored, and company lists work as examples rather than hard filters. It lives in your workspace and runs on your side.
The team is rethinking how recruiting runs end to end, and sourcing comes after the pieces that go first. Nothing on our side is on a clock.
These come from what worked and what broke during the pilot. None of them need Crustdata.
We want the role to hold the calibration.
If the new stack starts with planning and reqs, give each req a home for what sourcing will need later: the ideal profile, the anti-patterns, and every yes, no and maybe a recruiter gives on a real profile. Then a new recruiter on an evergreen role starts calibrated, and sourcing has context on day one.
The open question from July: profiles built mostly from interview feedback can push a search toward things that never show up publicly, like how someone did in a technical screen. A cleaner split is interview feedback for screening, and recruiter reactions to real profiles for sourcing.
It's worth an A/B on one evergreen role before settling it.
The quality drops in July came when the search logic got rewritten as the app grew around it: logins, per-role calibration, exports. What held up was keeping the core behind tests and a fixed contract, so screens and features can change without touching how candidates get found and ranked.
If something comes up before then, a question about the old build, a quick test against the data, or a sounding board while you build the new stack, I'm around.