Documentation repair floor

Keep LLM docs useful after the system changes.

LLM Docs Maintenance Bay is arranged like a real workshop: incoming release notes land on the intake rail, instruction fragments move through labeled drawers, and published pages leave only after they can be cited, retrieved, and understood by both humans and answer engines. The focus is not a glossy documentation portal. It is the maintenance work that prevents stale examples, missing caveats, and confident but obsolete model answers.

Documentation maintenance bench with review cards and instruction drawers
The bay model: receive a change, separate the moving parts, rebuild the public note, then test the answer path.

The maintenance corridor

A documentation set for LLM use fails quietly. The page still loads, the snippet still looks familiar, and the model still answers with an old assumption. This site studies the repair corridor between a product change and a trustworthy answer: what to inspect, what to rename, what to keep visible, and what to retire with a trace.

Receipt

Every product change arrives with owner, affected docs, model-facing risk, and expected answer behavior.

Disassembly

Instructions, examples, retrieval hints, and public wording are separated before anyone rewrites them.

Reassembly

The final page returns with a compact summary, updated caveats, source anchors, and test prompts.

A narrow implementation corridor lined with document stations

What belongs on the bench

The bay prefers tangible maintenance artifacts over vague guidance: change receipts, contradiction lists, example inventories, prompt probes, citation coverage notes, and small instruction cards that can be swapped without rewriting the whole system. A good document is not merely current on publication day. It gives the next editor enough structure to discover where future drift will appear.

Public notes should name the boundary they protect.

Examples should carry the version assumption they depend on.

Instructions should be short enough to audit under pressure.

Sitemaps and semantic pages should expose the latest repairs.

Bench notes from a live doc repair

BN-01

A deprecated parameter is not only removed from a page. Its examples, model answers, snippets, and fallback language are traced before publication.

BN-02

Model instructions are kept in small named drawers: role, boundary, evidence, refusal, citation, and escalation. Mixing them makes audits slow.

BN-03

Release notes are treated as repair tickets. The maintenance bay asks what changed, who needs to know, which old answer becomes unsafe, and what exact sentence should replace it.

Labeled drawers for modular model instruction cards
Instruction libraries work best when each drawer has one job and one owner.