Index

The Letter the Law Says You Have to Send

Somewhere in New York City right now, a candidate is waiting to hear back from an employer that used an automated tool to screen applications. Under NYC Local Law 144, that employer had to conduct a bias audit of the tool before using it and give candidates notice that it was used. They also have to tell candidates how to request an alternative selection process.

Most employers are not doing any of this correctly. And the ones trying are producing a letter that is, in almost every case, three different problems at once.

What the letter has to do

It has to tell the candidate an automated tool was involved. It has to name the person or team accountable for that decision. It has to be accessible - the Americans with Disabilities Act applies to electronic documents as well as physical premises, and an untagged PDF is not accessible to a screen reader user. And it has to be something the employer can show to a regulator if asked: a record with a date, a policy reference, and a verifiable provenance chain.

That is a lot to ask of a letter that most HR teams are still producing as a Word document converted to PDF and emailed as an attachment.

Three problems in one document

The accessibility problem. Most PDFs produced by HR teams are not tagged. An untagged PDF is a flat image to a screen reader - it reads as a series of characters with no structure, no reading order, and no logical navigation. A screen reader user cannot tell the subject line from the body. They cannot jump to the action the letter requires. They cannot determine which paragraph they are in. The ADA requires electronic communications to be accessible; an untagged PDF fails that test before anyone opens it.

The provenance problem. The letter says a decision was made, but it does not say how, by whom, under which policy version, or what the authorising human reviewed before the letter was sent. If the candidate contests the decision under LL144, the employer needs to reconstruct that trail. If a regulator asks, they need to produce it. Most employers cannot. The record was in someone's head, or in a system log nobody thought to export, or in a model's inference path that was never captured.

The Human-in-Command problem. Automated employment tools do not make decisions. People do, using outputs from tools. The law knows this - LL144 does not regulate the tool's decision; it regulates the employer's use of it. But most letters read as if the machine decided and the human signed off. That framing is legally and practically wrong, and it is the framing that makes regulators nervous. What the letter needs to show is that a named person reviewed the tool's output, held authority over the outcome, and directed the action. That is Human-in-Command: the machine operated inside a declared boundary, the human held authority over that boundary, and the record proves it.

One PDF, all three

A properly built employment letter is a tagged PDF with an MX provenance structure embedded in it. The structure tree makes it navigable to a screen reader - heading, body, action paragraph, contact, all in the right order. The MX metadata records the AI provenance: which model or tool contributed, what the input was, the policy version governing the decision, the timestamp, and the name of the person accountable. The Human-in-Command declaration lives in the same record: this decision was made by a human, the tool's output was reviewed, the scope of the tool's authority was declared, and the artefact you are holding is the proof.

The candidate receives a letter. Their screen reader navigates it correctly. If they request an explanation, the employer can open the PDF's own metadata and walk the full chain in five minutes. If a regulator asks for the record, the employer produces the same PDF. Everything needed to answer every question the law puts to the employer is in the file, and it travels with the file wherever it goes.

That is not a compliance workaround. It is what the law was designed to produce - a record the candidate can read and the regulator can verify, in one step, without the employer having to reconstruct anything.

Why this matters beyond employment

Employment is the use case the law reached first because the harms are visible and the victims can complain. The same pattern - an AI-assisted decision, an accessible document, a human-accountable record - is coming for lending, insurance, healthcare, and any other sector where automated tools affect decisions about individuals.

The employers and agencies that build this into their document workflow now have a reusable pattern. The ones that treat each LL144 notice as a one-off compliance task will build the same thing twelve more times as the next twelve regulations arrive.

The two posts that cover the technical underpinnings: Tagged PDFs Are MX on why the accessibility and machine-readability requirements converge on the same structure tree, and Who Answers When the Machine Decides? on the accountability gap the letter has to close.

If you want to see what this looks like in practice - a real employment letter produced by the same pipeline - get in touch: info@cognovamx.com.