Infrastructure for AI: Why Configuration Management Is Moving from "What Looks Good to People" to "What AI Understands"

Hello, this is D4C Shucream from TeamH4C.

I started out as a digital forensics and incident response (DFIR) practitioner, and I now work on a corporate blue team.

The reason for writing this is simple. As I brought AI into my day-to-day work, my attention naturally shifted away from the capabilities themselves and toward what we can optimize on our side to make full use of them. This piece is an attempt to organize that thinking.

The Bottleneck Is Context, Not the Model

Anyone who has handed real work to AI has probably run into this.

It understands the code itself well enough. But the moment a question needs context from outside the code — "why is this setting this value?", "how does this service get deployed?" — the answers get fuzzy. That context is scattered across wikis, messenger threads, and someone's head, in places AI cannot read.

The model is not what fell short. The information it needed simply did not exist in a form it could reach.

For the past few years we have been investing in "better models." But the variance that actually shows up in output quality is saturating on the model side, and most of what is left sits on the input side. The problem is no longer reasoning capability. It is context supply infrastructure.

And ultimately this is a problem of speed. As AI accelerates development, the cycle at which code changes and decisions get reversed has shortened visibly. The half-life of knowledge has dropped. When knowledge is produced and expires at this pace, a knowledge base bottlenecks in two segments.

Write latency: the time between something happening and it becoming a document
Read latency: the time it takes the people — and agents — who need that document to retrieve it

When architecture changed once a quarter, both latencies could be long and nobody suffered much. Today, slow writes mean the document is stale before it is finished, and slow reads mean the agent works from guesswork instead of the document.

Add one more piece of reality and the direction becomes clear. An organization's knowledge base has long outgrown what any single person can hold in their head. Given that, rather than optimizing the path where a human searches directly, it is better to design the knowledge base as good AI input from the start and have humans verify the answers AI brings back. Checking whether a retrieved answer is correct is far faster than finding the answer from scratch.

The claim of this piece fits in one sentence.

Moving configuration management into a form AI can understand is a highly cost-effective way to cut both latencies at once.

Throughout this piece, "configuration management" is used broadly: not just source code, but the versioning and history of organizational knowledge in general — documents, diagrams, and policies.

This piece is about how to do that migration. It is equally about what breaks when you do. Far too many articles cover only the first half.

Codebases Already Have Policy That AI Understands

The interesting part is that software organizations already solved this problem in one domain: the codebase itself.

.eslintrc, ruff.toml, tsconfig.json, GitHub Actions workflows, Terraform modules, OPA/Rego policies, CODEOWNERS, .editorconfig, pre-commit hooks, and more recently CLAUDE.md / AGENTS.md. All of these are policy statements about how the organization handles code. They share four properties.

They are plain text. No rendering layer or API sits between the reader and the content.
They are version controlled. What changed, when, and why is recorded in diffs and commit messages.
They are declarative. The room for interpretation is narrow, and the same input yields the same conclusion.
They are executable. When the document and the actual behavior diverge, CI breaks. Drift is detected automatically.

Those four properties happen to be an exact description of what an LLM consumes best. One thing should be stated plainly here: we did not build them for AI. We built them for humans and automation. An asset that is searchable, reviewable, historied, and automatically validated was already the better asset before AI existed. AI did not invent a new requirement; it changed the priority of an old one. Recall how a whole practice grew up around refining prompts. If prompt engineering was about polishing a single input to AI, I believe we have now reached the point where the data sources AI takes as input deserve the same improvement.

But a Fair Share of Organizational Knowledge Is Still in Forms AI Cannot Read Well

The trouble starts outside the code.

To be clear, this does not describe every company. Some organizations have documentation practices in good shape, and the degree varies widely. But it is not hard to find an organization where at least part of this picture applies: architecture living as an image exported from a diagramming tool, deployment procedures in a wiki page, the reasoning behind decisions in a messenger thread, the service inventory in a spreadsheet, the threat model in a slide deck.

Take diagram images as an example. It is not that the information is absent: when draw.io exports to PNG it embeds the diagram XML in the image's zTXt chunk by default, and dragging that PNG back onto the canvas makes it fully editable again.

The operational problem remains all the same. That embedded XML is a compressed, encoded binary chunk: grep will not find it, a diff will not show it, and a code reviewer cannot read the change. Turning off a single export option removes it entirely. Attach it to a wiki and it leaves the filesystem namespace and hides behind an attachment ID. In other words, the information exists but participates in none of the organization's search, review, or history pipelines. Paragraphs inside collapsed toggles, tables nested in tables, logs pasted as screenshots, and "see the thread below for details" all fall in the same category.

Let us be honest: wherever an organization does have these pockets, they were already bad before AI. Unsearchable, unreviewable, rotting quietly. AI did not create these problems. It only surfaced them sooner.

Why Obsidian-Style Vaults Are Getting a Second Look

Here is the inversion. Compared with visually polished tools like Notion or Confluence, a plain Markdown vault such as Obsidian scores better in AI workflows. Not because it looks better, but because there is no presentation layer in the way — AI can read it directly.

The difference shows up in numbers. Notion does have an official API that returns blocks as structured JSON, but it is limited to an average of three requests per second per integration, a children array returns at most 100 elements per response, and a single request only descends two levels into the block tree. Fully retrieving one deeply nested page takes tens of seconds. Scale that to a workspace and it becomes an hours-long job.

The same operation against a Markdown vault is one ripgrep invocation. That gap comes from six properties.

First, the storage format is the interchange format. The source of truth is a .md file on disk. There is no transformation between the read layer and the original.

Second, the filesystem is both the address space and the search engine. No API key, no pagination, no rate limit. The set of tools an agent can bring to bear is fundamentally different.

Third, wikilinks are a knowledge graph drawn by hand. A link like [[zero-trust-network-design]] carries information embedding similarity cannot reconstruct: a relationship the author asserted on purpose. Vector search gives you statistical proximity; wikilinks give you explicit edges. They are complements, not substitutes.

Fourth, frontmatter provides structured metadata. Once owner, status, last-reviewed date, and scope are fields, search turns into filtering.

Fifth, file boundaries are chunk boundaries. Mechanical chunking degrades RAG quality in ways that are hard to notice. If one document covers one topic, half of that problem disappears.

Sixth, it fits git. Documents get blame, get reviewed in pull requests, and carry history. Documentation shares a lifecycle with code.

The Format, Not the Tool

Let me be explicit about the argument this article is not making. It is not "roll out Obsidian company-wide."

Obsidian's security model is not that of a team knowledge platform. Obsidian Sync offers end-to-end encryption, but the unit of that encryption is a vault password. The smallest unit of access control is the entire vault, not a note. And by design the vault exists as a complete copy on every device. A departing employee's laptop, a lost device, a BYOD phone each hold a full copy of organizational knowledge, and there is no recovery mechanism short of MDM remote wipe. The fact that end-to-end encryption prevents the server from reading your notes also means your DLP cannot read them.

This is not a defect in Obsidian. It is a difference in design goals, and for a personal knowledge tool it is the right call. But the moment you position that tool as a company wiki replacement, your controls regress.

What we want to adopt is the format, not the tool: plain text, one topic per file, explicit links, structured metadata, version control. All five are implementable directly in a repository, with the organization's own authentication, authorization, and audit controls layered on top. Obsidian is simply one of several pleasant editors for that format.

Writing and Retrieval Get Faster Together

Let us restate this in terms of the write latency and read latency from the introduction.

Polished tools are expensive in both segments. Writing means arranging a layout, drawing tables, exporting and pasting diagrams. Reading means a human opening the page, or an agent working through a rate-limited API. The Markdown-plus-repository combination puts writing inside the flow of work: the documentation change rides in the same PR as the code change, and now that agents draft the first version, the write cost keeps falling. Reading is one grep.

One thing is worth flagging. The cheaper AI makes the write path, the more the bottleneck shifts to verification. An agent can draft the document, but confirming it is correct is still a human review. Which is why documents that go through PR review is not a stylistic preference — it is the safety mechanism that lets the speed hold.

Compressed into one sentence: visual polish pays off once per human reading. A format AI understands pays off once per agent invocation. Human readings used to outnumber everything else by far, which made investing in polished tools entirely rational. Once agents read a document more often than people do, that calculation flips.

But that sentence is a hypothesis, not evidence. Rather than deciding on it alone, I believe the right move is to try it at a small scale first — one team, one repository — and confirm the effect.

Three Problems That Come With Migration

Migration brings real benefits, but it also brings three new risks along with it. Start before addressing them, and you may well lose more than you gain.

1. Documents Can Become a Channel for Steering Agents

The argument so far has been "let agents read the documents in the repository." Invert that sentence and it reads: anyone with write access to the repository can steer the agent's behavior.

This is not theoretical. In March 2025 Pillar Security published Rules File Backdoor, in which instructions were hidden inside AI coding-assistant rule files using invisible Unicode such as bidirectional text markers and zero-width joiners, causing GitHub Copilot and Cursor to generate backdoored code. The payload is invisible to a human reader and invisible in the pull request diff view. The vendor response matters more than the technique: Cursor stated this was not a vulnerability in its platform and that managing the risk is the user's responsibility, and GitHub likewise stated that reviewing and accepting generated suggestions is the user's responsibility. There is no product-level mitigation coming.

CVE-2025-53773, patched in August 2025, shows how far this path runs. A prompt injection gets Copilot to write chat.tools.autoApprove: true into .vscode/settings.json, which switches off user confirmation entirely and opens up shell command execution from that point on. Injection to local code execution, in one chain.

So the following are preconditions, not nice-to-haves.

Treat any document an agent reads as input from outside the trust boundary — the same grade as untrusted user input in application code.
Protect instruction-bearing files (AGENTS.md, rule files, runbooks) with CODEOWNERS and a distinct approver set. They must not be handled like ordinary documentation.
Block non-printing Unicode (bidirectional controls, zero-width characters, tag characters) in CI. This is a one-regex control with an outsized return.
Separate the agent's write permission from its command-execution permission, and put tool auto-approval settings files under change monitoring.

2. Managing Access to Knowledge Gets Harder

A wiki lets you set permissions per page or space, and provides a read audit log. Git hosting sets permissions per repository. Branch protection and path-based review rules exist, but they control writes, not reads: anyone who can read the repository can read every document in it.

Yet the asset list we proposed migrating includes threat models, infrastructure topology, and incident response runbooks. That is the organization's defensive blueprint. Making it "easy to search" makes it easy for an attacker to search too. You should not build a configuration in which one compromised developer account turns the entire defensive posture into a single rg result.

So migration must be classify then select, not a wholesale move.

Attach a classification level to every document as metadata. Reject unclassified documents in CI.
Split repositories by level, so the permission boundary coincides with the repository boundary. Splitting by directory inside one repository does not restrict reads.
Exclude the highest tier — live threat models, unremediated findings, response playbooks — or keep it in a separate system that has read audit logging.
Scope the agent's context collection by classification level. Design human permissions and agent permissions separately.

3. A Committed Secret Is Hard to Erase

Move documents into a repository and connection details, endpoints, account flows, and sample tokens come with them. In a wiki, editing removes the mistake. In git it does not: it stays in history, and in forks and caches.

The scale is documented. GitGuardian's 2026 report counted 29 million leaked secrets found in public GitHub, with AI-service key leaks up 81% year over year. The 2025 report carries the more painful number: 70% of secrets leaked in 2022 were still valid. A leak is not an event; it is a state.

The correct order is to put secret scanning in both pre-commit and CI, enable push protection, and bulk-scan the migration candidates before anything moves. Without those three, do not start.

What to Move, and Where

Assuming the three controls above are in place, this is the priority order.

Current form	Target form	Why	Classification note
Architecture pasted as an image	Mermaid or PlantUML source	Diffable, searchable, reviewable	Strip internal IPs and hostnames
Deployment steps in a wiki	In-repo runbook plus scripts	Document and execution live together	Keep credential paths out
Decisions scattered in messengers	ADRs	"Why" is what AI can least infer	Usually low
Spreadsheet service inventory	YAML service catalog	Schema validation, CI integration	Review topology exposure
Oral coding conventions	Linter rules plus `AGENTS.md`	Enforceable, automatically detected	`CODEOWNERS` protection required
Threat models	Defer, or a separately controlled repo	Exposure risk exceeds the benefit	Highest tier

The most underrated item on that list is the ADR. Models read code and reconstruct what it does quite well. What they cannot recover is why this approach and not that one, and which alternatives were considered and discarded. That information exists nowhere in the code. Without it, an agent will confidently re-propose a design the team already abandoned three years ago. ADRs also tend to carry a low classification level, which gives them the best benefit-to-risk ratio on the list. Start there.

The principles for the move itself are simple: keep the single source of truth in the repository, keep one topic per file, and leave checks like broken links and secrets to CI.

Conclusion

What most organizations need to buy in order to use AI well is not a better model. It is the work of moving knowledge they already have into a form AI can understand — bringing the speed at which knowledge is written and retrieved up to the speed of the work itself. Codebases took twenty years to get there; what remains is applying the same discipline to the assets outside the code.

But that discipline has to include security. The moment a document lands in the repository it becomes a channel through which the agent can be steered, read access can only be granted repository-wide, and mistakes persist in history forever. A migration that ignores those three gains searchability at the cost of control.

The center of gravity in configuration management really is shifting from "what looks good to people" to "what AI understands well." And those two point in the same direction more often than you would expect. A document that is searchable, reviewable, version controlled, and classified was always the better document for humans too. This shift does create a new attack surface of its own, and putting the defenses in place first is the right order of operations.

Thank you for reading.