A Timeline Entry is one immutable entry in an append-only Timeline. It records a Blue message, the timeline it belongs to, the previous entry reference, the provider-assigned or provider-recorded timestamp, and attribution fields such as actor and source. Its BlueId is a content address over this data. If entries use `prevEntry`, each entry commits to the BlueId of its predecessor, creating a tamper-evident chain: changing an old entry changes its BlueId and breaks every later `prevEntry` link. A Timeline Entry is not automatically a document operation. It is a stored statement or action on a timeline. A Blue document may consume it through a Timeline Channel, but other applications may use the same timeline for audit, messaging, public announcements, personal storage, signed receipts, or other purposes. The provider does not need to know why the message was written. The provider's claims are about append authorization, identity/source attribution, timestamp/order, storage, and completeness. `timestamp` is used for deterministic ordering. For managed providers it is typically microseconds since Unix epoch and must respect all outstanding completeness guarantees. For blockchain-backed timelines it may be derived from finalized block timestamps and may have lower precision. When multiple entries have the same timestamp, processing environments must use deterministic tie-breakers such as channel key and provider-specific finalized order. `message` is the Blue payload. It may be an Operation Request, Chat Message, Status Change, customer response, domain-specific event, or any other Blue node. `actor` says who or what the provider attributes the entry to. `source` says how the message reached the provider. Blue documents should evaluate actor/source policy from these fields rather than guessing from the message body.