Information Architecture and AI

It has become increasingly difficult for me to make sense of where AI is going. Almost every week seems to bring another breakthrough, another warning, or another claim that a fundamental problem has been solved.

For the most part, the direction has seemed clear: make general models more capable, give them more knowledge, more context, more tools, more time to reason, and increasingly let them act on their own. When that isn’t enough, scale further.

There is even a theological idea¹ hiding in this direction: keep accumulating capabilities into a general intelligence powerful enough that, eventually, we can bring almost any problem to it. It has taken us remarkably far, but the consequences of pushing that frontier are becoming harder to ignore, to the point that Dario Amodei has argued we may need to pace the frontier.

Generality is what makes these models extraordinary. But it is worth asking whether pushing general intelligence further is the only frontier worth pursuing.

A Different Frontier

Enter Jev, the first public model from TypeSafe, a company founded by a former OpenAI researcher who helped create ChatGPT.

Jev feels like a breath of fresh air. Watching Diogo Almeida explain the model in funny outfits made me smile, and the message was just as provocative: “We’re building prod, not God.” The form and the idea seemed to reinforce each other: this was a very different way of presenting what a frontier model could be.

The target of this model is different: fast, structured decisions that software can use directly. It’s trained with a new method called Reinforcement Learning for Calibrated Decisions (RLCD). Instead of producing open-ended responses, Jev is given a set of possible outcomes and returns a probability distribution over them.

That makes the interaction with the model quite different from prompting an LLM. You do not ask Jev to explain what a candidate’s profile might be, for example. You define the possible profiles, provide the evidence, and ask it to judge among them. The result is not generated text but a structured decision, together with the model’s uncertainty about the alternatives.

TypeSafe presents Jev as a frontier model and it makes me wonder: what kind of frontier is this? Its capability is narrower and more specific: make an explicit decision from evidence and return a result another program can act on. And that narrowness also surfaced a recurring skepticism in the reactions to the launch: if this model is ultimately just a classifier, why all of this hype?

Taxonomies

Theo Browne gets close to this question in his overview of Jev. He emphasizes what the model actually does: classification, ranking, and structured decisions over data. And that framing makes the skepticism easy to understand: classification is one of the oldest problems in machine learning, and we have had classifiers for decades.

But classification has an interesting property that is easy to overlook: the classifier does not define the categories it classifies into.

Humans have always organized the world by putting things into groups: edible or poisonous, wild or domesticated, land or water, one kind of plant or animal and another. Before something can be classified, there must already be a set of categories to classify it into.

And as those categories grow, they can themselves be grouped, divided, named, and related to one another. What begins as classification becomes a system for organizing a domain: a taxonomy.

Carl Linnaeus, often called the father of modern taxonomy, built one of its most influential examples nearly 300 years ago. In 1735, he published the first edition of Systema Naturae. The classifications themselves would change considerably. Linnaeus revised the system through multiple editions, and later science would replace many of the distinctions he used. What proved more durable was the structure: names, categories, attributes, and relationships that could organize a vast domain of plants, animals, and minerals, and locate one thing in relation to another.

So perhaps “just a classifier” describes what happens at the end, but not everything required to make that classification possible.

That became much clearer when I tried to put Jev to work.

Putting Jev to Work

I wanted a task small enough that I could define not only the decision, but the conditions around it. I chose something familiar to me: looking at a resume and deciding what kind of professional profile the evidence actually supports. I documented the experiment, including the code and results, on GitHub.

I created eight synthetic resumes and four decisions, each asking a slightly different question:

The point was not to reproduce hiring. It was to create a bounded environment where the evidence, the possible decisions, and my expectations could all be made explicit.

I then ran the same resumes through three different models. I deliberately chose models that approached the task in different ways. The goal was not to benchmark equivalent models, but to compare three ways of turning the same evidence into a decision.

Each model received the same resume evidence and decision definitions, but the mechanics and the outputs were different. Jev received the valid choices directly and returned probabilities over them; Luna received instructions and a schema for generating a structured answer; and Qwen ranked each possible answer against the evidence, producing scores rather than probabilities. I was therefore less interested in which model won than in what each approach made available to the surrounding software, although seeing Jev return the four decisions so quickly and consistently across the experiment was striking.

Across the eight resumes, the models often arrived at similar decisions, with a few interesting disagreements. Luna, for example, classified the AI Product Manager resume as a Technical Product Manager in one run.

The most revealing decision, however, was technical_depth. Because its possible answers formed a scale, I could see not only which level Jev chose, but how its confidence was distributed across adjacent levels. In one resume, I considered both 3 and 4 reasonable outcomes. Jev put about 79% of its probability on 4 and 21% on 3. Instead of hiding the ambiguity behind a single score, the output preserved it.

What interested me was that the uncertainty itself became available to the software. Jev did not just return a decision; it exposed how strongly the evidence supported the alternatives I had defined.

That uncertainty could become part of the system’s behavior. An 80/20 decision might be accepted automatically, while a 51/49 one could trigger a review or ask for more evidence.²

And that exposed another part of the experiment: the decision was larger than the model making the judgment. Jev evaluated the evidence, but the possible outcomes, their meaning, and what happened next were defined by the surrounding system.

Explicit Judgment

There were two sides to the experiment. The models had to interpret the evidence and make a judgment, but I had to define the space in which that judgment could happen: what technical_depth meant, which outcomes were possible, and where the boundaries between them roughly belonged.

Those definitions also gave me a way to evaluate the results. Each resume had a human-reviewed expected decision or acceptable range that was kept outside the model instructions. Instead of asking whether the models agreed with each other, I could compare their decisions with the judgment I had intended to encode.

That is essentially what an AI eval does: it gives us a repeatable way to test a model’s behavior against an expected result or criterion. Unlike a traditional software test, however, the output is often probabilistic or subjective, so the evaluation itself may require judgment.

Creating the first eval was relatively easy. Maintaining it would be harder. A new resume might expose a distinction I had missed. Two cases that looked equivalent might turn out not to be. Sometimes the expected result would need to change; sometimes the definition itself would.

That makes evals more interesting than a simple pass/fail test. Evaluating the model also forces us to refine the judgment we are asking it to make.

A judgment like technical_depth does not exist by itself. To define it, I also had to define what counted as experience, ownership, technical complexity, and the evidence for each. Making the judgment explicit was also making its domain explicit.

The Domain Behind the Decision

That structure extends beyond the decision itself. technical_depth only makes sense inside a small domain of related concepts: candidates have experiences, those experiences provide evidence, and that evidence supports a judgment about technical depth.

Candidate → Experience → Evidence → Technical Depth → Decision

Once these concepts and relationships are made explicit, they begin to form a representation of the domain itself³: what kinds of things matter for the decision, what properties they have, and how they relate to one another. It is no longer only a set of possible answers, but a structure connecting the evidence to the judgment we want the model to make.

Software has long relied on explicit representations of domains. We encode them in schemas, tables, classes, types, relationships, and rules so that programs can operate on them. Large language models loosened that requirement. Because they can infer concepts and relationships from language, much of the structure that software once required us to specify could remain implicit.

As soon as we wanted the judgment to become more specific and evaluable, some of that structure started coming back. The model could evaluate the evidence, but we still had to decide what counted as evidence, which concepts mattered, how they related to one another, and where the boundaries of the decision were.

This did not mean modeling the entire domain. A candidate is obviously more than their experience, and their experience is more than the evidence available in a resume. We only needed enough structure to make this particular judgment meaningful.

And that reveals an interesting tradeoff: the less we ask the model to figure out, the more we have to figure out ourselves.

That need to make the structure of a domain explicit reminded me of an idea I first encountered through information architecture.

Information Architecture

Years ago, I came across a short article by designer Mark MacKay with a title that stayed with me: “Carolus Linnæus, the First Information Architect.” The post is only a few paragraphs long, and much of the idea is already contained in the title.

The post is also playful. I learned that Linnaeus liked the phrase “God creates, Linnaeus organizes.” And after the botanist Johann Siegesbeck criticized his classification system, Linnaeus named a small, unpleasant-smelling plant Siegesbeckia after him.

MacKay called Linnaeus an information architect. The term fits because the work was not simply classification. Systema Naturae gave information a structure. The individual observations already existed, but the architecture was the system that made them legible together.

Information architecture is often associated with websites, but the underlying problem is broader. It is about organizing information so that a complex domain can be understood and used. A taxonomy is one part of that structure. Definitions, relationships, and ways of navigating between concepts are others.

That makes the connection to Jev more concrete. We did not only give the model information. We progressively gave that information structure: choices to distinguish between, definitions to judge against, evidence to consider, and a domain in which those decisions had meaning.

This is where Jev starts to look different from the way we have become accustomed to working with large language models.

With an LLM and generative AI, much of the structure can remain implicit. We describe the problem in natural language and rely on the model to reconstruct the domain, infer the relevant distinctions, and decide what matters. Jev moves some of that work outside the model. The intelligence becomes narrower, but the world around it needs to be more explicit.

Taxonomies and domain models give that world structure. They establish what exists, what can be distinguished, and what counts as evidence for a judgment. In that sense, information architecture is not simply organizing information for an intelligent system. It defines the world in which that intelligence has something specific to do.

This is what makes Jev more interesting to me than “just a classifier.” The frontier it points to is not simply another capability to add to an increasingly general model. It suggests that progress can also happen around the model: in how precisely we define a domain, structure its information, and design the decisions we want intelligence to make.

That is a very different direction from putting more and more of the world inside the model.

Conclusion

Jev started as an interesting counterpoint to the direction AI seemed to be taking. What initially looked like a narrower model gradually became a different way of thinking about where the intelligence of a system comes from.

General intelligence encourages us to think in terms of accumulation: more knowledge, more reasoning, more tools, more autonomy, until enough capabilities begin to converge in the same model. Jev does almost the opposite. It gives the model a more specific job and makes us design more deliberately around it.

That difference matters beyond architecture. When a capability has a defined domain, explicit decisions, and observable criteria for success, it begins to look more like something we already know how to engineer. We can describe it, test it, combine it with other capabilities, constrain it, and hold it accountable for particular functions. Safety becomes less about controlling an intelligence capable of doing almost anything, and more about designing systems whose behavior we can specify and evaluate.

Perhaps that is why the distinction matters. The future of AI does not have to be understood only as a race toward increasingly general intelligence. Some of its most important progress may come not from making intelligence more general, but from making its boundaries more explicit.