Priya ran the small machine-learning platform team at a mid-sized retailer, and she remembered the Tuesday her recommendation service went quiet. Nothing had been deployed. No one had touched the code. A hosted model version her team relied on had reached the end of its published availability, the vendor had said so months earlier, and the notice had landed in an inbox that nobody read after a reorganisation. The surprise was real, but the date had never been secret. It had simply never been on a calendar.

That week she began comparing ways to keep an AI key-dates calendar, and what follows is the story of what her team tried, how the options differed, and what finally stuck. If you work with models, pipelines or managed AI services, the comparison may save you a Tuesday of your own.

What belongs in an AI key-dates calendar

Priya’s first lesson was that the list is longer than anyone expects. Teams usually think of certificates and forget everything else. Her inventory ended up covering several families of fixed dates:

• Model and API retirements: published sunset dates for hosted model versions and older API interfaces.
• Runtime and library end-of-support: the dates when the language versions, frameworks and drivers under your training and serving code stop receiving fixes.
• Licences and commitments: software licences, reserved capacity agreements and committed-spend renewals, each with its own anniversary.
• Data agreements: licence terms on datasets, and the renewal or expiry of data-sharing arrangements with partners.
• Compliance windows: internal and external review periods when documentation, impact assessments or audit evidence must be ready.
• Credentials: certificates, API keys with fixed lifetimes and service-account rotations.

None of these were unpredictable. Each had a date printed somewhere, and her team’s job was to bring those dates to one place with enough lead time to act.

Option one: the shared spreadsheet

The team’s first attempt was a spreadsheet with columns for the date, the item, the owner and the source. It was cheap, flexible and understood by everyone on day one. For a few weeks it felt like a triumph. People added rows with enthusiasm, and Priya could sort by date and see the next quarter at a glance.

The weakness appeared slowly. A spreadsheet does not tap anyone on the shoulder. It only helps when somebody opens it, and the people most likely to forget are exactly those too busy to open a spreadsheet. By the second month, a handful of rows were stale and nobody was sure which. The spreadsheet remained an excellent record and a poor reminder, which matters because the whole point of the calendar is the early nudge.

Option two: the calendar with invitations

The second approach put each date into a shared team calendar, with invitations sent to the owner and a backup. Reminders arrived by themselves: a month ahead for licence renewals, a week ahead for certificate expiries, and several staggered alerts for the big retirements. This solved the nudge problem immediately. People saw the entries alongside their ordinary meetings and could not easily ignore them.

Its weakness was context. An invitation titled “model retirement” says little about what to do, what depends on the model or where the vendor notice lives. Over time the descriptions grew uneven. Some entries had links to the source and a migration plan; others had two words. The calendar was an excellent reminder and a mediocre record, almost the mirror image of the spreadsheet.

Option three: dates inside the repository

The third approach was the one engineers were most drawn to: keep the dates in a structured file in the same repository as the services, reviewed through the ordinary change process, and let a scheduled job read it and send reminders. Each entry carried the date, the source link, the owner, the services affected and the lead times. A pull request was the way to add or change a date, so there was a history of who changed what and why.

This option combined the record of the spreadsheet with the nudge of the calendar, and it placed the dates beside the code they affected. It also had the highest set-up cost. Someone had to write and maintain the reminder job, and non-engineers on the wider team, such as the person who handled licence purchasing, found it awkward to contribute. The approach worked wonderfully for technical dates and poorly for commercial ones.

How the three compared

Priya laid them side by side against the things she cared about. The spreadsheet scored well on openness and poorly on nudging. The shared calendar scored well on nudging and poorly on depth. The repository file scored well on both record and reminders for engineers and poorly on accessibility for everyone else. Nobody won outright, and she noticed that trying to pick a champion was itself a distraction from the real work, which was getting the dates collected at all.

What she saw clearly was that each approach failed in a predictable place, so a combination could cover the gaps. The record of truth would live in one structured list, and the reminders would go out as calendar invitations that linked back to that list. Technical dates would be added through the repository; commercial dates would be entered by their owners into a simple form that wrote to the same list.

The lead-time rules the team adopted

Whichever vehicle you choose, the reminder schedule matters more than the tool. Priya’s team settled on a few rules of thumb. For anything with a migration involved, such as a model or runtime retirement, the first reminder fired about a quarter ahead, because migrating, testing and rolling out safely takes weeks. For renewals involving purchasing, the first reminder came two months ahead, so procurement had breathing room. For credentials and certificates, a month and then a week sufficed. Every reminder named an owner and linked to the source.

She also added a rule that mattered more than expected: each vendor notice must be turned into a calendar entry within a few working days of arriving. Notices sitting unprocessed in a shared mailbox had caused the original problem, so the intake step became a standing item in the team’s weekly sync.

A glance over the fence

It helps to see how other fields handle the same discipline. Finance education is full of fixed dates, and a site like Stocks Mantra, which publishes finance education for investors, includes an important-dates section among its resources. The idea translates neatly to an AI team: gather the predictable dates in one place and refer to them regularly, so no one is startled by something that was always scheduled. This is a point about method, not a comment on any market.

Why dates are an AI problem, not just an IT problem

AI work leans on a moving stack. Models, libraries and managed services change faster than the infrastructure around ordinary applications, and the notices that come with those changes tend to be short and easy to skim. The decision-making that sits on top of those systems is also time-sensitive, as this site’s explainer on how AI feeds everyday business decisions suggests: when a model underneath a decision process disappears or changes behaviour, the decisions change with it. A calendar does not prevent change, but it ensures you meet change on your own schedule rather than the vendor’s.

If you are still deciding what to put under a given service, a reasonable companion read is the site’s guide to weighing up AI products for a team; the calendar simply keeps the commitments you make afterwards visible.

What changed for Priya’s team

Six months after the quiet Tuesday, the platform team had a combined list of dates, a reminder schedule with owners, and a weekly five-minute review. The next vendor retirement notice arrived in the usual terse email. This time it became a calendar entry the same week, a migration ticket appeared a quarter ahead of the date, and the cut-over happened on a calm afternoon with nobody paged. The recommendation service never went quiet again.

Looking back, Priya described the change this way. The retirement had always been scheduled. What the team gained was not foresight but a place where scheduled things were written down and a habit of looking at them early. If you take one thing from the comparison, let it be that the best calendar is the one that your busiest teammate will actually see, with the date, the source and a nudge that arrives while there is still time to act.