Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Background check chaser series ~5 min read

How a check update arrives

This post is mostly about something the system does not do. A reference reply arrives as an email with a PDF attached, and the interesting engineering decision is to read the fact of it and nothing else.

Key takeaways

  • Three lanes: an email reply, a form the owner fills in, and a manual mark-complete.
  • The system records that a check came back. It does not read what it said.
  • Attachments are handed straight to HR storage and never enter this system’s buckets.
  • “Arrived” and “satisfactory” are different, and only a person can set the second.
  • An update against an unknown check is a question, never a new item.

Three lanes

Three update lanes converging on one status changeThree boxes stacked on the left. Email reply, from a referee or an agency, labelled arrived. A short form, one link per check, labelled status. And Marked by hand, when HR knows something landed, labelled manual. All three converge on One status change, moving an item from outstanding to arrived. Below it, connected by a downward arrow, is Closed by a person, noting that arrived is not the same as satisfactory. A note says whatever the lane, only a status moves and the content goes elsewhere entirely.Email replyreferee, agencyarrivedA short formone link per checkstatusMarked by handHR knows it landedmanualOne status changeoutstanding toarrivedClosed by a personarrived is not satisfactoryWhatever the lane, only a status moves. The content goes elsewhere entirely.
Fig 1. Three ways a check comes back and one thing that changes as a result. The second box underneath is the important one: arrival and acceptance are separate events with separate actors.
  • App integration
  • Machine learning
  • Front-end & mobile
  • People

What happens to the attachment

A reference reply arrives at a monitored address with a PDF attached. The system needs to know that it arrived. It does not need, and must not have, the contents.

How a check reply is handled without retaining its contentA vertical chain of five steps entered by a box labelled Reply arrives, with an attachment. Step one asks which check it belongs to, matched by mail thread or by a token in the request, against the outstanding items in a DynamoDB checks table; no match exits to Ask HR, because a match is never guessed. Step two forwards the whole message to HR storage untouched. Step three records only that it arrived, with the date and the lane. Step four deletes the copy, retaining nothing here. Step five tells HR to review, since a person closes the item. A note says step four is the whole privacy design: the content passes through and is not kept.AWS ACCOUNTReply arriveswith an attachmentWhich check?thread, or the tokenDynamoDB checksoutstanding itemsAsk HRnever guess a matchno matchForward the whole thingto HR storage, untouchedRecord: arriveddate and lane onlyDelete the copynothing retained hereTell HR to reviewa person closes itStep four is the whole privacy design: the content passes through and is not kept.
Fig 2. What happens to a reply with a reference attached. The system is a relay for the content and a record for the status, and it keeps only the second.
  • Database
  • App integration
  • Security & identity
  • Management
  • Analytics
  • People
  • Outside AWS

Why relay rather than store

Storing a reference or a disclosure would give this system a data class it is not built for. It would need retention rules, access controls tied to HR roles, a deletion path for subject access requests, and a place in whatever record of processing your business keeps. All of that is real work, and none of it makes the chasing any better.

Relaying costs one forward and one delete, and it means the honest answer to “what does this system hold about candidates” is: their name, their start date, and a list of check statuses. That is a sentence you can say to anybody.

Arrived is not satisfactory

The status a reply produces is arrived, and the item stays open. Somebody in HR reads the reference and closes it, which is a second status of cleared or needs a conversation. Collapsing those into one status would be a small simplification with a large failure mode: a reference that arrived and raised a concern would show as green.

  • Outstanding. Requested, nothing back.
  • Chased. Requested, chased at least once, nothing back. Tracked separately because it changes the prediction.
  • Arrived. Something came back and is with HR. The clock stops; the item is not closed.
  • Cleared. A person has read it and is satisfied. Only a person sets this.
  • Needs a conversation. A person has read it and it is not straightforward. The system does not know why and does not ask.
  • Withdrawn. The check is no longer required, usually because the offer changed. Recorded rather than deleted.

An update with no matching check

A reply that cannot be matched to an outstanding item is not silently discarded and is not used to create one. It goes to HR with the message intact and a note saying it could not be matched. In practice it is usually a referee replying to a request for a different candidate, or a reply landing after an item was already closed by hand, and both of those are worth a human glance.

Next: how the prediction works, and why it speaks in three words.

All posts