Hemory TeamOn this page
“Use the large-print label for West Depot.” The ticket tells an engineer which label to maintain, but not why it matters. A compact replacement looks cleaner and fits the new packaging. Without the original explanation, the engineer cannot tell whether that change would preserve the customer’s requirement.
Document an exception with its reason, scope, and current instruction. Then state what needs to be checked before changing it. The result should help another person act correctly without applying the exception everywhere or treating it as impossible to revisit.
Start with the question the working note leaves unanswered
An exception is a departure from the usual process for a particular customer, site, group, or deliverable. Its documentation needs to explain that boundary.
“Special reporting requirements” leaves too much to recover. “Finance needs a spreadsheet for monthly reconciliation; leadership uses the dashboard” identifies who needs what and why. The same principle applies to packaging, support arrangements, training, or delivery timing.
Before writing more, identify the missing point:
- Who or what does the exception apply to?
- What practical need does it serve?
- What instruction is currently approved?
- What would need to be checked before changing it?
If the existing record already answers these questions, use it. When the reason is missing, retrieve the relevant discussion or ask a participant for a focused clarification.
Recover the reason without expanding the requirement
Suppose a captured customer discussion explains that West Depot’s receiving staff read carton identifiers from a distance because cartons remain on high shelves during intake. That explains why readability matters at this site.
If you recorded the discussion in Hemory, locate it and use conversation Q&A to ask:
Why did West Depot request the large-print label, and did the requirement apply to any other sites?
Check the relevant exchange before making the scope broader. A statement about West Depot does not establish a rule for every warehouse. Nor does the reason establish a specific font size, viewing distance, or technical acceptance threshold unless those details were actually agreed.
Hemory helps preserve the explanation while you participate in the customer conversation. When a later design change raises a new question, you can retrieve that background instead of relying on the short ticket or someone’s recollection.
If the discussion was never captured, use existing records or a participant’s clarification. Identify a later explanation as such rather than presenting reconstructed wording as an original quote.
Check the current instruction and the proposed change
The original discussion tells you why a requirement arose. The current specification tells you what the project is working from now. Compare both before writing an instruction for someone else.
In this illustrative example, the current packaging specification still requires the large-print label at West Depot. The compact replacement is only a proposal. There is no established change to the intake process or approval to replace the label.
Keep three things separate:
| Element | What the example establishes |
|---|---|
| Customer need | Staff must be able to read carton identifiers from a distance during intake |
| Current implementation | The approved specification uses the large-print label at West Depot |
| Proposed alternative | A compact label is being considered but has not been approved |
This separation leaves room for a better implementation without quietly discarding the need it must satisfy.
Copy the customer exception template
Exception / topic:
Applies to:
Reason:
Current instruction:
Before changing it:
Open question / person or process for resolution:
Source of the requirement:
Current instruction checked against:Keep action-critical details in the note itself. A source link is useful for deeper questions, but it should not carry the only explanation of the constraint.
For the West Depot example, a completed note could read:
Exception / topic
Large-print carton identifier.
Applies to
West Depot's intake process. No broader site requirement is established
by the discussion used for this note.
Reason
Receiving staff read identifiers from a distance while cartons remain
on high shelves during intake.
Current instruction
Keep the large-print label required by the current packaging specification.
The compact-label proposal has not been approved for this site.
Before changing it
Check whether the intake process or readability requirement has changed.
Assess a proposed replacement against the applicable requirement and
use the existing project approval process before changing the instruction.
Open question
The available discussion does not specify a measurable readability
threshold. If the replacement requires one, clarify it with the customer
through the account contact before treating the design as acceptable.
Sources
Captured West Depot intake discussion for the reason and scope.
Current packaging specification for the applicable label instruction.The “before changing it” section is guidance for evaluating a future proposal, not a claim that the customer agreed to a new testing procedure. The open question also avoids inventing a numerical threshold to make the template look complete.
For the working ticket, you can use a shorter version:
Keep the large-print carton identifier for West Depot’s intake process, where staff read it from a distance. The compact replacement has not been approved for this site. Use the exception note and current packaging specification when evaluating a change.
Draft the note from available Hemory context
For an exception discussed across several meetings, an AI agent connected to Hemory can help bring the explanation together. Provide the current specification and proposed change separately if they are not accessible through the agent’s other tools.
Draft a customer exception note for the West Depot label.
Use the available Hemory intake discussions, the current specification,
and the compact-label proposal I provide.
Identify the customer need, applicable site or group, current instruction,
and status of the proposed change. Do not expand the exception to other
sites or invent a technical acceptance threshold.
Separate source facts from recommended checks. Flag missing information
that would affect a change, and include references where available.Review the draft and put the approved working instruction where the engineer already manages the task. Your personal Memory need not be accessible to the engineer: include the relevant permitted explanation in the shared note.
If the exception is part of a transfer of ownership, include it in the project handoff template. The new owner should not have to rediscover it after proposing a change.
Update the note when the exception changes
When an approved change replaces the instruction, update the working record and retain enough history to explain the change. Distinguish the date the customer’s process changed from the date the new instruction was approved if both matter.
Do not copy the old exception into every future project by default. Check its scope when reusing it. Equally, do not remove it merely because its original author has left or a newer design looks more convenient.
For broader problems with missing project explanations, see warning signs in project records. This note addresses one specific gap: making a known customer exception usable by the next person.
FAQ
How much detail belongs in an exception note?
Enough to identify the scope, reason, current instruction, and any condition that affects a change. Keep detailed evidence in accessible supporting material when it is not needed for everyday execution.
Does an old exception remain valid forever?
No. Check current instructions and relevant changes. The historical reason explains the exception; it does not prevent an authorized revision when circumstances change.
What if two sources disagree about the scope?
Compare the site, deliverable, version, and approval history. If the difference remains unresolved, identify that question and seek clarification before applying the exception more broadly.
Choose one customer exception that currently requires someone to explain it from memory. Use Hemory to recover its captured context, then write the reason and scope into a note the next person can act on.
