A new model release should not restart your AI roadmap. It should reopen only the ideas that were rejected for a constraint the release actually changed.
AI roadmaps are good at remembering winners.
The approved use cases get sponsors, pilots, budgets and status updates. The rejected ones usually get a lower score in a spreadsheet, a note saying "not now," or nothing at all.
That is a problem when the technology changes as quickly as the reasons for rejection.
On September 22, Anthropic released Claude Opus 5.5. The company says the model performs at the level of its higher-end Fable 5.1 on most work while costing 40% less to run than Opus 5 on typical workloads. Input and output token prices are 20% lower than Opus 5, cache reads are 60% lower, and output is more than 30% faster, according to Anthropic. The company also makes an unusually useful admission in the launch material: at this level of capability, small benchmark margins are becoming a less reliable guide to real-world differences.
The obvious response is to ask where the new model should be used.
I think there is a better portfolio question:
Which decisions that were correctly rejected six months ago are now wrong for a specific, identifiable reason?
Not every no deserves another meeting. But some do.
The way to tell them apart is to keep the reason you said no.
Most AI prioritization methods focus on the candidates still in play. Score value, feasibility, risk, effort, readiness or strategic fit; rank the opportunities; fund the top few.
That is useful for choosing what to do next.
It is less useful for remembering what changed.
Suppose five opportunities were rejected:
A document-review workflow was too expensive at the required volume.
A research workflow could not reliably handle the length and complexity of the source material.
A customer-service action could not meet the latency requirement.
A pricing decision depended on data nobody trusted.
A finance workflow had no agreed owner for the judgment the system would influence.
Six months later, a model arrives that is cheaper, faster and more capable on long tasks.
The first three decisions may deserve to be reopened.
The last two do not.
If all five sit in a backlog marked "low feasibility," that distinction has been lost.
The organization now has two bad options. Ignore the old list and miss opportunities that have become viable, or rescore everything whenever the frontier moves.
Both waste information the company already paid to learn.
I would keep a rejection ledger beside the active AI portfolio.
For every serious opportunity that does not proceed, record the main constraint that made the decision fail at that time.
The vocabulary does not need to be elaborate. It needs to distinguish reasons that move with the technology from reasons that do not.
A useful set might include:
There can be more than one constraint. But one should be named as the binding one: the condition that, if it changed, could plausibly change the decision.
That turns "not now" into a testable statement.
Rejected because acceptable completion cost exceeds our threshold at this volume.
is very different from:
Rejected because the workflow depends on three incompatible definitions of customer status.
Both may receive the same score in a prioritization matrix. Only one is likely to move because a model got cheaper.
This is where the current pace of model releases becomes manageable.
A launch does not need to become a strategy event.
Translate the release into the constraints it may have changed.
Anthropic's Opus 5.5 announcement, for example, contains claims about capability, task efficiency, token cost, cache-read cost, speed, long-running work and safety behavior. Those claims still need to be tested on the work an organization actually cares about; they are vendor evidence, not enterprise proof.
But they are enough to identify which drawers to open.
If an opportunity was rejected on economics, test the new cost per acceptable completed task.
If it failed on latency, rerun the timing requirement.
If long-horizon execution was the blocker, test the exact workflow that previously broke.
If the problem was data ownership, process ambiguity or a missing decision owner, leave it closed.
This is a much smaller piece of work than "review our AI strategy in light of the new model."
It is also harder for novelty to hijack.
A new model is allowed to change the decisions it has earned the right to change.
A rejection ledger needs one other field: the evidence date.
"Model cannot do this reliably" is not a durable organizational truth. It is an observation about a particular system, evaluation and moment.
The same is true of cost and latency.
This is why the ledger should preserve enough context to reconstruct the old decision: what was tested, against which threshold, with which configuration, and when.
The principle is similar to the one I argued in The benchmark needs a runtime address, but the portfolio consequence is different. Evaluation evidence expires when the system materially changes. A rejected opportunity can expire for the same reason.
The reverse matters too.
Some rejection reasons should age slowly.
A workflow rejected because nobody owns the outcome should remain rejected until ownership changes. A use case built around a poorly framed problem should not come back because a model gained ten benchmark points. A consequential decision judged inappropriate for delegation needs a governance change, not a capability announcement.
The ledger tells you what kind of change would be relevant.
This also fixes a weakness in scoring models.
Scores compress reasoning.
A use case that received 2.8 out of 5 six months ago does not tell you what would have to become true for it to reach 3.8. Re-running the rubric can produce a new number, but it may not tell you whether the underlying decision changed or merely the enthusiasm around it did.
The rejection reason is more useful because it preserves causality.
It says: we would have done this, except for X.
Then X can be watched.
This is especially valuable for opportunities rejected after a real pilot. A good pilot should reduce uncertainty around a decision, not simply demonstrate that something works. I have argued that in A pilot is a decision instrument. When the answer is no, the organization should keep the evidence that made no the right answer.
Otherwise the next model launch erases the learning and the same idea returns wearing a new product name.
There is a tendency to treat rejected ideas as waste: proposals that did not survive prioritization.
In a fast-moving technical environment, a well-reasoned rejection is an option.
The organization has already investigated the problem, exposed a constraint and decided not to spend further. If that constraint later moves, the opportunity can be reconsidered with much less discovery than a completely new idea.
But the option has value only if the reason for rejection survived.
That creates a useful discipline for an AI portfolio. Do not keep an infinite graveyard of every suggestion anyone has made. Keep the opportunities that were serious enough to evaluate, and attach the condition that prevented them from proceeding.
Then watch the conditions, not the hype cycle.
Claude Opus 5.5 will not be the last release to move the price-performance boundary. Anthropic says Sonnet 5.5 and Haiku 5.5 will follow in the coming weeks. Other providers will move different boundaries. Some previously uneconomic work will become cheap. Some unreliable work will cross an acceptable threshold. Some constraints will not move at all.
The strategic advantage is not predicting every model improvement.
It is knowing which of your old decisions each improvement is actually capable of changing.
A backlog tells you what you might do.
A rejection ledger tells you what would have to become true.
Berk Bayri
Creative Technology & Innovation Leader
Designing and building for digital environments since 1998, across strategy, product, design, technology and organizational innovation.
About Berk →