Recording past events

A thread’s Transaction History normally records what DICE itself observed. Recording lets you add what happened outside DICE: a repair at a vendor last March, a sale before the item was ever tagged, or a painting created in 1835. Each recorded entry becomes a permanent part of the Transaction History, interleaved at the time you claim it happened.

Recorded entries are always marked Declared in the feed. They are your attributed statement — DICE never verifies them, and never presents them as facts it observed.

Recording something that happened

1. Open the thread and select Record at the top of the Transaction History.

2. Give the entry a short title — for example, Repackaged for shipment. That’s enough: press Add to record, and the entry lands in the history as of now.

3. Optionally add details, the kind of event (inspection, sale, repair, …), and where it happened, under More options.

Caution

A recorded entry is part of the permanent record: it is shared with future owners along with the rest of the thread’s history, and it cannot be deleted — only retracted.

Recording the past

The When control accepts more than “now”:

• A date — as precise as you actually know: a year (1835), a month (1835-06), an exact day (1835-06-15), a range (1968 to 1970), or an open bound (before/after a date). Check Approximate when the date is a “circa”.
• Relative to an entry — place the record just before or just after an existing entry in the history, when you know the order of events better than their dates.

The entry sorts into the timeline at the claimed time — a creation date of 1835 appears before the thread’s own creation — and the feed always displays the claim at the precision you stated (“Circa 1835”, “Before March 1970”), never a fabricated exact timestamp.

Recording many entries at once

When you have a whole history to add rather than one entry, upload it as a CSV. The file describes events only — it never names which records receive them. That comes from where you start the import:

• One record, many entries — open Record on the thread and switch to Import CSV. Every row lands on that thread.
• Many records, the same history — select the records, then choose Import past events (CSV) from the batch actions. Every row lands on every selected record, so 3 rows across 40 records is 120 entries. The review step states that number before you commit.

The columns match the single-entry form: Title, Details, Kind, When, Location, Latitude, Longitude. Nothing is required as long as each row carries a title, details, or a kind. When takes the same date claims as the form, written as EDTF — 1968, 1968-03, 1968-03-21, 1968/1970, 1835~, ../1970, 2019/.. — and a row with no date is recorded as of now. Location publishes exactly as written and is never looked up on a map. Download the example CSV from the upload step to start from a working file.

Caution

An import is all-or-nothing: if any row has a problem, the review step names it and nothing is imported. Because entries are permanent, this is deliberate — fix the file and upload it again rather than cleaning up a half-applied import. Once an import succeeds, Undo on the confirmation retracts the whole thing in one step.

A CSV can carry up to 100 rows, and one import can write up to 2,000 entries. For a continuous feed from an ERP, WMS, or MES — or for many records each with a different history — post entries through the API instead; see Provenance from an ERP.

Correcting a mistake

Recorded entries can’t be edited or deleted — like everything in the Transaction History, they are immutable. Instead, retract the entry from its expanded view, and record a corrected entry in its place.

A retraction is visible from both sides of the history:

• The retracted entry stays where it was, struck through, greyed, and marked Retracted. Expanding it shows who retracted it, when, and the reason given.
• The retraction itself appears as its own entry at the moment you retracted, titled with the entry it retracts (Retracted: Repackaged for shipment) and linking back to it.

Recording and retracting require edit access to the thread. Viewers see recorded entries like any other history.