But the “Hallucination Stations” paper (Sikka & Sikka 2025) suggests a hard theoretical limit to this approach.

The paper demonstrates that an LLM cannot strictly solve or verify problems that exceed its internal computational complexity (roughly O(n²)). If asked to solve a more complex problem, it is mathematically forced to hallucinate a statistically probable answer.

The problem for us in AI Safety: Verifying safety is often strictly harder than generating text.

A robust safety check isn't just a keyword scan. It requires verifying the logical consistency of a response against complex, interacting policies (bias, privacy, jailbreaks, illegal content, hate speech, dangerous weaponry, etc.) across a full conversation history. This creates a combinatorial state explosion, probably pushing the verification task into exponential complexity, or certainly far beyond the O(n²) limit of the critic itself.

The Result: The critic may confidently label a response as “safe” simply because it’s statistically safe, even when it fails a complex logical constraint.

The Way Forward: Rather than rely on “LLMs all the way down.”, the critic can be part of a hybrid system—capable of generating code or calling deterministic tools to offload the high-complexity verification tasks that the LLM theoretically cannot handle.

https://eobrain.github.io/

Putting together only the ones that currently work, I was able to list eighteen, but I may be able to add some more if I can manage to revive several more repos using now obsolete frameworks and build systems.

To give a flavor of what's there, below are some videos and screenshots. See the above link for more details of any of them.

This is only for European languages that use a Latin-based alphabet.

It was adapted from the original diagram What European language am I reading? European language flowchart by mel_afefon which was based on What European language am I reading? A flow chart by @oysteib@masto.ai .

I call this a “phenotype” tree because it represents the visual appearance of the languages, and is distinct from the true tree of how these languages are related. Some languages are close to one another in this phenotype tree because they borrowed alphabets from neighboring or hegemonic languages, despite being from very different language families.

Appendix

For reference, non-English letters in the above diagram:

This opportunity comes from two observations: (1) that the biggest problem in privacy is explaining to the user how their data is used, and (2) that one of the notable abilities of LLMs (large language models) is to summarize complex data understandably.

Over the years working on Internet systems, I have seen big improvements in protecting privacy. Some of this improvement is driven by the increasing public awareness of the importance of privacy and the necessity for companies to address privacy if they want to maintain user trust. Some of this is driven by the need for regulatory compliance, initially with GDPR in Europe, but increasingly with new regulations in various countries and US states.

But what do companies actually do to respond to retain trust and keep in compliance? Let’s divide privacy protection measures into two categories: backend and frontend.

Backend privacy protection is where most of the effort has gone. Much of the work here is around data flows, identifying and controlling how personal data is transmitted through and stored in the complex infrastructure behind large modern Internet systems. While practically doing this can be a difficult engineering task, the requirements are generally well understood.

Frontend privacy protection is much more of an open problem. The areas of understanding and consensus are limited to a few areas such as what “dark patterns” should be avoided and how to create cookie consent UIs (which everyone hates). In particular, there remains the biggest unsolved problem, which is how to give people meaningful agency over how their data is used, given the systems are so complex that it is very difficult even for the engineers building and running the services to explain.

But now we see the opportunity. Explaining complex subjects is one thing that LLMs are good at.

One approach is, given an existing system that has personal data flowing through it, for a particular person using the system, we generate a comprehensive description of all their data and how it is used, perhaps in the context of a particular feature they are using. This raw description would be voluminous, highly technical, and perhaps might contain references to proprietary information, so it would be not at all useful or appropriate to display to the person. However an LLM, with an appropriate prompt, could summarize this raw dump in a way that could be safely and meaningfully displayed to the person. This could provide transparency, customized to the particular context. With different prompts, the LLM output format could be adjusted to match the reading level of the person, and to the size and formatting constraint of the part of the UI in which it is displayed.

This transparency is good, and it would help give a sense of agency to the person. But is there a way to take this further and additionally use LLMs to provide controls?

Well, yes, in some cases if an LLM is incorporated into the system and helps personalize the output, then we can take advantage of the fact that the “API” of an LLM is natural language. That means that somewhere deep in the data flow is some human-meaningful text that is being ingested into an LLM. So we have an opportunity to reveal that text to the person using the system and allow them to modify it, possibly by simply adding or modifying freeform natural language text.

Of course, there are many challenges and possible hazards to using LLMs in these ways. For the transparency proposal, LLMs can hallucinate and generate incorrect summaries of personal data which could be confusing or possibly disturbing to the person. Even if the summary is factual it could present it in a biased manner, for example using gender or racial stereotypes. There is also the possibility that the summary, even if correct and unbiased, could be alarming to the person, but that is arguably a case of “working as intended”: it is better for long-term trust for the person to learn this sooner rather than later, and to thus be able to take prompt action to control how their data is used.

I’m not aware of any such systems yet launched, but I’m hoping it will happen, and in so doing harness the power of generative AI to empower people to make the appropriate trade-offs in each context for how much personal data they want to be used in return for a particular benefit.

As the planet warms due to climate change, the threat of heat waves looms larger than ever. Extreme heat isn't just uncomfortable; it can be deadly, especially when combined with high humidity.

To help visualize this growing danger, I've created a new website: Dangerous Heatwaves

What Makes a Heat Wave Dangerous?

The site focuses on a key metric called the wet-bulb temperature. This isn't the temperature you see on the thermometer. Instead, it's the lowest temperature you can reach by evaporating water – a crucial concept for understanding how humans handle heat.

We cool down by sweating, a process that relies on evaporation. When the wet-bulb temperature gets too close to our body temperature, sweating becomes ineffective. That's when the risk of heatstroke and other heat-related illnesses skyrockets.

• Low humidity: Even with high temperatures, low humidity means a lower wet-bulb temperature, reducing the danger.
• High humidity: This is the worst-case scenario. When it's both hot and humid, the wet-bulb temperature rises, making conditions extremely hazardous.

How the Site Works

The Dangerous Heatwaves site analyzes weather forecasts for locations around the world. It highlights the areas with the highest predicted wet-bulb temperatures in the coming days, giving you a real-time snapshot of where the risk of dangerous heat is greatest.

Why This Matters

Understanding wet-bulb temperature and its impact is essential for preparedness and planning. Whether you're concerned about your health, outdoor activities, or the well-being of vulnerable populations, this tool can help you stay informed and make smart decisions in the face of extreme heat.

I tried to build a simple blog for anyone with a GitHib account.

How to use it

All you do is

1. Fork a repo
2. Do a small amount of configuration of your new GitHub repo
3. Use the GitHub web UI to edit markdown files
4. Your blog gets automatically published as GitHub pages

The GitHub repo with full instructions is at simplestblog

An example of a blog that uses this is eobrain.github.io/mysimplestblog

How it was built

It is a simple Node.js JavaScript app that is built on a simple foundation:

• A markdown library that converts markdown to HTML
• The Mustache library for building pages from templates

Prerequisites:

1. Shell access to your WriteFreely server
2. Node.js installed (I recommend using nvm for managing Node.js versions – installation instructions here)

Steps:

Clone the repository and cd into it:

git clone https://github.com/eobrain/writefreely-export.git
cd writefreely-export

Ensure Node.js compatibility (if using nvm):

nvm use

Finally to do the export do

npm install
npm run export

This creates a content directory containing Markdown files of your WriteFreely posts.

Using the Exported Files

One option is to import your Markdown files into a static site generator like simplestblog. This approach gives you a static backup and an alternate site. For example, this blog is mirrored at mysimplestblog.

Additional Notes:

Consider automating the export process for regular backups.

One improvement I've wished for is the ability to use the Tufte CSS with well-structured semantic HTML, without requiring sprinkling class attributes around the CSS.

So I forked the project and created a new one called, which you can check out at: Classless Tufte CSS.

You can try it out by including this in the <head> section of your HTML:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/eobrain/classless-tufte-css@v1.0.1/tufte.min.css"/>

Your HTML requires no class attributes but should be in a standard semantic structure like this:

<body>
  <article>
    <h1> title </h1>
    <p> subtitle </p>
    <section>
       <h2> section header </h2>
       ... paragraphs, lists, code blocks, figures etc
    </section>
    <section>
    ...

The main features lost in moving to the classless form were

• There is no automatic sidenote numbering
• The <aside>s used to implement margin material must be between paragraphs, they cannot be embedded in the middle of a paragraph.

There are some added features though:

• Lists that are in between paragraphs are also put in the margin.
• The margin material does not disappear for narrow screens. Instead, it is shown inline, indented.
• Code blocks have a subtle background shading
• Tables have some lines

Here is a comparison of the HTML between Tufte CSS and Classless Tufte CSS, so you can see the simplification.

What prompted me to do this is that I'm currently working to convert this blog to a static version, and I wanted to use Tufte CSS for plain semantic HTML generated from markdown.

1. Lower House: The European Parliament is the US House of Representatives.
2. Upper House: The European Council is the US Senate from the early US when the states directly appointed senators
3. Executive: The European Commission is the US President and Cabinet, except there is exactly one cabinet member from each state

On both sides of the Atlantic, both the lower and upper house must agree on legislation before it is passed.

One difference is that in the EU the executive proposes legislation, but in the US it can also be proposed by the upper or lower house

Another practical difference is the US bodies have only two political parties because of the first-past-the-post voting system. In contrast, the EU bodies have many political parties because of greater diversity and more proportional voting systems.

And of course in Europe, the individual member states retain much more sovereignty than US states do (despite what Texas might think).

Update 2024-03-01, more analogs in response to a comment on BlueSky:

EU conciliation committees are US congressional conference committees, except also including some cabinet members, and with a deadline.

Trilogue is when the president invites leaders of both houses of Congress to the White House for an informal chat to move some legislation forward.