Put events in order before asking AI to summarize them

A customer says a delivery was late. The first note says the carrier arrived at 2:15. A later message says the customer changed the delivery window that morning. Another note, entered the next day, says the carrier was turned away because the site was closed.

Ask AI to summarize those notes as they appear, and you might get a tidy story that puts the delivery change after the attempted arrival. The dates in the notes may be scattered. The order the notes were written may not match the order the events happened.

Try one concept: ask AI to build a dated event list before asking for the summary. The list is a visible intermediate step. You can check its sequence and uncertainty against the original records, then decide whether a summary is safe to use.

Why the order deserves its own check

A summary compresses. That’s useful when several records describe one piece of work, but compression can hide sequence. If a request changed before a task began, that means something different from a change made after the task was completed. If a customer was contacted after a refund was issued, that’s different from a call that led to the refund.

Dates can be messy even when everyone is acting carefully. A note might be entered after a meeting, describe an event from the previous day, and mention a deadline in another time zone. A message can refer to “yesterday,” “next Tuesday,” or “after approval” without saying which date or time zone the writer meant. Two records may describe the same event from different perspectives. And a record’s timestamp may tell you when someone wrote it, not when the event occurred.

That makes event order a useful thing to ask for separately. OpenAI’s current prompting guidance recommends being clear and specific about the context and task. Asking for a dated event list is a specific output you can inspect; it doesn’t guarantee that the dates or order are right.

There’s a reason to keep that limit in view. A 2025 paper in the Association for Computational Linguistics’ Findings evaluated event and time reasoning across several categories. Its authors report weaker performance on some tasks involving time spans, compound questions, and fine-grained timing. A separate ICLR 2025 study treats temporal meaning and time arithmetic as distinct skills and shows why the order and structure of the facts can affect the task. These studies don’t measure every current model or workplace situation. They do give us a practical reason to review a generated sequence instead of assuming a smooth narrative proves the order is sound.

The event list doesn’t establish what happened. It makes the model’s proposed sequence easier to compare with the records you already have.

Try it on a small set of notes

Choose a low-stakes example with a handful of records you are allowed to share with the AI service. A routine internal handoff or a fictional case you make up is a good place to start. Don’t begin with a dispute, employee investigation, medical issue, legal deadline, or any case where an incorrect sequence could harm someone. Use your organization’s approved tool and data rules.

Here is a fictional example:

• Monday, 10:00 a.m. — calendar invite sent: The customer is offered a Wednesday delivery window.
• Tuesday, 3:20 p.m. — customer email received: “Could we move this to Thursday? The loading bay will be closed Wednesday.”
• Tuesday, 4:05 p.m. — dispatcher reply sent: “Thursday is available. I’ve asked the carrier to confirm.”
• Wednesday, 11:40 a.m. — carrier portal entry: The carrier still lists Wednesday’s window.
• Thursday, 8:15 a.m. — service note entered: “Customer called. Driver arrived at 8:00; bay was locked.”

The notes are already in chronological order here, but the key detail is not. The service note was entered Thursday and describes an event at 8:00. The carrier portal still had a Wednesday window. The customer’s Tuesday request and the dispatcher’s reply may be related to that mismatch, but the notes alone don’t show whether the carrier received the change.

Now imagine the same five records copied from different systems in this order: the service note, the Monday invite, the portal entry, the dispatcher reply, the customer email. That can happen when someone gathers information for a handoff. A summary made directly from the pasted order may echo the source order. The model might also sort it incorrectly, or miss that the record date and event date differ.

The next step is not “write a better summary.” Ask for the intermediate event list and require the model to mark unknowns rather than fill them in. For example:

Build a chronological event list from the notes below. For each item, include the event date and time if the note gives one, the date the note was entered if available, the source, and the exact detail supporting the event. Keep event time separate from note-entry time. If the order is uncertain, say why and mark the item “order unclear.” Do not infer that a message reached the carrier unless the notes say it did. After the list, identify which sequence questions the records do not settle. Do not write a narrative summary yet. Notes: [paste approved notes]

That request keeps the output to one task: a list of events in time order, with evidence attached and gaps visible. It does not ask AI to decide who was responsible or to write a polished explanation.

Read the list against its sources

Review the entries one by one. Don’t grade the answer by whether it “looks chronological.” Confirm what each date refers to and whether the record actually supports the event described.

For the fictional case, a review could look like this:

| Event-list entry | What to check | What the notes establish | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | | Customer requested Thursday instead of Wednesday on Tuesday at 3:20 p.m. | Open the original customer email. | The customer asked to move the delivery and said the loading bay would be closed Wednesday. | | Dispatcher replied at 4:05 p.m. that Thursday was available and asked the carrier to confirm. | Open the reply and check whether it names a confirmed booking or only a request. | The dispatcher asked for confirmation; the wording doesn’t establish that the carrier received it. | | Carrier portal showed Wednesday on Wednesday at 11:40 a.m. | Confirm the entry’s timestamp and whether it reports the current booking or an earlier snapshot. | The listed window was Wednesday when the portal entry was recorded. The note doesn’t reveal when the carrier last updated it. | | Driver arrived Thursday at 8:00 a.m., according to a note entered at 8:15 a.m. | Check whether the note identifies who observed the arrival and the time zone. | The note reports an 8:00 arrival and a locked bay. Whether that time came from a direct observation or another source may need confirmation. |

The table separates what the notes say from what they don’t settle. That last column is your job. If the portal entry’s timestamp is not clearly a snapshot time, ask the person who owns the portal or check its history. If the service note is secondhand, identify that before treating the time as confirmed. If the time zone is missing and matters to the sequence, establish it from the system or record owner.

Pay attention to the words AI uses to connect events. “Then,” “because,” “after the change,” and “the carrier failed to update” all imply relationships beyond a list of timestamps. A sequence can be right while the explanation is still unsupported. If the evidence says the dispatcher asked the carrier to confirm, it doesn’t prove the carrier received the message. If the vehicle arrived Thursday, it doesn’t establish why the bay was locked. Keep those conclusions out unless a source supports them.

If the model leaves a gap visible, keep it visible. You can add a row that says “carrier confirmation: not in these notes” or list “whether the carrier received the change” as an open question. Don’t instruct the model to choose the most likely answer just to make the story read cleanly.

Once the sequence is checked, ask for the summary

When the list is accurate enough for your purpose, ask for a short handoff summary based only on its checked entries. Tell the model who will read the handoff and what they need to do. For example:

Using only the checked event list, write a three-sentence handoff for the operations lead. Separate confirmed facts from open questions. Do not assign fault. Include the unresolved question about carrier confirmation and name the record or person that could settle it. Do not add a next step that the notes do not support.

Then compare the summary with the checked list. Did “asked to confirm” turn into “confirmed”? Did an event date get replaced with a note-entry date? Did the AI invent a cause or omit a gap because it made the prose less neat? Check any time, name, promise, and implied responsibility against the original record before the handoff leaves your team.

You can do the exercise manually in a few minutes: copy a small group of notes, ask for a chronological list with sources and unknowns, and verify each row. If the list is wrong, fix the row yourself or supply the missing detail from an authorized source. Then ask for the summary. If the records don’t support a reliable order, don’t send a confident timeline. Ask the person who owns the event or system to resolve it.

Where this stops helping

This method is most useful when order changes the meaning of the work: a set of customer updates, a project handoff, an equipment service log, or a sequence of approvals. It’s less useful when notes all describe one simple event, the timestamps are already authoritative, or nobody needs to understand the order. Setting up an event list costs time. Don’t turn every short AI task into a two-stage process.

It also has limits when sources disagree, dates are missing, or events overlap. A list can make those problems easier to spot, but it can’t decide which account is correct. If the records use different time zones or timestamps from different systems, normalize those details only after you know what each clock represents. For consequential decisions, use the formal review process and the system of record. A generated timeline is not an audit log, proof of notice, or determination of fault.

This is one of those cases where a polished paragraph can be less useful than a slightly awkward table. The table gives a reader room to notice that “the note was entered Thursday” and “the event happened Thursday” are separate claims, and that “we asked for confirmation” and “confirmation was received” are separate events. The wording may take longer to read, but it protects the distinction that a handoff needs.

Try the dated event list the next time scattered notes need to become a sequence. Check the event times and note times separately, keep unknowns visible, and only ask for a narrative after the order is supported. If you can’t verify the list, treat the sequence as unresolved and route that question to the person or record that can settle it.

Sources: OpenAI’s prompting guidance, the ACL Findings paper on event temporal reasoning, and the ICLR paper on temporal reasoning.