Four time values can describe one launch

Launch Library 2 exposes a no-earlier-than time, window start, window end and a precision object when the source material supports them. Those values can be equal, but they are not interchangeable. An instantaneous opportunity may have identical bounds; a broad window may place NET somewhere inside it.

Precision is not cosmetic metadata. ‘Second’, ‘minute’, ‘hour’, ‘day’ and wider planning estimates tell the interface how much certainty it is allowed to display. Adding a live seconds countdown to a day-level estimate makes the product look active by inventing accuracy.

Status is another independent claim. A mission can remain scheduled while its time moves, enter a hold while the current opportunity remains open, be scrubbed for the day or be confirmed successful after flight. The timestamp alone cannot express those states.

An update is not an explanation

Upstream records often change before an operator publishes a detailed reason. Orbital can say that the target moved from one time to another and identify when its source record was checked. It cannot safely conclude that weather, range traffic or a technical problem caused the move unless a responsible source says so.

This is an important editorial boundary. Schedule aggregators are excellent at consolidating changing times; they are not automatically primary evidence for the operational decision behind every change. A cause should link to an operator, range, agency or mission statement.

Silence is sometimes the honest result. ‘Reason not published’ is more useful than a confident-looking guess because it tells the reader what to watch for next.

Changed at 14:20 is evidence. Changed because of weather requires a source.

Keep the flight; revise the schedule

A launch should retain one permanent identity through slips, vehicle swaps, mission-name refinements and pad changes. The current schedule belongs to that record; it should not define the record. Otherwise every update fractures links, alerts and discussion across multiple pages.

Stable identity also makes change history possible. A reader can see the current truth while Orbital preserves the fact that the public plan used to be different. That history is useful for accountability and for understanding why an old screenshot or calendar entry no longer matches.

The same principle extends outward. Vehicle, operator and place connections survive the schedule update. A story written before a slip remains attached to the correct mission instead of becoming an orphaned page about a vanished timestamp.

Notify the decision, not every database twitch

Future Orbital alerts should distinguish material changes from routine source maintenance. A moved day, narrowed window, hold, scrub, pad change or confirmed result can alter someone’s plan. A spelling correction or refreshed source timestamp usually should not wake them.

That requires comparing meaning, not merely rows. The alert system needs thresholds, deduplication and a record of what each follower has already been told. When several fields move together, one coherent briefing is better than a burst of machine-generated notifications.

The editorial test is simple: after reading the alert, does a person know what changed, what remains uncertain and whether they need to act? If not, the system has transmitted activity rather than information.