This is a live product built for one specific new AI-hiring compliance requirement, and deliberately scoped to that requirement rather than grown into a general governance platform. It sends candidate notices on approved templates, records delivery and failure as they happen, keeps a history that cannot be rewritten afterward, and exports evidence when someone asks for it. It is not legal advice and it is not an applicant tracking system.
The requirement this was built for
A new obligation appeared around notifying candidates when automated tools are used in hiring. The obligation was specific. What existed to satisfy it was not.
A new duty with nothing underneath it
The requirement says a notice goes to a candidate. Nothing in a typical hiring stack produces that notice, retains the wording used, or keeps proof that it went. Recruiters do it by hand, so it happens when someone remembers and stops when they are busy.
Notice wording drifts the moment people write their own
Once individual recruiters compose the message, there are as many versions of the notice as there are people sending it. Reviewed wording sits in a document somewhere and bears a decreasing resemblance to what candidates receive.
Sending is not the same as being able to show you sent
An email in a sent folder is an assertion. It does not survive the question of whether it reached the address, whether it bounced, or what it said at the time. The gap between doing the thing and demonstrating it is the reason this product exists.
A record that can be edited is not evidence
If the history of what was sent can be corrected afterward, it answers a different question than the one being asked. Anyone reviewing it has to consider whether it was adjusted, which is enough to make it worthless.
Governance platforms answer a much larger question
Enterprise AI governance software models risk, policy, model inventories, and bias testing. It is expensive, slow to adopt, and aimed at a programme rather than an obligation. A team facing one concrete notice duty does not need a programme. Scoping to that duty was the design decision.
What this platform deliberately does not store, and where that data already lives
The product holds far less about a candidate than people expect. That is an integration decision rather than a privacy stance. Every row below already has a system of record in the hiring stack.
| Data | Where it already lives | What this platform holds instead | Why it is not duplicated here |
|---|---|---|---|
| Resumes and application materials | The applicant tracking system | A reference to the candidate record, and nothing from inside it | Two copies of an application diverge the first time one is edited. The ATS is the system of record and stays that way. |
| Candidate contact directory | The applicant tracking system | The destination used for one specific send, as a fact about that send | A contact list maintained here goes stale against the ATS the moment a candidate updates their details. A send record is an event, not a directory. |
| Demographic and protected-class data | The ATS, or whichever tool collects it separately | Nothing | No operation here requires it. Data that is never held cannot go stale, cannot diverge, and is not part of anything that leaks. |
| Assessment and scoring output | The assessment vendor, then the ATS | Nothing | Scores are the assessment tool’s to hold and interpret. Copying them here creates a second version of a result with no owner. |
| Background check results | The screening provider | Nothing | A regulated record with its own retention rules belongs in the system built for it, not mirrored into a notice tool. |
| Interview notes and hiring decisions | The ATS | Nothing | The notice duty is about what was communicated, not what was decided. Holding the decision would widen the product past its scope. |
| The notice event itself | Nowhere else | Which approved template version went out, when, to which destination, and what the delivery attempt returned | No other system in the stack keeps this, which is the entire reason the product exists. |
How a notice goes out and what is left behind
Templates are approved before anyone can use them
Notices go out on approved templates. A recruiter selects a template; they do not compose wording at send time. Whoever is responsible for what the organisation says to candidates controls that wording in one place.
A send is an event, not a status field
Sending a notice creates a record of that send: which template version, when, to which destination. It does not update a flag that the next send overwrites. Each event stands on its own and remains after the next one happens.
Delivery and failure are recorded as they happen
What the delivery attempt returned is written to the send record when it comes back, including failures. A bounce is as much a fact as a delivery and is kept with the same weight. Somebody reading the record later sees what happened rather than what was intended.
The history cannot be rewritten afterward
Records of what was sent are not editable after the fact. If something needs correcting, that is a new event added to the history rather than a change to the old one. A record that can be tidied up is a record nobody can rely on.
Evidence exports when somebody asks for it
When a candidate, a regulator, or your own counsel asks what was sent, the history exports as a record of the notices, their template versions, their timestamps, and their delivery outcomes.
What it explicitly does not do
It does not determine which law applies to you, and it does not select which notice is legally correct for a situation. It does not guarantee compliance and it does not guarantee that any notice was received. It is not legal advice, not a substitute for counsel, and not an applicant tracking system. It sends what you approved and records what happened.
The boundary it keeps with the rest of your hiring stack
- custom application development — A narrow product with a defined boundary is a harder design problem than a broad one, and the boundary is the deliverable.
- document generation and delivery workflows — Approved template versions, generated notices, and the delivery record that follows each one out.
- workflow automation services — Where the notice sits in a hiring process people already run, so it happens without anyone remembering to do it.
Is this a fit for your business?
A good fit when
- You have one concrete notice obligation and no system producing evidence for it
- Recruiters are sending required notices by hand from their own mailboxes
- Somebody asked you for proof and you assembled it from a sent folder
- You want notice wording controlled by one owner rather than whoever is typing
Probably not a fit when
- You want a full AI governance programme with model inventories and bias testing
- You need something to decide which notices you are legally required to send
- You are looking for an applicant tracking system, or to replace the one you have
What to have ready
- The notice wording your counsel has approved, in whatever form it exists
- Access to the applicant tracking system that holds your candidate records
- A named owner for the template wording, because that role has to exist
Questions we get asked
Does it decide which notice we are required to send?
No. It does not determine which law applies to you and it does not select a legally correct notice. You and your counsel decide what has to go out and what it says. The product sends the templates you approved and keeps the record.
Does using it mean we are compliant?
No, and we will not say otherwise. Compliance depends on your obligations, your wording, and your process, none of which are ours to certify. What the product does is make the operational half reliable: the notice goes out on approved wording, and there is a record of what happened to it.
Can it prove a candidate received the notice?
It cannot guarantee receipt, and nothing honestly can. What it records is what the delivery attempt returned, including failures. That is a meaningfully different claim from receipt, and keeping the difference visible is the point.
Why does it hold so little candidate data?
Because your applicant tracking system already holds it. Duplicating a system of record is how data goes stale, diverges, and turns into an incident. The product references the candidate record and stores the one thing nothing else stores, which is the notice event.
Related
- automated quoting and invoicing for a professional services firm
- a vetted marketplace with verification built into the core
- managed services for systems we build
- selected product, application and workflow projects
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.