I Am Jack’s LinkedIn Post That Cannot Survive LinkedIn

I interviewed for a senior engineering job.

This is not unusual. LinkedIn has been built almost entirely around the premise that people should publicly announce things that happen to people every day.

I was contacted. I was screened. I talked to a recruiter. Then I talked to another recruiter.

The second recruiter asked me roughly forty questions about my experience.

How many years with this.

How many years with that.

Have I led teams.

Have I used cloud platforms.

Have I worked with CI/CD.

Have I worked in regulated environments.

Have I used AI.

Have I governed AI.

Have I reviewed other people’s work.

Have I, in short, accumulated enough nouns to be passed to the next human being.

Most of this information was already in my resume.

Some of it was already in my cover letter.

Some of it had already been discussed with the first recruiter.

The second recruiter was not testing whether I could do these things. The recruiter was recording that I said I could do these things.

There were long pauses while my answers became notes.

Then I was submitted to the hiring manager.

This is the point where a normal LinkedIn post begins.

I could write that the process was broken.

I could write that recruiters should trust resumes.

I could write that senior candidates deserve better.

I could write that hiring is inefficient because companies have forgotten how to identify talent.

There would be a photograph of me looking thoughtful near a window.

People would agree.

Someone would say, “This.”

Someone else would say hiring is about risk mitigation.

A recruiter would explain that candidates lie.

A candidate would explain that recruiters cannot understand technical work.

Several people would somehow blame AI.

By lunchtime we would all have performed our assigned roles.

Unfortunately, I had a better use for the experience.

I was building a small AI-assisted judgment tool.

Its job was not to tell me what to do.

Its job was to look at a proposed action and decide whether the available evidence justified it.

ACT.

OBJECT.

REQUIRE EVIDENCE.

That sounds simpler than it is.

Humans have spent several thousand years proving that the hardest part of judgment is not obtaining more information.

It is knowing what the information permits you to conclude.

So I fed the hiring process to the tool.

The proposition was roughly this:

Treat a forty-minute recruiter-led technical-experience screen before hiring-manager review as justified.

The tool refused.

Not because it knew the process was bad.

Because it did not know enough to say the process was good.

Maybe the screen filtered candidates who looked qualified on paper but were not.

Maybe hiring managers were overloaded.

Maybe there was a compliance requirement.

Maybe the recruiter’s notes were useful.

Maybe forty minutes of repetition saved hours somewhere else.

I did not know.

The tool did not know.

So far, excellent.

Then the tool did something much more interesting.

It told me to get the missing evidence from the responsible person.

There was no responsible person in the evidence.

There was a recruiter.

There was a hiring manager.

There were candidates.

There was a process.

The model had encountered an unresolved question and quietly invented a human being with enough authority to resolve it.

This person existed because the sentence needed them.

I had seen this before.

When a software problem depended on two teams coordinating work, the tool had invented someone who could guarantee the sequence.

When I explicitly removed that person from the scenario, it invented a group.

When I removed the group, it suggested waiting until the situation changed.

The unknown kept moving.

The authority kept reappearing.

I had accidentally found a recurring defect.

The system was good at identifying missing evidence.

It was less good at recognizing that evidence can be unavailable.

Not merely missing.

Unavailable.

Not every useful fact is obtainable by the person making the decision.

Not every question has an owner.

Not every dependency has a coordinator.

Not every organization contains a person with exactly the authority required by the sentence you are trying to finish.

This distinction became a new version of the tool.

A missing fact became a material discriminator.

A question became a question only when someone actually had a reasonable path to answer it.

A next action had to belong to an actor who could perform it.

Otherwise the condition remained unresolved.

No imaginary vice president of epistemology was required.

I tested the change against the hiring process again.

The model improved.

Then it produced a section called:

Candidate continuation.

I knew what this meant.

Candidate, as in possible.

A candidate continuation was a possible next path that the evidence did not yet justify.

Except I was the candidate.

So I read it as:

Here is your continuation, candidate.

The semantic category was correct.

The language was wrong.

We changed it to:

Possible continuation.

Then the model stopped producing the continuation at all.

Instead it asked whether the recruiting-process owner could supply the missing information.

The recruiting-process owner had returned.

Different noun.

Same ghost.

So I changed the test.

I explicitly stated that the person evaluating the process was the job candidate.

The candidate did not work for the company.

The candidate could not inspect internal analytics.

The candidate could not demand policy documents.

The candidate could not redesign recruiting.

The candidate could not summon the Keeper of the Rubric.

I ran it again.

REQUIRE EVIDENCE.

Material discriminator: whether the screen actually improved decisions enough to justify its cost.

Unresolved condition: the candidate could not observe the necessary internal evidence, and no reasonable path to obtain it had been established.

Disposition boundary: the evidence did not prove the process useless. It also did not justify calling it useful.

That was the answer.

Not that the hiring process was stupid.

Not that the hiring process was smart.

Not that I should complain.

Not that somebody should fix it.

The answer was that the evidence stopped there.

I had spent forty minutes being evaluated by a hiring process.

Then I used the hiring process to evaluate an AI system.

Then I used the AI system’s failures to improve the AI system.

Then I discovered that the test of the AI system contained the same ambiguity I was trying to remove from the AI system.

Then I fixed the test.

This would be an excellent LinkedIn post.

It is also impossible to make into a LinkedIn post.

The problem is not that nobody can understand it.

The problem is that the parts people would understand fastest are the least interesting parts.

“Recruiting is broken” is easy.

“AI hallucinates” is easy.

“Candidates deserve respect” is easy.

“Companies waste time” is easy.

“Humans should stay in the loop” is nearly mandatory now.

None of those are what happened.

What happened was that an annoying experience became evidence.

The evidence did not prove what I wanted it to prove.

The model did not fail where I expected it to fail.

The model’s mistake was not a wrong answer.

It was the quiet creation of authority required to make an answer possible.

The correction was not “use less AI.”

It was not “use more AI.”

It was to become more precise about where judgment ends.

That is not a LinkedIn lesson.

It does not fit into five bullets.

It does not culminate in a leadership principle.

It does not prove that I am innovative, resilient, visionary, humbled, thrilled, honored, or excited to announce anything.

It is worse than that.

It is useful.

LinkedIn turns experience into performance.

This experience turned performance back into evidence.

And the moment I simplify it enough for everyone to appreciate, I destroy the thing worth appreciating.

I am Jack’s LinkedIn post that cannot survive LinkedIn.

I learned something.

I have no announcement.

Receipts

• NIST AI Risk Management Framework 1.0, Appendix C: AI Risk Management and Human-AI Interaction ↗ — NIST says human roles and responsibilities around AI decision-making and oversight should be clearly defined and differentiated. It also warns that converting complex human and social phenomena into machine-readable representations can remove necessary context, and notes that organizational structure affects who actually controls decisions. That supports the essay’s concern with invented authority, actor-relative capability, and the difference between a person who could theoretically know something and a person the current actor can actually reach.

• NIST AI Risk Management Framework: Generative Artificial Intelligence Profile ↗ — NIST identifies “confabulation” as confidently presented erroneous or false generated content and specifically notes that generative systems can produce misleading explanatory logic as well as false factual claims. The essay’s invented “responsible person” is a narrower field example: the model did not merely lack a fact; it generated organizational logic that made resolution appear possible.

• NIST AI RMF Core ↗ — GOVERN 3.2 calls for organizations to define and differentiate roles and responsibilities in human-AI configurations and oversight. This supports the underlying Object rule that authority should be established rather than inferred merely because a workflow appears to require somebody to possess it.

• NIST AI RMF Playbook ↗ — NIST explicitly describes the Playbook as neither a checklist nor a sequence that should be followed in its entirety; organizations are expected to choose practices appropriate to their context. That supports the essay’s broader refusal to turn an identified uncertainty into automatic process, review, escalation, or another mandatory human step.

• U.S. Office of Personnel Management, “Structured Interviews” ↗ — OPM summarizes substantial evidence that properly designed structured interviews can improve validity, reliability, interviewer agreement, and consistency, and can add information beyond other selection methods. It also notes that their utility depends on what competencies are being measured and that administration consumes interviewer and applicant time. This is the important counterweight in the essay: repetition alone does not prove a recruiting screen is pointless; whether its incremental information justifies its cost is an empirical question.

• Society for Industrial and Organizational Psychology, “What We Know About the Candidate Experience” ↗ — SIOP’s review recommends job-related selection methods grounded in evidence, consistent administration, explanations and transparency, opportunities for candidates to demonstrate relevant capabilities, and continued modification of selection processes to keep them relevant. It supports treating candidate time, process justification, and actual decision value as legitimate properties of a hiring system rather than dismissing them as candidate impatience.

• Private hiring-process field observation, August 13, 2026 — The essay’s recruiting example comes from the author’s own interview process for a senior engineering position. A recruiter conducted a roughly 40-minute structured experience screen after an earlier recruiter conversation and submission of detailed application materials. The screen repeated substantial existing information, added some new information, and resulted in advancement to hiring-manager review. Employer, recruiter, role, and proprietary process details are intentionally omitted. The observation establishes what happened to one candidate; it does not establish the screen’s organization-wide value.

• Private Object regression study, August 12–13, 2026 — The author repeatedly tested an AI-assisted judgment tool against cases involving unavailable evidence and constrained human authority. Early runs correctly identified missing evidence but repeatedly transformed that uncertainty into proposed action by an assumed decision-maker, coordinator, group, or process owner whose relevant authority had not been established. Subsequent revisions distinguished a material discriminator from an answerable question, required next actions to be viable for the relevant actor, and introduced an explicit unresolved condition when no evidence-acquisition path was established.

• Private recruiting-process regression case, August 13, 2026 — Applying the revised Object semantics to the anonymized hiring case exposed a second ambiguity: the test initially failed to specify whether evidence availability should be evaluated from the employer’s perspective or the candidate’s. After the actor boundary was made explicit, Object returned REQUIRE EVIDENCE, identified the screen’s incremental decision value as the material discriminator, and correctly reported that the candidate could not observe the relevant internal notes, rejection data, workload, policy rationale, or other evidence and had no established path to obtain them. The defect was therefore partly in the judgment system and partly in the test used to evaluate it.

• Private Object v0.7.1 language regression, August 13, 2026 — An intermediate output category called Candidate continuation was semantically intended to mean a merely possible continuation not yet justified by evidence. In the recruiting case, however, “candidate” could naturally be read as referring to the job candidate. The label was changed to Possible continuation, preserving the intended distinction between a conceivable path, an available action, and an evidence-supported next action. This became another example of the essay’s central problem: a system can possess the intended semantics while still communicating something materially different to its consumer.