Key takeaway
A polished summary can introduce a fact the source never established. Preserve origin, interpretation and verification as separate layers.
Give each assertion an identifiable origin
A preparation team may add summaries, issue categories or outcome labels to make an archive easier to evaluate. Those additions can be useful, but they should not become indistinguishable from contemporaneous records. A later interpretation may be uncertain, disputed or wrong even when it reads confidently.
W3C PROV-DM describes derivation as relating a produced entity to earlier information and the activities involved. Zendesk’s audit reference separately describes comments and field changes. Together they support a practical distinction: what the source recorded, what a later process added and who or what produced the addition. They do not guarantee that an annotation is correct.
Identify the source record, annotation identifier, creation date, method, reviewer and supporting evidence. If the method uses a model, record the relevant configuration or procedure in the controlled preparation record. A reader should be able to reject an annotation without losing access to the original evidence.
An illustrative assertion ledger
The following hypothetical case contains an intermittent equipment fault. The original note records a replacement and a short test, but no later follow-up. A generated summary adds a claim of lasting resolution. The ledger shows exactly where that new claim entered the package.
The illustrative source sentences below are invented, not excerpts from customer records. The purpose is to test how a reviewer treats insufficient evidence. A fluent summary is not an observation, and absence of recorded recurrence is not proof that the issue never returned.
| Layer | Illustrative content | Treatment |
|---|---|---|
| Original note O17 | Intermittent noise; bearing replaced; short bench test completed | Retain as the recorded action and limited test |
| Generated summary A8 | Bearing replacement permanently resolved the fault | Flag lasting-resolution assertion as unsupported |
| Reviewer annotation A9 | Action recorded; long-term outcome unknown | Keep separate, with rationale and source O17 |
| Later observation O22 | Same symptom reported on day 11 | Add permitted source evidence; reconsider derived outcome |
| Corrected annotation A10 | Recurrence observed within the defined follow-up window | Link to O17 and O22; supersede A9 visibly |
Check added meaning before checking style
Review whether the annotation adds a cause, degree of certainty, duration, actor or outcome absent from the source. Small language changes matter: inspected is different from repaired, likely is different from confirmed, and passed a short test is different from no recurrence for a month. Preserve those distinctions even if they make the prose less tidy.
For a hypothetical preparation sample, one summary merges two visits and assigns the second visit’s outcome to the first action. Another changes a technician’s suspected cause into a confirmed diagnosis. These are interpretation errors, not merely grammar problems. Record the source references and correct the assertions before producing more summaries.
Use a review category such as supported, unsupported, contradicted or insufficient evidence. Do not use a model’s self-reported confidence as proof of a source fact. If reviewers disagree, retain the disagreement and identify what additional evidence would settle it.
Keep transformations and permissions distinct
An annotation ledger should record how a summary was produced, which source records it used and what review occurred. Keep generation time separate from event time. In a prediction evaluation, a summary written after case closure may expose later outcomes even if it describes an earlier event. Provenance helps a reviewer see that route; it does not eliminate it.
Adding a summary does not establish authority to reuse the original record, disclose restricted narrative or train a model on it. Have the responsible owner review those questions separately under the applicable contracts and law. This article supplies a technical evidence method, not a conclusion about copyright, privacy or the rights attached to a particular archive.
When a source correction affects several annotations, locate the affected outputs through their references. Mark the earlier annotation as superseded and document the correction. Do not quietly rewrite the original operational record or imply that every recipient has adopted the revised interpretation.
Choose the smallest useful annotation project
Begin with the buyer’s actual evaluation question. If the task needs an action category, a full narrative rewrite may add unnecessary work and uncertainty. If it needs an outcome, agree on evidence requirements before asking a model to infer outcomes from every record. A small reviewed set can reveal that the source lacks the follow-up the desired labels require.
Proceed when added interpretations are inspectable, their uncertainties survive delivery, and the approved package preserves source relationships. Pause when summaries repeatedly invent outcomes or when useful interpretation depends on records outside the permitted scope. Use the due-diligence tool to record the missing evidence and the rights-review tool for separate disclosure questions. More annotation does not by itself establish a higher price or a ready buyer.