Build a repair history someone can follow.

Give a unit a permanent label such as Unit A. Keep the serial number privately beside it. If the unit moves to another room, retain its label and record the move. If the entire unit is replaced, assign a new identifier and link the old and new records.

An incident begins with a reported problem. It may involve several suspected components, visits or replacement parts. Do not count every message, ticket or part as a separate equipment failure. A later recurrence can have its own incident, linked to the earlier one, without assuming the cause is identical.

Field	What belongs here
Unit and incident ID	Stable identifiers and the relevant ticket references
First observation	Date, symptom and who observed it
Operating effect	Fully unavailable, limited operation, usable with an unresolved issue, or unknown
Diagnosis	Attributed technician or engineering conclusion, with source
Authorized work	Approved parts, labor and any stated limits
Completed work	What the work order says was actually done
Verification	Dated observations after service
Cost status	Quoted, authorized, paid, reimbursed or disputed
Current outcome	Resolved, unresolved, disputed or unknown, with an observation date

Leave an unknown field marked unknown. That is more useful than silently filling a gap from memory.

Keep the original email or service document, including attachments. Give it a short reference in the ledger. A screenshot may be useful for a quick view, but retain the original where available so dates, participants and context can be checked.

Distinguish an owner’s observation, a support agent’s suggestion and a technician’s diagnosis. For example, water near a chiller establishes an observed leak location. It does not by itself establish which internal component failed or why.

If records conflict, write down the conflict. Do not force an apparently complete chronology by choosing whichever version strengthens the complaint.

Store the first unavailable date and the date usable operation was confirmed. State whether your count includes both endpoints and how partial days are treated. For an unresolved case, report that it remained open as of a particular date.

Keep unit downtime separate from a site’s total shutdown. Three unavailable units on one day produce three unit-days of lost capacity and one calendar day with all three unavailable. Those measures answer different questions.

A repair estimate is not a payment. A provider authorization is not proof that the vendor was paid. A paid invoice may later be reimbursed. Give each transaction its own status, payer, date and source, then calculate the owner’s remaining expense.

Label hypothetical examples clearly. If a fictional repair costs $600 and $450 is reimbursed, the unreimbursed amount is $150. That example says nothing about an actual customer’s coverage or entitlement.

Remove addresses, order numbers, serial numbers, personal contact details and unrelated third-party information from a public copy. Preserve a private original. Decide separately whether to contribute an account to a public record, publish it yourself or provide it to an identified adviser.

An organized file helps people assess what happened. It does not, by itself, establish a product-wide defect, legal liability or membership in a class action. The value comes from making the evidence and the gaps equally visible.

Use the worksheet below to assemble the unit identity, incident timeline, current condition and next requested action. Keep originals private and make a separate redacted sharing copy. Include successful repairs and later corrections as carefully as the original problem.