I find myself haunted by this notification.

In October 2025, Sky News published a political comment piece. Same news, different day. This one went viral. Why? Because of how modern devices notified readers of the headline.

No human wrote the headline in this way. It stems from the text being truncated automatically by the device notification system. This is called “truncation”.

What is truncation? It is a method for automatically cutting off content when doesn’t fit into a layout container. Say you have a button element that can fit 18 characters. If the button content is 25 characters, truncation cuts off the content at 17 characters, and then insets an ellipsis to show what has happened.

We need automated content methods like this because there is an almost invite variation in the layout constraint variances across devices, user device preferences and content sources. There’s no way anyone can manually rewrite content to fit every context.

It’s automated layout behaviour, so I figured there has to be an automated way to prevent it.

Safe truncation information

I started out assuming this would require something like a banned words list, but I quickly discovered the problem is slightly different to that.

For example, the word “polemic” can be truncated to “pole”. Both of these are innocuous words but the wrong truncation could still cause embarrassment. At the risk of over-explaining, say for example that the sentence:

“Tristan loved nothing more than his professor’s long polemics against the dangers of artificial intelligence.”

Is truncated into:

“Tristan loved nothing more than his professor’s long pole…”

What you end up with is embarrassing screenshot bait.

As you can see, safe truncation isn’t about banned words, its about unintended shifts in meaning and context.

Token efficiency

It’s 2026, isn’t the obvious approach here to abandon truncation and simply rewrite every headline with an LLM to fit the particular layout context at the users runtime?

And you could totally do it that way. But scaled across millions (billions?) of devices that’s a lot of token consumption without any obvious revenue benefit. It doesn’t feel like a sustainable approach.

A more efficient method would be to scan every content string with a simple word filter before truncation, and only rewrite content that contains a word considered to be a truncation risk.

Based on sampling a few news websites and my email inbox, Claude Code estimates you would only need to rewrite between 1-5% content strings, causing a 95-99% reduction in AI usage for the same quality outcome.

Designing for LLMs

Considering that LLMs are the primary users for this tool, I made it API first.

The content comes from a simple json file that lists out the truncation risk word, its corresponding bad word, and definition for both (to aid LLMs identify unintended context shifts).

The content is available as a full JSON-LD in the head, and as a llms.txt.

It’s all static content, so I’ve put it on Github Pages for stability and ease of deployment.

Check out the site here

Languages other than English

I don’t understand enough about sentence construction in languages other than English to know how widespread an issue truncation might be. I assume it isn’t much of an issue with logographic languages like Chinese, but probably impacts compound-heavy languages such as German and Dutch.

The API oriented design makes adding additional languages simple. If you want to contribute (or if I’ve missed any English words) please do get involved on Github.

You can pretend it's 2005 and subscribe to my RSS feed