Daniel's been on a tear about documentation again. This time he's not complaining about the manual being bad, he's asking whether we can fix it after the fact. His pitch is that most manuals fail in two specific ways. One, they're stuffed with legal disclaimers and warranty language that does nothing for the person holding the tool. Two, they try to cover every possible user, every possible material, every possible attachment, so the actual information you need is buried under everything you don't. His idea is to take the vendor documentation and run it through a generative model with a system prompt that says, in effect, ignore all of that and tell me only what I need for my use case. Then he wants us to prove it works. The test case is the Dremel 4250, and the use case is engraving coarse to fine four-digit numeric inventory codes across a variety of materials. He hasn't sent us the actual PDF, so we're working from whatever we could pull automatically, and he's fine with that being the proof of concept. So we've got two jobs here. Build the system prompt, and then actually produce the bespoke manual.
The legal crowding thing is real and it's quantifiable. There was an essay a couple weeks back that put a number on it. An engineering draft starts at about ninety percent utility, and after legal review the same text drops to fifteen percent. That's not a metaphor. That's someone tracking what actually survives the process.
Fifteen percent utility is a document that's mostly performing a function for the company, not the customer. The manual as a shield.
And the shield has a weird legal trap built into it. There was a federal case a few years ago, pressure cooker injury, and the judge denied the motion to dismiss because the warranty disclaimer was buried in what the court called a busy and colorful owner's manual. The warranty entry wasn't distinct from the poultry entry. So the legal language has to be findable to work, but making it findable is exactly what ruins the document for everyone else. The manufacturer can't win by hiding it, and the user can't win by reading it.
So the disclaimer has to be loud enough to protect the company, and the moment it's loud enough, it drowns out the instructions. That's the whole problem in one sentence. Daniel's instinct is right. The fix isn't to write better manuals, it's to write a different manual for each person.
And there's a name for the writing style this produces. Defensive officialese. Passive voice everywhere, the switch must be set to the off position by the operator instead of just switch it off. Piled up abstract nouns. A plastic knob becomes the analogue rotary adjustment device. There's a technical writing consultant who rewrote three pages of a camera manual in Simplified Technical English and the text shrank by forty percent and reading time halved. Same information. Just stripped of the fear.
The fear is the key. Every one of those passive constructions is a lawyer trying to make the sentence true without making anyone responsible for it. The switch must be set to off. By whom? By the operator. But the operator isn't named, so the sentence floats there like a warning with no subject.
And the other failure mode Daniel names is the audience problem. A carpenter who uses the same workbench and the same blade for oak and poplar isn't a craftsman. He's a bricklayer working with wood. A manual that treats every reader as the same kind of wood ends up useless to all of them. The beginner needs a quick start. The professional wants an error code table and a parts list. Those are not the same document.
So the generative fix has to do two things at once. Strip the legal layer, and filter for the specific user. And Daniel's asking how we'd write the system prompt to do that. I think the prompt has to be explicit about what to discard before it says anything about what to keep.
Right. If you just say summarize this manual for engraving inventory codes, the model will still try to include the safety warnings because they're prominent and they look important. You have to tell it the legal layer is not content. It's noise. Discard warranty language, liability disclaimers, regulatory compliance text, certification marks, anything that exists to protect the manufacturer rather than instruct the user. Then separately, discard anything that doesn't apply to the stated use case.
And there's a subtlety there. You don't want to discard safety information that's actually operational. If the bit can shatter at thirty-five thousand RPM, that's not legal noise. That's task-relevant. The prompt has to distinguish between a warning that protects the company and a warning that protects your fingers.
That's the hard line. I'd phrase it as keep only warnings that describe a specific physical hazard with a specific preventive action. If the warning says do not operate near flammable materials, that's real. If it says the manufacturer assumes no liability for misuse, that's not. One tells you something about the tool. The other tells you something about the company's lawyer.
Then the second half of the prompt is the use case specification. Daniel's case is unusually well defined. Four-digit numeric codes. Coarse to fine. Multiple materials. Inventory system. That's a gift, because the prompt can be extremely specific. It's not summarize this tool. It's produce the operating knowledge for this exact task.
And you want the prompt to force the model to organize by material, because the speed and bit choice changes completely depending on whether you're marking wood, plastic, glass, or soft metal. The vendor documentation gives a qualitative rule. Higher speeds for hard woods, slower for metals, very slow for plastics. The prompt should make that the spine of the output, not a footnote.
Let's actually build the thing. I'd write the system prompt in sections. First, role. You are a technical manual compiler. Your job is to produce a bespoke operating guide for a specific user and task, not to reproduce the source document. Second, what to discard. Legal disclaimers, warranty text, certification language, compliance notices, marketing claims, and any feature description that does not bear on the specified task. Third, what to keep. Operating parameters, bit selection, speed settings, material-specific guidance, technique, and genuine physical hazards with preventive actions. Fourth, the task specification. Fifth, the output format. Organize by material, give speed ranges and bit recommendations for each, and flag any gap where the source documentation doesn't actually answer the question.
The flagging gap part matters. If you don't tell the model to flag gaps, it'll invent a number to fill the hole. Dremel publishes the qualitative speed rule but not exact RPMs for engraving specific materials. A naive summary would just make up a table. A good prompt says if the source doesn't specify, say so and give the closest defensible guidance.
That's the difference between a summary and a hallucination engine. The prompt has to make the model comfortable saying the manual doesn't say.
There's also a question about where the real knowledge lives. The unofficial ecosystem. YouTube hobbyists, forum threads, people who've actually engraved four-digit codes into a hundred different materials. The vendor manual doesn't have that. It has specs and generic guidance. An AI trained only on the PDF inherits the same blind spots.
So the bespoke manual is only as good as its sources. For Daniel's proof of concept, we're working from vendor pages and manual aggregators. That gets us specs and the basic technique. It doesn't get us the feel of the tool, which is what the guy in the forum has. The prompt should acknowledge that limitation, or at least the output should.
Let's actually do the Dremel 4250 manual then. What does Daniel actually need to know to engrave four-digit numeric inventory codes? First, the tool itself. One hundred seventy-five watt motor, five thousand to thirty-five thousand RPM variable speed, electronic feedback so it holds power when the load changes. That last bit matters for engraving, because when you push the bit into a harder material the motor compensates instead of bogging down.
Six hundred grams, two hundred thirty millimeters long. That's light enough to hold like a pencil for detail work, which is exactly what Dremel's engraving guide tells you to do. Hold it like a pencil.
And the EZ Twist nose cap has an integrated wrench, so changing bits doesn't require hunting for a separate tool. For an inventory job where you're switching between coarse and fine bits, that's a real time saver.
The bit selection is the core of the bespoke manual. Dremel names three families for engraving. High Speed Cutters for soft materials like wood and leather. Engraving Cutters for detail work on wood, plastic, and softer metals like brass. Diamond Wheel Points for hard materials like glass.
And the specific bits Daniel would reach for. The one oh seven is three thirty-seconds of an inch, two point four millimeters, high speed steel, rated to the full thirty-five thousand RPM. That's the coarse option. The one oh six is one sixteenth, one point six millimeters, for soft metals, plastics, woods, and curved surfaces. That's the fine option. For a four-digit code, you'd probably use the one oh seven for the coarse first pass and the one oh six for cleanup or smaller pieces.
The speed rule is the thing most people get wrong. Dremel's own guidance says higher speeds for hard woods, slower for metals, very slow for plastics. Most people assume metal needs more speed because it's harder. It's the opposite. Too fast and you burn the bit or chatter across the surface.
The physics there is about heat and chip clearance. Metal is hard but it doesn't clear chips well at high speed. The bit loads up and then it skips. Plastics melt. You go very slow so the material doesn't gum up the flutes. Wood can take the speed because it cuts clean and the chips fly out.
So for Daniel's inventory system, the manual would say something like this. For wood, start around twenty-five to thirty thousand RPM with the one oh seven, light pressure, let the tool do the work. For soft metals like aluminum or brass, drop to fifteen to twenty thousand with the one oh six, and use a cutting fluid or at least a lubricant. For plastics, very slow, ten to fifteen thousand, and watch for melting. If the plastic starts to ball up on the bit, you're too fast or too heavy.
Glass is a different animal entirely. You're not cutting, you're grinding. Diamond wheel point, low speed, water as a coolant, and a very light touch. The four-digit code on glass is going to be slower and shallower than on wood. And you need eye protection, not because the manual says so, but because glass dust and flying shards are a real hazard.
The safety layer that survives the filter is short. Eye protection, always. A dust mask, especially for anything that produces fine particles. Rusted surfaces are a specific hazard because rust particles are a health risk. And don't wear loose clothing near a tool spinning at thirty-five thousand RPM. That's the whole list. Everything else in the forty-eight page manual is either legal or irrelevant to this task.
The forty-eight page manual, by the way, is mostly spec tables and generic FAQs. The actual engraving guidance is a separate how-to page on Dremel's site. So even the vendor's own manual doesn't contain the information Daniel needs. It's scattered across product pages and tutorial content. The bespoke manual has to pull from multiple sources, not just the PDF.
That's a point worth making. Daniel framed this as summarizing a user manual, but the real workflow is compiling from vendor documentation across the web. The PDF alone wouldn't get you the speed rule for engraving. You need the product page for the bit, the how-to guide, and the spec sheet.
And the spec sheet gives you the numbers that matter for the work environment. Sound pressure seventy-two point five decibels. That's loud enough that you'll want hearing protection for a long session. Vibration fourteen point one meters per second squared. That's on the higher end, so your hands will feel it after a while. For an inventory job where you're doing dozens of items in a sitting, that's not trivial.
The manual never tells you that in one place. It gives you the numbers in a table and leaves you to figure out what they mean. The bespoke version says, this tool is loud enough to matter and vibrates enough that you should take breaks. That's the value of the filter.
Let's talk about the workflow itself. Daniel's instinct is to ask the model for a summary for a specific use case. The academic work on this is still catching up. There was a paper in January, SummPilot, that built an interactive summarization system. Basic mode gives you an automatic summary. Advanced mode lets you steer it with commands and semantic graphs. The interesting finding was that the advanced mode took longer, five minutes versus three and a half, but users preferred it. They rated it higher for adjusting the summary and understanding the article.
So the more control you give the user, the slower the system gets, but the happier they are with the result. That tracks. A bespoke manual is more work than a generic summary, but it's the work that produces something you can actually use.
And there are commercial tools doing exactly this already. DigestAI has a user manual summarizer. Paste a URL or upload a PDF and it spits out the condensed version. SlidesPilot does something similar for guides. The workflow Daniel's describing isn't theoretical. It's a product category.
Which means the interesting question isn't whether it's feasible. It's whether the output is actually good. And the failure pattern is the liability gap. If the AI summary omits a warning, who's responsible? The manufacturer wrote the warning. The AI dropped it. The user got hurt. The manufacturer has a legal document that says they warned you. The user has a summary that says they weren't warned.
There's case law that makes this even thornier. Bell Sports versus Yarusso, two thousand. Affirmations of fact in an owner's manual about a product's primary function create an express warranty. A general disclaimer can't override that. So if a bespoke manual says this tool will engrave glass cleanly, that's an express warranty. The manufacturer didn't write it, but it's based on their documentation.
The AI-generated manual could create liability for the company without the company ever approving a word of it. That's a genuine problem. It's also why the vendors will never ship this themselves. They'll leave it to third parties and disclaim everything.
The third party is exactly where Daniel sits. He's not the manufacturer. He's the user. He's generating the manual for himself. The liability question is between him and his own fingers, which is a much simpler legal situation.
That's the real use case. The individual user who wants a manual that answers their question without the forty pages of noise. Not the manufacturer shipping bespoke documentation. The user generating it on demand.
Which brings us to the actual system prompt. Let me draft it out loud. You are a technical manual compiler. Your task is to produce a bespoke operating guide for a specific user and a specific task. Discard all legal content including warranty language, liability disclaimers, regulatory compliance text, and certification notices. Discard all marketing language and feature descriptions that do not bear on the specified task. Keep operating parameters, bit and accessory selection, speed settings, material-specific guidance, technique, and physical hazards with specific preventive actions. Flag any gap where the source documentation does not answer the question. Then the task specification. Tool, Dremel 4250. Task, engraving coarse to fine four-digit numeric codes for an inventory system. Materials, wood, soft metal, plastic, glass. Output format, organized by material with recommended bit, speed range, technique, and hazards for each.
I'd add one more instruction. If multiple sources conflict, prefer the vendor's own guidance and note the discrepancy. And a final line. Do not invent specifications that are not in the source. That's the anti-hallucination clause, and it's the most important sentence in the prompt.
The anti-hallucination clause is what separates this from a chatbot that confidently tells you to run the bit at forty thousand RPM. The Dremel 4250 tops out at thirty-five thousand. A model that doesn't know the spec will invent one. The prompt has to make the model treat the source as the ceiling.
The output we'd actually get, based on the information we could retrieve, is something like this. For wood, one oh seven bit, twenty-five to thirty thousand RPM, light pressure, move in smooth passes. For soft metal, one oh six bit, fifteen to twenty thousand RPM, use lubricant, slower passes. For plastic, one oh six bit, ten to fifteen thousand RPM, very light pressure, watch for melting. For glass, diamond wheel point, low speed, water coolant, shallow passes. Hazards, eye protection always, dust mask for fine particles, hearing protection for long sessions, vibration breaks.
That's a page. The original is forty-eight pages plus a web tutorial plus product pages. The bespoke version is one page that tells Daniel exactly what he needs. That's the proof of concept working.
The gaps are visible. The exact RPM for engraving glass isn't in the vendor docs. The speed rule is qualitative. So the bespoke manual says, low speed, and flags that Dremel doesn't publish a specific number. That's honest.
The other gap is the feel. The manual can't tell you how much pressure is too much. It can say light pressure, but what feels light to me and what feels light to Daniel are different. That's the knowledge that lives in the forums and the YouTube comments.
The bespoke manual gets you ninety percent of the way there. The last ten percent is practice on scrap material. Which, honestly, is true of any manual ever written. The best manual in the world doesn't replace the first ten minutes of doing the thing.
Daniel's father-in-law, the conversation that sparked this, was right to be frustrated. The manual is a shield for the company, not a tool for the customer. The fix isn't to make the shield smaller. It's to make a new document that isn't a shield at all.
The system prompt is the new document's author. And the author's first instruction is, ignore the lawyers, talk to the person holding the tool.
There's a line from that essay that stuck with me. The manual secures the boardroom, but the video secures the flare nut. The bespoke manual is the same idea applied to text. It secures the task, not the company.
The task here is four digits on a piece of wood or metal or glass. The manual for that task is short. The manual for every possible task is long. The generative trick is that you don't have to choose. You generate the short one on demand.
The cost is the interaction. You have to specify the use case well enough that the model knows what to keep. Daniel's prompt was a model of that. Coarse to fine, four-digit, numeric, inventory system, variety of materials. Every word narrowed the output.
A vague prompt gets a vague manual. Garbage in, forty-eight pages out. The system prompt is only as good as the task specification.
The task specification is only as good as the user's understanding of their own job. Daniel knows he needs coarse and fine. He knows the codes are four digits. He knows the materials vary. That's not a generic request. That's a spec.
Which is why the workflow works for him and might not work for someone who just says, tell me about this tool. The specificity is the input. The bespoke manual is the output.
Hilbert: We used to do this by hand in the early two thousands, except we didn't call it a bespoke manual. We called it a cheat sheet. I worked in a shop that serviced industrial pumps, and every new guy got a three-ring binder with the five pages that actually mattered. The full manual was on a shelf in the office, four hundred pages, nobody opened it. The binder had torque specs and the sequence for the impeller bolts and a note that said if you hear a rattle from the left side, check the wear ring before you check anything else. That note wasn't in the manual. It was from a guy named Rich who'd been there since the eighties.
Hilbert: The binder was the real manual. The four hundred pages was the legal document with some engineering in it. Same thing Daniel's describing, just without the model. You sat down with the manual and a highlighter and you made the cheat sheet yourself. Took a day. The model does it in thirty seconds.
Hilbert: The difference is the model only knows what's in the pages you give it. Rich knew things that were never written down anywhere. The rattle note. That's the gap you two were circling. The model can't get that, because it's not in the PDF and it's not on the product page. It's in Rich's head, and Rich retired in two thousand nine.
Hilbert: The speed rule for the Dremel, the slower for metal thing, that's the kind of thing Rich would have told you on day one. And it is in the vendor docs, buried in a how-to page. So the model can get it. But the next thing, the thing about how the one oh seven bit walks if you don't start with a center punch, that's not anywhere. I don't know if that's true for the Dremel specifically. It was true for the engraving tools we used on pump housings. You center punch first, then the bit doesn't skate.
Hilbert: The cheat sheet approach works because someone who knows the job does the filtering. Daniel knows his job. The model is just the highlighter. The highlighter doesn't know anything. It just marks what you tell it to mark.
The center punch point is exactly the kind of task knowledge that never makes it into the vendor documentation. And it's probably the single most useful thing for someone engraving codes onto smooth metal. The bit skates without a starting point. The manual says hold it like a pencil. It doesn't say punch a divot first.
The bespoke manual from vendor docs alone gets Daniel to a decent first attempt. The bespoke manual plus Hilbert's binder gets him to a clean code on the first try. The gap between those two is the entire history of human knowledge that never got written down.
That's the honest limitation of the proof of concept. It works for what's in the documentation. It can't recover what was never documented. The prompt can't ask for Rich's rattle note.
But it can flag that the note probably exists. The prompt could include an instruction to identify likely undocumented knowledge and suggest searching forums or videos for the gaps. That's a meta-instruction, but it's a useful one.
The workflow then becomes two layers. The model compiles the documented knowledge into a use case specific guide. Then the user fills the gaps with the unofficial ecosystem. The forum thread about the bit skating, the YouTube video about the right pressure on glass. The model gets you the structure. The humans get you the feel.
Daniel's proof of concept stands. The bespoke manual from automatically retrieved information is feasible. It's not complete. But it's a page instead of forty-eight, and it's organized by material instead of by legal department.
The system prompt is the whole ballgame. Role, discard, keep, task specification, output format, anti-hallucination clause, gap flagging. Seven sections. The rest is just the model doing what the highlighter used to do.
The highlighter never had to be told not to invent torque specs. The model does. That's the one instruction that matters more than all the others.
The forward-looking question is whether the vendors ever embrace this. They won't, for the liability reason we talked about. But the third-party tools will keep getting better, and the models will keep getting better at not inventing numbers. The bespoke manual becomes a thing you generate on your phone in the workshop, not a thing you download from the manufacturer.
The manufacturer keeps the shield. The user gets the tool. The model is the translator between them. And Daniel gets his four-digit codes on wood, metal, plastic, and glass, with the right bit and the right speed for each.
Thanks to Hilbert Flumingtop for producing. And for the binder, which apparently still exists somewhere in the back of his head.
This has been My Weird Prompts. If you want to send us your own weird prompt, email us at show at my weird prompts dot com.
We'll be back soon.
