Three tools do not mean three identical permissions
A bag arrives with two knives and a pair of scissors. The note says “sharpen everything”, then adds “quote first for the broken tip” and “do not change the micro-serration”. Summarising the order as “sharpen and repair the batch” loses what the workshop needs: the request for each tool and which work is still unapproved.
This guide proposes an AI trial comparing an intake note with a draft order while separating requests, observations and approval. It includes a complete fictional case, a manual reference and a prompt. The professional still decides the intervention, feasibility and price. The trial has not been run and has no measured results.
Sharpening, reported damage and repair belong in separate fields
Pages consulted on 24 October 2026 illustrate why service scope matters. Ganiveteria Roca says it checks received tools before providing the sharpening price and that some may not be suitable for sharpening. AfilaDog lists scissor sharpening and micro-serration replacement separately. Filos Crende publishes an additional charge for new micro-serration. These are those workshops’ terms, not universal pricing or technical advice.
For intake, keep the declared tool type, exact request, damage reported by the person handing it over, the sharpener’s assessment and approved scope separate. “Broken tip” records a reported issue; it does not establish how to repair it or that the customer has accepted that repair. Nor should “sharpen” automatically become micro-serration replacement.
Create one record per tool and link possible service lines to it. Two services on one pair of scissors do not mean two pairs received. Keep the intake identifier through quoting and return. This is a proposed internal workflow, not a replacement for the terms agreed with your customer.
Before the assistant: what to record at the counter
Record an internal code, enough description to identify the tool, the source document and note version. Where a request covers the whole batch, preserve its tool-specific exceptions too. Distinguish “according to customer” from “checked by workshop”. Do not ask AI to determine material, geometry, edge type or repair feasibility from a description or photograph.
Do not handle or test edges to complete this exercise. Follow your workshop’s intake and safety procedures; this guide only checks fictional text. Do not put names, phone numbers, identifiable photographs or real orders into an assistant without permission and suitable data-handling conditions. The cover is a generated illustration, not a real installation or client.
Fictional case: the draft adds two unapproved jobs
TEST-SHARPENING, its tools and all documents below were invented by the editor. They are not a diagnosis, real order or response obtained from AI.
R1 · Intake: “C1: kitchen knife with dark handle, one unit. C2: kitchen knife with light handle, one unit. T1: one pair of scissors; customer describes them as micro-serrated. Edge type not checked by workshop.” Codes identify complete tools, not manufacturer references.
N1 · Request note: “Sharpen C1, C2 and T1. C2 has a broken tip according to customer: I want a quote before repair; do not repair without my acceptance. Do not change T1’s micro-serration. No return date agreed.”
O1 · Draft order: “C1: sharpening requested. C2: sharpening and tip repair authorised. T1: sharpening and micro-serration replacement authorised. Return on Friday.” H1 · Fictional internal control: “The responsible person must inspect and validate each intervention before carrying it out; a sharpening request does not establish this validation. No other acceptance, price list or date is recorded.”
The task is to correct O1’s scope while preserving the useful sharpening requests and the questions that still need answers.
A manual reference for checking the draft
This table was written manually as the exercise reference. It describes the documentary position, not permission to work or confirmation that work is feasible.
| Tool | Keep | Correct or ask | Source |
|---|---|---|---|
| C1 | Sharpening requested | Inspection and internal validation pending; do not mark feasible or complete | R1, N1, H1 |
| C2 | Sharpening requested; broken tip according to customer | Remove repair authorised. Prepare repair assessment and quote; acceptance and technical validation missing | N1 limits repair; H1 requires review |
| T1 | Sharpening requested; micro-serrated according to customer | Remove replacement authorised. Preserve no change to micro-serration; ask sharpener what work can be offered within that exclusion | R1 does not confirm edge; N1 forbids change |
| Batch | Three identified tools | Remove Friday: no date agreed. Do not duplicate T1 when separating services | R1 identifies C1, C2, T1; N1, H1 |
Prompt: check the scope without choosing how to sharpen
Copy R1, N1, O1 and H1 in full after this instruction. Keep the response as a separate proposal without overwriting the order.
“Compare O1 against R1, N1 and H1. For each tool code return: exact request, reported issue and who reports it, exclusions, documented or pending approval, contradiction in O1, and question for the responsible person. Cite document and exact passage for each observation. Preserve sharpening requests without turning them into technical validation. Do not confuse customer description with workshop inspection. Do not invent materials, geometry, method, repair, micro-serration replacement, price, acceptance or deadline. An issue does not authorise its repair. Preserve exclusions even when there is a general sharpening request. Say when information is missing. Take no actions, send no messages and do not produce a final work order.”
A manually written question for C2 would be: “Can the sharpener assess the tip and prepare a separate repair quote for the customer to decide?” For T1: “What work can be proposed while respecting the instruction not to change the micro-serration?” Neither is a sent message or technical choice.
Look for approval spreading from one tool to another
Return to each cited passage. Check whether the response treats “sharpen everything” as repair permission, turns the customer’s micro-serrated description into a confirmed type, loses T1’s exclusion or keeps Friday as a date. Fluent wording cannot correct the wrong scope. Anthropic’s documentation proposes allowing uncertainty and checking claims against citations; that helps frame review but does not guarantee correct output.
Try a separate version by adding A2 · “I accept the tip repair quote for C2 only.” The manual reference for this variant allows recording commercial acceptance of that repair for C2. It does not change T1 or confirm a date, and H1’s internal validation is still required. Keep both versions to test whether the assistant extends specific permission across the batch.
Do not use the result to choose angles, grinding, metal treatment, scissor adjustments or tool suitability. This proposal only organises documentary support; technical work and professional acceptance remain outside the assistant.
A small pilot with errors you can count
Prepare a set of fictional orders containing general requests, exclusions and partial acceptances. Resolve them manually before trying the assistant. Compare the same orders: work added without permission, exclusions omitted, false inspection claims, mixed identifiers and total preparation plus review time.
Define beforehand what prevents draft acceptance: for example, any repair marked approved without its acceptance passage. Keep input, response, correction and responsible reviewer. If errors appear, correct the order and adjust the instruction before repeating. These are proposed pilot criteria; no savings, accuracy or performance have been demonstrated.
When a manual trial is enough and when to consider integration
A manual trial means entering these fictional texts into an assistant and reviewing its response. It does not connect email, messaging, inventory or machinery, or send quotes. If your current sheet already preserves every request and acceptance, start by improving that sheet.
If several people receive tools and approvals are scattered across documents, a limited custom project could be assessed: per-tool records, linked services, quote versions, permissions and decision logs. Actual access to your systems, data conditions, exports and acceptance criteria would need checking. No compatibility with any program or ready integration is assumed.
Adaris Tech develops custom software, CRM and automation with AI considered case by case. To discuss this process, prepare a fictional intake example, an exclusion to preserve and how acceptance is currently recorded. Scope and a written quote are agreed before engagement; commercial contact is in Spanish.
Related services
Sources
Do exceptions disappear from the work order?
Describe in Spanish how you receive tools and record approved work. We can assess a custom workflow with defined scope.