Knowledge · Business Operations

    Author, Timestamp, Source and Record Attribution

    A note without an author is a rumour. What attribution a field note needs, why capture time and event time differ, and how edits should be handled.

    What information should a note record besides the text?

    Four things: who wrote it, when it was captured, how it arrived — typed, dictated, imported or generated — and which record it belongs to. Without those, a note is an unsourced claim, and nobody reading it later can judge how much weight it deserves.

    Key takeaways

    • Author, time, source and parent record are part of the note, not metadata trivia.
    • Capture time and the time of the observed event are different facts.
    • Source matters: a dictated note and a generated summary carry different weight.
    • Corrections belong in a new note, not a silent rewrite.
    • Do not claim immutable history unless the system actually enforces it.

    The four attributes every note needs

    • Author: the signed-in person accountable for the content.
    • Timestamp: when the note was captured, in a timezone the reader can interpret.
    • Source: typed, dictated, imported, or produced by a summarisation step.
    • Parent record: the lead, customer, appointment, deal, job or task it describes.

    Capture time is not event time

    A note saved at 7:40pm about a visit at 10am is a note about the morning, written in the evening. The system knows the first time; only the writer can supply the second. When the gap matters — damage discovered, a verbal approval, an incident — say the time inside the note text.

    This is also the honest way to read old notes. A detailed note captured on site and a summary written at the end of the week are different kinds of evidence even when their text looks similar.

    Why source is worth storing

    A note typed by an estimator, a note dictated in the wind, a note imported from an old system, and a paragraph produced by a summarisation step are four different reliability profiles. Collapsing them into one anonymous stream means the reader has no way to calibrate.

    Generated text especially should never be laundered into looking like a human observation. If a model wrote it, the record should say so.

    Corrections, edits and history

    • Correct with a new note that references the mistake, so the sequence stays readable.
    • Reserve edits for typos and formatting, not for changing what was claimed.
    • Never assume a note is tamper-proof unless your system genuinely enforces that.
    • System-level changes belong in the audit trail; notes are observation, not audit.

    Where URBLD fits

    URBLD saves each note with its type, body, author, capture timestamp, source and the record it belongs to. Notes are observation records; system-level and destructive changes are separately recorded in the audit trail, so 'what someone saw' and 'what the system did' stay legible as different histories.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Business Operations

    The daily mechanics: workflows, checklists, scheduling and handoffs.

    Browse Business Operations
    Share this page