Required for what?

Three questions, asked of one document

The three questions come from what a decision system needs in order to be a system rather than a set of intentions: meaning, authority and validity. Something has to define the construct: what this is, and what counts as it. Then the call has to be allocated to whoever settles the thing when the evidence runs out. And the loop has to close, so that anyone can tell afterwards whether the calls were good. Take any one away and the other two stop working. Define a construct nobody may act on and you have a definition. Allocate a call with no measure behind it and you have an opinion with a signature. Settle and measure a question nobody has defined and you have an exact answer to a question nobody framed.

None of those three functions is directly observable in a job posting, so each is read here through a single marker: a candidate attribute, a named decision, and a measure of the role’s own work. The markers are narrower than the functions they stand for. A required master’s degree is not a construct definition, and the count below is a count of the marker.

Job postings are an unusually clean place to test this, because a requisition is the founding document of a working relationship and it is written before anyone has a stake in softening it. I have read hiring artifacts this way before, going through a decade of take-home tasks to see what they revealed about the teams that set them. A posting is the same kind of evidence one step earlier, and there are more of them.

Sixty-four of sixty-five codable postings name at least one attribute required of the person. That is ninety-eight percent. The rule was written to make the finding hard rather than easy: one named attribute clears the bar, and the same grain was used for all three anchors, so the comparison could not be rigged by setting a low bar for one and a high bar for another.

Twenty-three of the sixty-five name a decision the hire may make, anywhere in the document. Thirty-five percent. Two coders worked from the same evidence packet, each seeing the rule and the text but neither seeing the other’s codes or the postings themselves. On this marker they agreed on fifty-five of the sixty-six. Then a separate pass swept all sixty-six for the verb patterns the adjudication had settled on, and it turned up five postings both coders had missed. Agreement tells you two readers were consistent. It cannot tell you they were right, and here they were consistently wrong five times.

Seven name a measure of the role’s own work, which is eleven percent, and it is the same gap I went after in the evaluation of AI systems, arriving here one document earlier and about a person instead. Inside those seven there are thirty-three enumerated success items, and exactly one carries a number: a target net promoter score, above 0.70, at a consultancy. That is the only threshold applied to a post-holder’s own work anywhere in the corpus. The other thirty-two name a condition without saying how anyone would read it. Stakeholders trust the numbers. Dashboards are widely adopted. Time-to-insight comes down. How widely, by when, down to what, measured by whom — none of that is written, so none of it could be missed.

Read down the three and the shape is a descent.

Counted the other way, by how many anchors a single document founds rather than by how many documents found each anchor: four postings of sixty-five have all three. Twenty-one have two, forty have one, and none have zero.

What the requirements are for

That descent was the finding for about a week. Then a question that sounds like housekeeping turned into the thing underneath it.

Employment-selection standards have said since 1978 that a requirement needs a job analysis behind it. Sixty-four of the sixty-five codable postings have a section where the employer states what the role requires. It is headed Requirements, or Qualifications, or Minimum Qualifications, or What You Bring, and it is usually followed by a preferred block. Ten years of this, a degree in that, fluency in these tools, the ability to influence across functions.

A requirement is a claim of necessity, and necessity is always relative to a task. Ten years of data engineering is required in order to do what. So a requirements section is not a list. It is an inference, and it needs a stated job on the other end of it to be an inference about anything.

Forty-two of the sixty-five name what the person must bring and never say what the role may decide. Not in a scope paragraph, not in responsibilities, not anywhere. These are director-level roles and above. From here the argument needs an assumption the corpus does not measure: that at this level, settling things is most of the work. Grant that, and those items are being asserted as necessary for a job the document has not stated.

That is a claim about the document and it stops there. A job analysis may well exist somewhere — in a competency model, in a hiring manager’s head, in the conversation that produced the requisition. Nothing here says otherwise. What the corpus supports is narrower: these documents specify the candidate and mostly leave the role’s decision scope unstated. There is a second question underneath it that I did not code at all: whether, for any given requirement, the document says what work makes that attribute necessary. Searching for a named decision is not the same as checking eight hundred and thirteen items for a stated warrant, and only the first was done here.

Before any of this was a corpus, I sat with one job description and counted its and/or constructions. There were four. Every one of them sat at the point where the document had to say whether the role decided something or assisted with it. The slash is the document arriving at the question and declining to answer it. One document proves nothing and I have not counted this marker across the sixty-five. It did change what I thought I was reading. I had been treating these as loosely written documents. After the and/or count I started reading them as documents that arrive at the decision question and step around it.

The claim under test was written down before coding, in the form most likely to be wrong: the requirements section is composed of credentials, skills and capabilities, and does not carry decision rights. Any material rate of authority inside those sections would have falsified it.

Sixty-four postings carry a requirements section. Across them there are eight hundred and thirteen items — one bullet or one sentence apiece — and not one of those items names a decision the hire may make. Not in the required block, not in the preferred block. This is a count of items inside one section, not a count of documents. Fifty-seven items came close enough to be pulled into an adjudication packet by a deliberately over-inclusive filter, and every one of the fifty-seven was read and coded false rather than filtered out mechanically. Forty-four were read three times, once by each of the two coders working blind from the same packet and once more at adjudication. Thirteen were read only at adjudication, and seven of those come from postings the blind coders never saw. That is the thinnest part of the zero, and it sits at thirteen items out of eight hundred and thirteen.

What the eight hundred and thirteen are made of, roughly: three quarters are abilities and dispositions, then tools, then domain knowledge, then years, then degrees, then a thin tail of certifications. The abilities category is the largest and the least falsifiable in content, which is a finding in itself and should not be smoothed over.

The count is not clean, and where it is dirty changes what you can infer from it. About eight percent of the items resist categorising, and a handful are not requirements at all. One school district’s posting runs its qualifications list straight into a payroll term with no heading between them, so the extractor kept reading and counted it. A recruiting mailbox in the same posting is my own fault rather than the employer’s: my heading rule matches on the word requirements, it caught a later Job Requirements line, and it swallowed the contact block underneath. The split between the required block and the preferred block is worse than that: on two postings the extraction ignored the employer’s own preferred heading, so I would not quote a required-versus-preferred ratio from this pass. None of that moves the zero, because a payroll code cannot be a decision and a misfiled bullet is still a counted bullet. It does mean the eight hundred and thirteen is a working count rather than a clean one, which is the same disclosure the meaning number carries a paragraph earlier.

Getting to sixty-four took a repair that nearly became a finding of its own. The first build reported nine postings with no requirements section at all. Checking those nine against their source files, seven had one, under headings a list built from the common cases could not see. What Experience We Need. What We Require. You Need to Have. You should definitely have. One posting’s headings had been glued onto the tail of the preceding bullet by the text extraction, so no heading list of any size would have found it. Employers who write informally were being dropped, and the drop looked exactly like employer silence.

Sixty-four is the denominator because two of the sixty-six have no requirements section to count items in, and the second of those two is awkward for me. One is the posting my own segmenter truncated. The other wrote no requirements section at all, and it is the same posting the next section holds up as the one employer here who states decision rights explicitly. So the document that argues hardest against me is the one missing from the denominator of my headline number. The exclusion is real and the reason for it was written down before the count was run. A reader is still entitled to both facts in the same place.

What happens when the decision does exist

An absence is a weak finding on its own, and this one has an obvious answer that I want to concede before going further. The answer is that requirements describe the person and responsibilities describe the work, so naturally the decision sits in the other section. That is right. Filing is not a fault, and I am not claiming the decision belongs in one section rather than another.

What is worth looking at is the twenty-three postings where the employer did settle a decision, because there the document had something to be required for and you can watch what it does with it.

Twenty-two of the twenty-three also carry a requirements section. In four of them the same decision appears in both, and the transformation is the thing to look at. An insurer’s responsibilities block says the role will resolve cross-stream data dependencies and tradeoffs…. Its requirements block asks for experience resolving cross-team data dependencies and tradeoffs…. I have cut both quotations where they stop matching; each sentence continues, and they continue differently. The decision has become a credential. What the person will do has been rewritten as something the person should already have done, somewhere else, for somebody else.

The word authority appears eight times inside requirements sections across seven postings. Five of the eight are explicit negations, and the phrases inside those five items run: influence without direct authority, create alignment even without direct authority, influence without authority, influencing without formal authority, in positions without formal positional authority.

Those five are not silence. They name work the role must accomplish beyond whatever positional authority it carries, and select for the candidate’s ability to operate there. That is not the same as an absence of decision rights, though it would be easy to read it that way. It is still the most specific thing any requirements section in the corpus says about authority, and what it asks for is the capacity to work without leaning on it.

And the sharpest single item in the corpus, from a research university: Experience establishing enterprise governance structures with formal decision rights. The candidate is required to have held formal decision rights somewhere. None is granted here.

One posting inverts the whole pattern, and it is worth reading closely because it cuts against the easy version of this argument. A quantum computing company’s requisition carries a section headed What You Won’t Own (by design), an operating-model section, and a sentence naming what the role holds and what functional owners retain. It is the writing this essay is asking for. It is also the single posting in sixty-five that names no attribute required of the person. That was checked against the complete twelve-thousand-character source: there is no qualifications block under any heading, and the only requirements it mentions are export-control ones. Every other posting in the corpus names what the person must bring. This one names none of that and states the decisions instead.

The count that changed when the rule changed

These sixty-six documents were coded twice, and the second pass is the one this essay reports.

The first pass ran while the corpus was still being read. Its markers were built out of what was in front of me, so the rule for a decision the hire may make was narrow. It looked for one particular way of handing a role the right to settle something, and it found four postings in sixty-six. That number sat on disk for a week. It is now retired.

The second pass started with three rules written out in full before any posting was reopened. One grain for all three anchors: a single named item clears the bar, whether the item is an attribute, a decision or a measure. Setting an easy bar for meaning and a hard one for authority is the obvious way to manufacture this comparison, so the grain was fixed in advance to close that off. Authority came back at twenty-three.

The documents did not change and neither did the employer prose. Nothing was added to the corpus between the two passes, and the whole difference is the rule.

The second rule stands because of how it was built, not because it is newer. A rule written after reading encodes the examples it has already seen, then goes and finds more of those. A rule written beforehand can be wrong in public. This one went to two coders working blind from an identical evidence packet, disagreements were adjudicated in writing against a stated line, and the result was swept back across all sixty-six for postings both coders had missed. The authority sweep found five. The validity sweep found one.

Four would have been the better number for this argument. Twenty-three is the number the rule produced.

Twenty-three depends on a judgment call about one pattern, and that pattern is common in these documents. It counts a posting where the role both sets a standard and can hold others to it. A stricter reader rejects that, on the grounds that a duty to enforce a rule is something you must do about other people rather than a decision you get to settle. The strictest reading gives eleven. Those eleven name an actual decision: approve this spend, select this platform, hold decision rights over this architecture. Eleven would make the forty-two a fifty-four. This essay uses twenty-three throughout, and anyone who rejects the enforce pattern should read eleven wherever it appears.

One consequence of coding twice is that every count here has to say what it is a count of. Sixty-six were collected. Sixty-five are codable, since one posting’s extract is a truncation defect in my own pipeline and gets reported as a defect rather than as employer silence. Sixty-four carry a requirements section (the sixty-fifth writes none, checked against its full source). The three anchors report over sixty-five; the composition finding reports over sixty-four. Anything computed under the first pass is retired and is not in this piece.

What this evidence will not carry

The strongest objection to all of it was raised before the coding started, and it has not gone away.

If a role exists to build a governance function, then a requisition that does not contain decision rules is not failing. It is a work order. You cannot fault a document for omitting the deliverable of the job it advertises, and the ambiguity language in these postings — one wants someone comfortable with ambiguity, another someone who enjoys creating structure where none exists — is arguably the employer saying so rather than hiding it.

That objection is largely right and it changes what the counts can be used for. It does not reach the warrant question, though. A work order still has to say what the person is required for, and a posting that asks for ten years of a named skill has already made a necessity claim whether or not the decisions are the deliverable. The four conversion cases are the sharper version: those employers had settled the decision and still wrote it into requirements as something the candidate should have done elsewhere. But nothing in this corpus separates an employer who never thought about it from one who thought about it and chose to leave it open. No marker coded here can, and I am not going to estimate it.

Three further limits, stated rather than discovered. A job posting is not a governance document; an organization can run a model-risk committee and put none of it in a requisition, and reading these counts as a claim about internal practice would be the category error this library keeps objecting to. The sampling is worse than the coding: these sixty-six are roles one person selected and in most cases applied to, across four months, leaning toward education, nonprofit and health-adjacent employers, so selection bias is total and runs in a known direction. And the corpus has no outcome variable, so it supports no claim about what any of this causes downstream. The causal literature connecting unclear decision rights to churn and failed restructures is real and it is borrowed; the join between that literature and this evidence does not exist in this design.

One piece of that sampling objection can be checked rather than conceded. If these employers were simply too early to have needed decision rights written down, the silence would say something about their stage and little else. So each posting was coded for whether the role holds an AI or machine-learning system in its remit. Twenty-seven of the sixty-five do. Within those twenty-seven, thirteen name a decision the hire may make and fourteen do not. Among the thirty-eight holding no such system, ten name one. That is forty-eight percent against twenty-six, an odds ratio of 2.6, and a two-tailed exact test on the table returns p = 0.11. Sixty-five postings cannot establish a gap that size, so this is a direction rather than a result. It cuts both ways regardless. Fourteen of the twenty-seven roles that hold an AI system in their remit still never say what the person may decide.

A fourth limit belongs with those three, and it is the one I would go after first if this were someone else’s essay. Decision-absence is standing in for something broader. The corpus measured whether a document names a decision the role may make. The argument wants to know whether the document says what work its requirements are for. Those are not the same question. The study that would close the gap has not been run: for each of the eight hundred and thirteen items, is there employer prose establishing what work makes that attribute necessary. It would need its own coding rule, its own double-coding and its own adjudication, so it is a second study rather than a repair to this one. Until it exists, the forty-two counts documents that name no decision, and the step from there to a job unstated is the assumption stated earlier and not a finding.

A second arm is designed against that objection and has not been collected yet. It is fifty-six postings, drawn mechanically from an enumerated set rather than picked by me, with the coding rules frozen as they stand. Fifty-six postings can show a large move and cannot resolve a small one. Against a thirty-five percent base rate the arm cannot tell apart anything between roughly twenty-three and forty-eight percent, so it is a check for a big shift rather than a measurement of how far the two arms differ. The falsifier is declared in advance, it sits on the same anchor the argument does, and it is written down where I cannot move it later without the move showing.

Why an undefined boundary got expensive

None of this was a problem for as long as the thing on the other side of the boundary was a person.

People negotiate an undefined boundary after they arrive. They read the room, decide something small, see whether anyone objects, and settle into a working answer nobody ever writes down. That absorption is why the line could go unwritten for decades without anyone filing a complaint. It is also why hiring into ambiguity is rational on the day. Writing the boundary down requires several senior people to agree in advance about something each of them would rather keep flexible. Hiring someone into the gap produces a headcount instead, which is a form of progress that shows up in a plan.

A system also carries on, and this is the part to get right. The expected version of this argument is that machines fail loudly and people fail quietly. That is not what happens. The workflow continues. Nothing is raised, nothing settles, and the point where the premises ran out is not surfaced anywhere. Someone has to go looking for it, and whether looking is part of the workflow is usually not established.

So the claim here is narrow and worth keeping narrow: agents are not better at governance than people. They remove the absorbing layer without putting a signal in its place. What used to be a cost paid quietly by whoever was standing at the ambiguous boundary is now a defect nobody has been told to find. I have made the general version of this argument elsewhere — the checkpoint that came free with every answer has to be built back in once the system produces actions. These sixty-six requisitions are where you can see whether anyone did.

There is a second machine in this story and it arrives earlier, at the other end of the same document. A screening tool can read the whole posting; that is not the constraint. The constraint is that requirements are already written in the grammar of selection. Ten years, a named degree, a listed tool — each one is an attribute a candidate can be compared against, and eight hundred and thirteen of them (over sixty-four documents) is the shape a scoring system wants. Decision scope is not usually written that way. Where it exists it sits in prose in another section as a description of the job, not as a variable anyone is selected on, and where it does not exist it is something a person infers from the title and works out after they arrive.

So the automation lands on the specified half and misses the unspecified half, and it misses it silently, because nothing in the pipeline is asking. A person reading a requisition reconstructs the implied scope without noticing they are doing it. A system matching against enumerated attributes has nothing to reconstruct from and no reason to try.

That part of the argument is not mine, and it is better admitted than defended. Microsoft put the execution and decision split in the standfirst of its 2026 Work Trend Index. Deloitte built a chapter of its 2026 Global Human Capital Trends on who is accountable when humans and machines are both deciding. Both are vendor and consultancy research with commercial interests in their own conclusions, and both are worth reading anyway.

What neither of them does is run backward to the door. Microsoft’s talent-practices variable contains no selection and no hiring at all, and the report says so plainly: leaders focus on hiring the right people, and their data points at the conditions created afterwards instead. Deloitte’s seven chapters have no hiring chapter. Both redesign decision rights for people already inside the building. Neither touches the decision that put them there, or the document that recorded it.

Researchers have studied postings for years, mostly for skills and degree inflation. In June 2026 the Labor Department asked the question directly. In June 2026 the Labor Department opened a request for information on modernizing O*NET, the federal occupational database, and closed it in August. Part of what it asks is whether to draw more of O*NET’s skills data from job postings. One of its questions asks how far postings accurately reflect real work requirements, and where they are misleading or incomplete. This corpus answers one narrow part of that, for one slice of one labor market. Forty-two of these documents state requirements and name no decision the role may make.

There is one more asymmetry in the corpus that belongs here. Five postings of sixty-five name a standard applied to an AI or ML system’s outputs: evaluation frameworks, drift monitoring, human-in-the-loop review. Seven name a measure of the person’s own work. So the machine gets a measurement regime about as often as the person does, and no posting in the corpus names both. The machine-side version of that regime is a solved problem in the sense that people have written down what it should contain, down to the contract every AI feature has to hold to. Nobody has written the person-side one, and these documents are where it would go.

One requisition carries both of this section’s machines at once. It advertises a role that will run AI systems for the employer, and it also describes the AI that screens the person reading it. That posting is the only place in the corpus where a boundary between human and machine judgment is written down cleanly.

An insurer’s requisition closes with a notice about the hiring process the reader is standing in. The company may use AI to sort and filter applicants during preliminary screening, it says. Then: “we do not use AI Tools to substantially assist or replace human judgment or discretionary decision making in our hiring process.” All hiring decisions, it adds, are made by its own colleagues. The paragraphs around that sentence offer a route to request an alternative process, and commit to publishing the most recent bias-audit results.

Read it next to New York City’s Local Law 144. The law took effect at the start of 2023 and has been enforced since that July. It bars an employer from using an automated employment decision tool in the city without three things: an annual independent bias audit, a published summary of the results, and notice to candidates ten business days before the tool is used. The statute defines such a tool on three prongs, and the third is whether it “substantially assists or replaces discretionary decision-making.”

The posting does not cite the law, so that connection is an inference, and it is drawn from three features: the third prong quoted almost word for word, the route to request an alternative process, and the commitment to publish bias-audit results. The law permits the notice to be delivered in a job posting, which is why any of it sits in a requisition at all.

A fourth feature looked like evidence and is not. The posting also names ten business days, which is the same figure the statute uses. But the statute’s ten days is notice owed to the candidate before the tool runs, and the posting’s ten days is the applicant’s own deadline to write in and opt out after applying. The clock runs in opposite directions. I had it in the list of matches before I checked which way it pointed, and a fourth match would have made the inference look stronger than it is.

Now look at what the law asks for, because it lands in a particular place. The notice must tell the candidate which job qualifications the tool will assess. The audit must calculate selection rates and impact ratios by sex, race and ethnicity, and the city’s Department of Consumer and Worker Protection, which enforces the law, says in its own guidance that nothing requires an employer to act on what the audit finds. And the city’s rules describe the tool as one that predicts a candidate’s fit for the job or likelihood of success.

So the qualifications get published, the distribution gets measured every year, and nothing in the statute asks anyone to establish that those qualifications are what the job needs. Fit for the job is the thing being predicted, and the role’s decision scope is not among the things anyone has to write down. The regulator reached the specified half of the document too.

Job-relatedness has sat in federal employment law, which is why a municipal audit statute never needed to carry it. That settlement is moving: in June 2026 the Justice Department advised the Equal Employment Opportunity Commission that its disparate-impact guidelines are unconstitutional. The detail sits outside this essay’s question. Neither regime asks what decisions the role holds.

That is a claim about where Local Law 144 reaches. It is not a claim that the law is badly built, since it was written to catch disparate impact and it does that.

The corpus adds up to this. The one clean statement of where machine judgment stops sits in a legal notice, it was written because a regulator required it, and it governs the AI that screens the applicant rather than any AI the job is about.

I am not going to argue that these documents should have specified what an AI system may decide. A requisition is a hiring document and that boundary belongs in a model-risk policy or an operating charter, if it is written anywhere. The point runs the other way. Dividing decisions between a person and a system means naming the decisions first and then saying which side each one falls on. Forty-two of these documents never complete the first step. Whatever the division turns out to be, it cannot be recorded in a document that has not said what the role settles, because there is nothing there to divide.

What has to be written down

Three asks, addressed to three different people.

To whoever is leading the transformation. An AI redesign is mostly a redesign of decisions: one moves from a person to a system, or from three people to one, or from a weekly meeting to a threshold in a config file. When a decision moves, the role document that used to hold it has to change in the same cycle, and the change has to name who settles it now. Not who owns the area, not who is accountable for the outcome — who settles it. Ownership is a different question with its own answer, and the one I would give is about where a function reports rather than what it is called. If that edit does not happen, the redesign exists in the design deck and the organization’s founding documents still describe the operating model you replaced.

This is deliberately a low bar. It is one sentence per moved decision, and it is a statement about the job rather than about the candidate. It is low because the failure mode in this corpus is absence, and a bar that requires a working group will not clear.

To whoever writes or approves the requisition. A requirements section states what a person must bring. Add one line stating what the role settles without another signature, and put it next to the requirements rather than in a section further down. Then what the document asks of the candidate and what it grants the role sit on the same page. That line is what a screening tool has no way to infer, and what a new hire currently reconstructs by trying something and seeing whether anyone objects.

One employer in these sixty-six already writes that line, and it is the quantum computing company from earlier. Its operating-model section says the role “holds decision rights over IT-owned data architecture, data-platform roadmap, integration standards, cataloging, metadata, lineage, and data-governance workflows; functional owners retain decision rights over domain definitions.” Name the decisions, then name what somebody else keeps. Set that next to owns data strategy and the difference needs no explaining.

A gap sits between that ask and the one before it. The person who can see that a decision moved is usually not the person who can edit the requisition. Nothing in this corpus says who the handoff goes to, and neither the Microsoft nor the Deloitte report says either, since neither goes near hiring. Sponsor, talent officer, works council in a European context: I do not know. The ask stands anyway. A document nobody has been assigned to change is the condition being described.

To whoever does organizational design or leadership development. The three questions run against a set of role documents. Take the ten most senior data and analytics ones you have and ask each question of each document. Does it name an attribute required of the person? Does it name a decision that person settles without another signature? Does it name how anyone will know their calls were good? Then compare against ninety-eight, thirty-five and eleven, and treat the comparison as the beginning of a conversation rather than the end of one. If your organization looks like the corpus, the finding is not that you are behind everyone else. The middle number and the last number are the ones your leadership development program has been compensating for all along.

Whoever takes one of these sixty-six roles will work out what they are allowed to decide the way people always have. They will try something and see whether anyone objects. That repair has always been done by a person, and it is worth asking what happens to it when the thing on the other side of the boundary is not one. The attributes were written down. In forty-two of these documents, what the role may settle was not.

Written September 2026 for the Analytic Bytes Library. Sixty-six postings for director-level and above data, analytics and AI leadership roles, captured between 29 April and 28 August 2026. No employer is named and every quotation is verbatim. The full coding rules, the disagreements and the adjudication lines are held with the corpus rather than repeated here; the sensitivity of the counts to where the lines were drawn is stated in the text. One disclosure the body does not carry: an earlier pass over the same sixty-six used narrower markers built while reading, and its counts are superseded and cited nowhere. Three external facts were verified against primary sources — Local Law 144 of 2021 against the New York City Department of Consumer and Worker Protection’s AEDT page, the Office of Legal Counsel opinion on disparate-impact liability issued to the EEOC on 9 June 2026, and the Labor Department’s request for information, Modernizing Federal Workforce Information Tools, 91 FR 34833.