Information Expires: Give Messages in Interactive Stories an Expiry Time
Even a reliable observation station’s forecast may have expired by the time it arrives. A three-column ledger—when the message applies, how to check it, and what to do after it expires—shows players what old information still supports and what they can do next.
Separate Two Questions First: Who Said It, and Does It Still Apply?
When a night-shift observer receives an old tide forecast, they need to assess its source’s credibility separately from whether its content applies to the present time. Writers should make both judgments visible in the text, then give the message a three-column ledger: when it applies, how to check it, and what to do after it expires. A reliable source does not make a forecast valid forever; an expired message does not mean its issuer lied.
The following example, North Dike Night Bulletin, is a fictional teaching scenario. Its characters, times, forecasts, and branching rules were invented to illustrate writing techniques. It is not a real user case, a measured result, or a product feature, and is not intended for assessing real tides.
Observer Lin Cheng starts a shift at 23:10 and receives a paper bulletin issued by North Dike Observation Station at 20:00: “From 22:00 to 23:00, the outer bay is in a low-tide window.” The story has already established through the handover log that the bulletin came from that station. Lin must decide whether to enter “low tide forecast” or “current tide conditions pending verification” in tonight’s observation record.
The source question has an answer, but the timing question remains unresolved: the station did issue the bulletin, yet its coverage period has ended. Writing “the reliable forecast proves it is still low tide” substitutes source credibility for current applicability. The appropriate wording is: “The period covered by the bulletin has ended. Current tide conditions are pending verification.” The old bulletin can still explain why the previous shift scheduled an observation; it cannot, on its own, answer what is happening now.
A Three-Column Ledger: Leave a Next Step for Every Message
Above the ledger, write the original message, its source, and its issue time. Keep the ledger itself to three columns. The issue time tells us when the message was produced; its period of applicability tells us which time span it can support judgments about. Neither can replace the other. The deadlines in this table are narrative rules established in advance for this story.
| When the message applies | How to check it | What to do after it expires |
|---|---|---|
| A: The old paper bulletin applies from 22:00 to 23:00; at 23:00, it stops supporting judgments about current tide conditions | Check the duty desk’s incoming-bulletin register for a follow-up covering the period after 23:00 | Retain it as the basis for the previous shift’s record; mark this shift’s tide conditions as pending verification and request a supplementary bulletin |
| B: If a follow-up covers 23:00 to 00:00, it can be cited as a forecast during that period; any original judgment affected by a correction ceases to apply before its scheduled expiry | Check the incoming-bulletin register and the corrections section under the same reference number; verify the location, coverage period, and correction details | On normal expiry: retain it as a historical forecast and find a follow-up for the next period; if invalidated by a correction: retain the original, record its relationship to the correction, and check the correction before citing the corrected information |
| C: The waterline Lin records at the east-side window at 23:15 describes only that time and place | Return to the same observation point, observe the waterline again, and record the new observation’s location and time | Retain the original as a historical observation; make a separate record for the new observation, without changing the old timestamp or directly extrapolating to the outer bay or a later time |
When reusing this structure, put “what it applies to, start and end points, and conditions that would invalidate it early” in the first column; “what can be found and which fields to check” in the second; and “what it still supports and what to do next” in the third. Normal expiry does not imply a correction exists; record the relationship only when there is a correction. If the third column says only “cannot be used,” the story has taken away a choice without providing an action.
Do not give everything a blanket rule of “valid for one hour after receipt.” A late-arriving paper bulletin does not gain a longer coverage period, and a fresh on-site observation does not automatically apply elsewhere. The deadline should follow the question the message is meant to answer, not the time the player opens it.
Turn the Ledger into a Handover with Choices
Show the coverage period on the bulletin first, then the wall clock reading 23:10, and finally the choices. This lets players discover the deadline before acting and gives the consequences a traceable basis.
The scene could read: “The signature matches the handover log. You set the bulletin beside your record book and notice that the forecast’s coverage ended ten minutes before the time on the wall clock. The tide-conditions field for your shift is still blank.” Then offer three actions: “Look for a follow-up in the incoming-bulletin register,” “Mark it pending verification and fill in the other handover items,” and “Use the old bulletin to enter low tide.”
In this illustrative walkthrough, Lin chooses to look for a follow-up. The register shows an entry at 23:05, but the bulletin’s text has not yet been copied in. All Lin knows now is that there may be a new message. The registration time cannot stand in for the message’s content, much less establish that the current forecast has been updated.
The next step could read: “Request that the missing text be copied in, using the registration number,” or “Record that the follow-up is awaiting retrieval, then finish handing over the instrument identification numbers.” If the player requests the missing text, the writer then supplies a follow-up covering the current period and matching the location. Only after Lin checks the corrections section may the record say, “According to the follow-up bulletin, the forecast is…” This is still a forecast; narration should not turn it into a present observation.
The other two initial choices also need clear outcomes. Marking the field pending verification leaves an unresolved item that can be revisited while the rest of the handover proceeds. Reusing the old bulletin prompts the next person on duty to point out the mismatched period and request an added note explaining the basis for the entry. The consequences here concern record quality; there is no need to invent a disaster to punish the player. The old message affects the choice because the range of conclusions it supports has narrowed.
You Do Not Always Need a Countdown, and Checking Need Not Always Succeed
If the story has no precise clocks, events can serve as deadlines: “Recheck after the shift-change bell,” or “Suspend the old judgment when the gate’s status changes.” Players must be able to see or learn that the event has occurred. If the writer changes conditions behind the scenes and announces only afterward that the message has expired, players cannot judge from the information available to them.
Two messages can also remain in use at once: the old bulletin explains earlier arrangements, while the follow-up informs the current record. This suits stories that require tracing how decisions were made. If the plot concerns only the immediate choice, emphasize the follow-up in the character’s summary and return the old bulletin to the archive. Every exchange of dialogue need not repeat the message’s entire history.
Failed attempts to check information are worth writing, too. If pages are missing from the follow-up or no one answers communications, the ledger’s third column should allow actions such as “Mark as pending verification for now,” “Move on to handover items that do not depend on tide conditions,” and “Leave a numbered request for further checking.” Each has a narrative cost: finishing the record later, temporarily missing a conversation, or carrying the issue into the next scene. Explain those costs beforehand; “pending verification” must not secretly mean “wrong choice.”
If the task demands an immediate choice, make the lack of evidence explicit and have the character state the assumption they are using. When the truth is revealed later, distinguish “there was not enough information at the time” from “the player overlooked information already available.” These call for different feedback.
Check Whether the Deadline Actually Changes the Writing
After drafting, follow one message through its lifetime: which statement does it support before expiry, what does the player see when it expires, and which action remains available afterward? If the narration and choices are identical at all three points, the ledger is probably decorative.
Then check three easily confused situations. If no period of applicability is given, label it “applicable period unknown”; do not arbitrarily declare it still valid or expired. If a conflicting observation appears, specify where and when it was actually made, rather than declaring the entire source untrustworthy. If a newly relayed message arrives with identical wording, investigate whether it was copied from the old bulletin; the time it was relayed does not refresh the original message. A fresh observation also requires a new record, not an altered timestamp on the old one.
Finally, replace “The station has always been accurate, so follow it” with two sentences: “The source has been checked. The coverage period has ended; I’ll look for a follow-up first.” This preserves the character’s trust in the source while making the current decision subject to time constraints. The standard for a finished three-column ledger is not that every message has an answer, but that every question that cannot yet be answered leaves a next action the reader can understand and the character can perform.
