5 amazing visuals show how the male fruit fly’s brain map is advancing neuroscience

Mike's Notes

The brain's structural complexity is fascinating.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > News from Google
  • Home > Handbook > 

Last Updated

29/09/2026

5 amazing visuals show how the male fruit fly’s brain map is advancing neuroscience

By: Michał Januszewski & Viren Jain
News from Google: 03/09/2026, Updated 21/09/2026

Michał Januszewski: Research Scientist, Google Research.

Viren Jain: Research Scientist, Google Research.

...

A years-long project by HHMI Janelia, Google Research, and collaborators has built the first complete brain map for a male fruit fly, a key model organism in science.

Updated September 21, 2026

For the first time, scientists have mapped every single neural connection in the brain and central nervous system of an adult male fruit fly. In this years-long project by HHMI Janelia Research Campus, Google Research, a team in Cambridge, U.K., and collaborators from the scientific community, this map of the male fruit fly brain includes a record-breaking more than 166,000 neurons. It’s a big step in advancing neuroscience experiments on this key model organism.

AI is making it possible for scientists and researchers to exponentially scale projects in the field of connectomics, which precisely reconstruct the connections between brain cells. This new complete brain map, a first for a male fruit fly, builds on the earlier release of a complete female fruit fly brain map, and promises to be a foundational resource for neuroscience for years to come.

Today, we’re sharing five images from the project.

1. A record-breaking map: charting more neurons than ever before

Angled brain map of the male fruit fly

This image shows selected neurons in the male fruit fly’s brain and ventral nerve cord, which is analogous to a spinal cord.

Like humans, flies do most of their sensing using organs located on their heads, including two huge compound eyes and a retractable proboscis that extends to detect smell and ingest liquid food. Neurons in these sensing organs detect external information and pass the signal through pathways that eventually reach the motor neurons that control movement.

2. Brain + nerve cord: Connecting sensing to actions using AI

Male fruit fly brain map when viewed from above

When seen from above, the fruit fly’s massive eyes and central brain stand out. They connect via a thick cord of nerves to the body, where motor neurons control behavior. This map was created by taking thin sections of a fruit fly brain and body, imaging each slice, and then using computers and AI to combine millions of 2D images to create 3D neural shapes. Knowing the structure of the brain allows neuroscientists to understand the mechanisms behind brain function.

3. Inside the black box: Visualizing almost 11,700 types of neurons

Male fruit fly CNS cell types. 0:32

(Data acquired and analyzed by the FlyEM Project Team at HHMI-Janelia, the Cambridge Connectomics Group, and Google Research. Video by Philip Hubbard.)

This video shows some of the 11,691 types of neuron cells in the male fruit fly’s central nervous system, which includes the brain and ventral nerve cord. Neurons can be categorized by size, shape, function, gene expression, or other factors. This visualization begins with neurons at the core of the brain and body. It then gradually moves to outer layers and, finally, to neurons at the extremities. Computing and AI helped human experts classify more than 166,000 neurons.

4. Vive la différence: Brain differences between male and female fruit flies

Sexual dimorphism in the fruit fly central nervous system. 0:56

(Data acquired and analyzed by the FlyEM Project Team at HHMI-Janelia, the Cambridge Connectomics Group, and Google Research. Female data acquired by the FlyWire project. Video by Philip Hubbard and Isabella Beckett.)

While most neurons in male and fruit females are the same, or isomorphic, a minority are sex-specific. A third category of neurons are “dimorphic,” existing in both males and females but connecting to different neighboring neurons. These neighbors may be isomorphic, the same in both male and female, or sex-specific, or even dimorphic themselves. This video shows one example, for the neural type AOTU012 (blue) that plays a role in processing sensory and taste inputs. While paired AOTU012 neurons exist in both male (left) and female (right) fruit fly brains, the AOTU012 connect to both similar (green) and different (red, orange and yellow) neurons in male and female fruit flies.

5. Fly see, fly do: Connecting stimulus to motion

Example visual-motor pathway in the fruit fly. 0:51

(Data acquired and analyzed by the FlyEM Project Team at HHMI-Janelia, the Cambridge Connectomics Group, and Google Research. Video by Philip Hubbard and Alexandra Fragniere.)

The new brain map of the male fruit fly includes visual-motor pathways. These connect the visual neurons, which help the fly detect its environment, to motor neurons, which help it move in response. This video shows an example of such a pathway, going from the R1-R6 visual neurons (purple) to the DNg13 motor neuron (green). In between are several intermediate steps, including the male-specific LoVP92, named for the so-called “love spot,” that plays a role in courtship behavior.

Three companion studies also released today apply the new brain map to studying visual systems, taste, and social behavior. Read more about this groundbreaking project, and about our ongoing efforts to map full vertebrate brains, on the Neural Mapping website and in the Google Research Blog post.

Semantic and Context Layers via Open Standards

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part eight: A post by Kingsley Uyi Idehen on LinkedIn.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

28/09/2026

Semantic and Context Layers via Open Standards

By: Kingsley Uyi Idehen
LinkedIn: 20/09/2026

Kingsley Uyi Idehen: Founder & CEO at OpenLink Software | Driving GenAI-Based AI Agents | Harmonizing Disparate Data Spaces (Databases, Knowledge Bases/Graphs, and File System Documents)

Architecture for interoperable systems

Most data systems can tell you what a value is. Far fewer can tell you what it means within a shared universe of discourse. An ontology supplies that contextual frame: the concepts, relationships, constraints, and identity anchors through which a semantic layer becomes interpretable

Architecture at a glance

Figure: ontology as the context layer enclosing the semantic layer (TBox / RBox / ABox), grounded in RDF and expressed through open notations.

The architecture is compact but consequential. At the top sits a semantic layer: a TBox that defines the vocabulary with [RDF Schema (RDFS)](https://www.w3.org/TR/rdf-schema/), an RBox that defines relationship behavior with [OWL 2](https://www.w3.org/TR/owl2-overview/), and an ABox that supplies assertions about actual things. Around it sits the context layer—basically, the ontology that establishes the formal frame in which those terms, relationships, and assertions are understood. Beneath this ontology-enclosed semantic model is [RDF](https://www.w3.org/TR/rdf12-concepts/)—not a file format, but an abstract graph model that can be expressed through multiple concrete notations and serialization formats, including [Turtle](https://www.w3.org/TR/turtle/) and [JSON-LD](https://www.w3.org/TR/json-ld11/).

This separation matters because syntax alone does not produce interoperability. Two systems can exchange perfectly valid JSON and still disagree about the identity of the things being described, the meaning of their properties, or the conditions under which a statement should be applied. Open standards give us a way to make those assumptions explicit.

The ontology is the context: it establishes the shared frame in which terms, entities, relationships, and assertions acquire usable meaning.

RDF Schema - https://www.w3.org/TR/rdf-schema/ provides the TBox vocabulary for declaring classes, properties, domains, ranges, and class and property hierarchies through rdfs:subClassOf and rdfs:subPropertyOf.

The RBox—the role or relationship component—uses [OWL property axioms](https://www.w3.org/TR/owl2-syntax/#Object_Property_Axioms) to define how relationships behave. It captures characteristics such as transitivity and symmetry, inverse relationships, functionality, property chains, and related constraints.

The ABox—the assertional component—contains claims about particular entities: this organization issued this invoice; this product has this offer; this document was generated by this activity. It can also contain an explicit [*owl:sameAs*](https://www.w3.org/TR/owl2-syntax/#Same_Individual) assertion that two identifiers denote the same individual; the same equivalence can be inferred implicitly through OWL reasoning. The TBox supplies the shared classes and vocabulary, while the RBox supplies the semantics of the relationships. The ABox uses both to describe the world.

Keeping the three conceptually distinct produces leverage. Vocabulary and relationship semantics can evolve without being buried inside application code, and instance data can be interpreted by software that was not present when the data was created. A row in one database, an object in an API response, and a statement in a document can all refer to the same identified entity and use the same published predicate.

The context layer: ontology as the frame

A semantic statement rarely stands alone. “Alice approved the payment” is useful, but an operational system will immediately ask: Which Alice? What is an approval? Acting in what role? On behalf of whom? At what time? Against which policy? Using which source record? Is the assertion current, superseded, inferred, or disputed?

The ontology provides this context layer. It defines the domain’s universe of discourse and supplies the classes, relationships, rules, and reusable vocabularies needed to interpret the semantic layer. In practical systems, that ontological frame commonly covers:

  • Identity and authority: the agent responsible for an assertion and any delegation under which it acted.
  • Provenance: the source entities, activities, and transformations that produced the assertion.
  • Time and scope: when a statement was generated, when it applies, and the graph or dataset in which it is asserted.
  • Policy and purpose: the rules governing access, use, validation, or disclosure.
  • Quality and confidence: whether the data conforms to an expected shape and what evidence supports it.

The open-standards ecosystem already provides useful ontological building blocks. [PROV-O](https://www.w3.org/TR/prov-o/) defines an RDF vocabulary for entities, activities, agents, derivation, attribution, and delegation. RDF Schema and OWL define domain vocabularies and axioms. RDF datasets provide a default graph plus named graphs, giving applications a standard structural basis for organizing distinct assertion sets. [SHACL](https://www.w3.org/TR/shacl/) describes constraints over RDF graphs, allowing a system to state and test what acceptable contextualized data should look like.

The semantic layer: shared meaning before shared data

The semantic layer begins with distinctions borrowed from knowledge representation. The TBox—the terminological component—defines the kinds of things a domain recognizes. Classes such as Person, Organization, Product, or Invoice live here, together with the vocabulary used to describe them.

The key architectural choice is to make the ontology explicit rather than hide its assumptions in code, prompts, middleware, or undocumented conventions. Once the contextual frame is represented with identifiers and shared vocabularies, it can be queried, validated, exchanged, and audited using the same graph machinery as the domain data it governs.

RDF is the model—not the notation or serialization format

The lower half of the visual makes a distinction that is often missed. RDF is an abstract data model. The [RDF 1.2 Concepts](https://www.w3.org/TR/rdf12-concepts/) specification describes RDF graphs as sets of subject–predicate–object triples and RDF datasets as a default graph plus zero or more named graphs. An RDF document represents that graph or dataset using a concrete notation that also serves as a serialization format.

Turtle and JSON-LD are two such RDF notations and serialization formats. Turtle is compact and well suited to human authoring and inspection. [JSON-LD 1.1](https://www.w3.org/TR/json-ld11/) carries Linked Data through familiar JSON structures and integrates naturally with Web applications. They may look very different, yet both can represent the same underlying graph.

This gives architecture an escape hatch from format lock-in. One team can work in JSON-LD, another in Turtle, and a third through a SPARQL endpoint. As long as their documents map to the same identifiers and graph statements, the meaning survives the change in notation or serialization format.

An open standards stack

The diagram becomes more useful when read as a small stack of separable responsibilities:

Responsibility Open-standards role
Identity IRIs give entities, properties, graphs, agents, and policies globally referenceable names.
Semantic layer The TBox, RBox, and ABox work together to provide shared terminology, relationship semantics, and instance assertions.
Terminology RDF Schema publishes the class and property vocabulary and the *subClassOf* and *subPropertyOf* hierarchies that form the TBox.
Relations OWL supplies the RBox axioms that characterize relationships—for example, transitivity, symmetry, inversion, functionality, and property chains.
Assertions RDF graphs express ABox facts—including *owl:sameAs* equivalence asserted explicitly or inferred implicitly—while remaining independent of storage layout.
Context The enclosing ontology supplies the shared contextual frame, reusing vocabularies such as PROV-O for source, agent, activity, time, and scope.
Validation SHACL states machine-readable expectations for nodes, properties, cardinalities, datatypes, and relationships.
Access SPARQL](https://www.w3.org/TR/sparql11-query/) queries the graph by meaning and relationship rather than by one application’s table or object layout.
Exchange Turtle, JSON-LD, and other RDF notation–serialization format combinations carry the same abstract model across tools and organizational boundaries.

Why this matters now

The context problem becomes acute when software agents participate in workflows. A model can generate a plausible answer from text, but an accountable agent needs more: stable identifiers, source lineage, authorization boundaries, validation rules, and evidence that another system can inspect independently.

A semantic layer helps the agent understand that two differently shaped records refer to the same kind of entity—or the same entity. An ontology supplies the broader context needed to determine whether a statement is applicable and trustworthy for the task at hand. Open standards keep both layers from becoming proprietary memory trapped inside one model, vendor, vector index, or application.

This is also why a knowledge graph should not be reduced to “a database with edges.” The durable value lies in the contract around the edges: globally referenceable identities, published semantics, explicit provenance, reusable constraints, and a standard query model. The graph becomes a medium through which independent systems can exchange not just values, but interpretable claims.

A practical implementation pattern

  1. Start with identifiers. Mint or reuse stable IRIs for the entities, concepts, agents, and policies that must survive outside one application.
  2. Find, reuse, and cross-reference shared vocabularies. Create your own only as a last resort. That said, you can begin with your own vocabulary and progressively cross-reference it with shared ontologies as you—or, increasingly, your agents—discover them. **Construct** only the smallest useful set of TBox and RBox terms and axioms.
  3. Represent assertions separately. Keep domain facts in ABox graphs and preserve their source boundaries rather than flattening everything into an anonymous pool.
  4. Attach additional context progressively. Record provenance, time, delegation, validation state, and applicable policy using named resources and reusable vocabularies.
  5. Validate and expose. Use SHACL to validate graph-shape conformance, SPARQL for inquiry, and content negotiation or APIs to deliver the graph in the notation and serialization format each consumer can use.

The point is not to deploy every standard at once. It is to keep the architecture open at each boundary. Begin with the identifiers and semantics that remove the most ambiguity. Add context where decisions require evidence. Add validation where downstream systems need guarantees. Preserve the abstract graph so that serialization and storage remain implementation choices rather than permanent constraints.

The durable architecture

The sketch’s lasting insight is the separation of concerns through containment. The semantic layer expresses RDF Schema vocabulary in the TBox, OWL relationship axioms in the RBox, and instance assertions in the ABox. The enclosing context ontology establishes the shared interpretive frame—including identity, provenance, time, policy, and purpose. RDF supplies a common abstract model. Open notations and query standards make the result portable.

When these pieces are collapsed, meaning leaks into code and context disappears into operational exhaust. When they are separated but connected through open standards, data becomes easier to integrate, agents become easier to govern, and decisions become easier to explain.

That is the real promise of semantic and context layers: not another abstraction for its own sake, but a Web-native foundation for exchanging claims whose meaning and conditions of use can travel together.

Standards referenced

Related

1. LLMs Obsolete the GUI Moat. They Don’t Obsolete Loosely Coupled Architecture Built on Open Standards

2. Ontology by Another Name: Why BI "Semantic Layers" Are Just Narrow TBoxes — and R2RML Is the Open Path Out

3. The Agent Engineering Stack Nobody Shows You

#CDO #CDIO #CAIO #CIO #CTO #CMO #CxO #AI #Agentic #AgenticWeb #SemanticWeb #LinkedData #KnowledgeGraph #DataSpaces #RDF #Ontology #SPARQL #OWL #RDFS #SHACL

Posted on my behalf by Phenny

Innovation Portfolio Management: Strategy Before Tools or Framework

Mike's Notes

Everything from Tristan Komer is deeply insightful. The same goes for Steve Blank, Alex Osterwalder, and Jason Cohen. I use them to figure out what to do.

Ajabbi aims to make money to provide a good service. All future profits will go to a yet-to-be-established non-profit foundation to fund open research, science communication, and support for the Pipi user community. Ajabbi has many moving parts: the Business Model Canvas and the Mission Model Canvas are useful tools.

Resources

References

  • The Real Startup Book (2nd edition, 2026) by Tristan Komer

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Kromatic
  • Home > Handbook > 

Last Updated

27/09/2026

Innovation Portfolio Management: Strategy Before Tools or Framework

By: Tristan Kromer
Kromatic: 09/07/2019

Tristan Kromer: Tristan Kromer is an innovation coach and the founder of Kromatic. He helps enterprise companies build innovation ecosystems and works with startups and intrapreneurs worldwide to create better products for real people. Editor of The Real Startup Book (2nd edition, 2026), a free field guide to 51 experiments for finding product/market fit. Speaker and longtime advocate for lean startup and innovation accounting methods, now focused on how AI changes (and does not change) the customer-discovery work that decides whether a startup lives.

Martin Kupp: Martin Kupp is an associate professor for entrepreneurship at ESCP Europe in Paris and a visiting professor at the ESMT European School of Management and Technology in Berlin. His work has appeared in California Management Review, MIT Sloan Management Review, Business Strategy Review, Info Journal, Financial Times, the Economist, the Economic Times of India and the Wall Street Journal.

...

Stop shopping for frameworks until you know what you're optimizing for

...

Quick Answer: An innovation portfolio without a clear strategy behind it is just innovation theatre. Before choosing any framework or tool — whether McKinsey’s Three Horizons, the Innovation Ambition Matrix, or Strategyzer’s Portfolio Map — we need to define our innovation strategy, understand our risk tolerance, and ensure alignment with senior leadership. Each tool is simply a lens that emphasizes different dimensions (resources, timing, risk, options), so as innovation managers, we should mix, match, or create our own frameworks optimized for the specific decisions we need to make.

...

Innovation portfolio by Martin Kupp & Tristan Kromer

Martin Kupp is an associate professor for entrepreneurship at ESCP Europe in Paris and a visiting professor at the ESMT European School of Management and Technology in Berlin. His work has appeared in California Management Review, MIT Sloan Management Review, Business Strategy Review, Info Journal, Financial Times, the Economist, the Economic Times of India and the Wall Street Journal.

Tristan Kromer works with innovation teams and leaders to create amazing products and build startup ecosystems. He has worked with companies from early stage startups with zero revenue to enterprise companies with >$1B USD revenue (Unilever, Swisscom, Salesforce, Fujitsu, LinkedIn). Newly appointed VPs of Innovation have been popping up in every company these days. While they are often given vague tasks such as “install the entrepreneurial mindset in the core business” and “look to the future,” managing the innovation portfolio is one of their most important responsibilities. To manage your innovation portfolio, you need to know what to optimize for.

What Is Innovation Portfolio Management?

Innovation Portfolio Management is the process of allocating finite resources into potentially infinite opportunity arenas and then into specific projects to capture a strategic objective. Decisions are not based on individual projects, but on an ideal mix of investments over arenas due to the uncertainty of innovation projects.

Why Bother? Isn’t Innovation Unpredictable?

While it is virtually impossible to predict the financial output of a highly transformational innovation at the very early stages, some projects are substantially less risky. There is a big difference between the transformational approach of moving financial transactions to blockchain and a core innovation of simply providing SMS updates on the status of the same financial transaction. No innovation is certain — they all represent different risk profiles. Just as a good retirement fund will spread its investment into high-, medium-, and low-risk categories, companies must decide where and how to allocate their resources in an ever-changing environment. By diversifying investments into many different bets instead of one big transformation project, managing our innovation portfolio can make the overall output more predictable. The primary goal of building innovation portfolios is to make the unpredictable more predictable.

It’s Not About the Tools

From the McKinsey Three Horizons model, to the Innovation Ambition approach used by Google, to the Strategyzer Innovation Portfolio, academics and consultancies alike are putting ever more tools on the market, each promising to solve the difficult task of managing innovation. A person with tools in his mindEven the word tool is confusing. What used to be a piece of paper presenting a framework or template is now called a tool by many companies and consultants. The innovation portfolio management software used to visualize all this information is now called a platform. The number of frameworks, tools, and platforms to manage innovation is growing almost as fast as the number of salespeople pitching them. 5 People with a laptop computer in their hands and their innovation manager.Before measuring the pros and cons of one tool versus another, an innovation manager needs to understand why they are building an innovation portfolio, and more importantly, what interdependencies need to be identified, monitored, and visualized. The right tool should not only provide a broad overview of the portfolio, but should also help the manager allocate resources, set priorities, and develop options for the future. In helping innovation managers visualize the portfolio, the right tool will force them to make decisions by making the need for decisions obvious. Ultimately it is up to the manager to say no to projects that would only distract the team and suck up resources. This requires strategy.

Prerequisites for Innovation Portfolio Tools

Before choosing their tools, a surgeon knows exactly what they have to do and what they want to achieve. No one wants a surgeon just cutting away without a clear objective. The same is true for innovation managers and CEOs.A surgeon asking his patient if he's using his foot a lot. Innovation Strategy The first prerequisite of any innovation portfolio is that there is an actual innovation strategy. What is promoted inside the company as a strategy is often no more than an empty slogan like “Be the most innovative.” A viable strategy will tell you which projects belong in the portfolio and which do not.

Vision

Similarly, slogans such as “Unlock the innovation potential of digital transformation” are equally useless. This simply tells the company that anything with a mobile app will get approval while worthwhile cost-cutting measures and routine operations are out of favor. The strategy must clearly state what trends are impacting the business environment, where the tipping points are, and where the company wishes to position itself in the future. Are there technological, social, economic, or other trends? Are they predictable linear trends, or do they represent exponential changes that will appear very slowly, but will quickly reach a tipping point? Where does the company need to be positioned when the tipping point happens to make use of the opportunity?

Risk Tolerance

Does the company have a high tolerance for risk, and does it seek to transform the way all businesses in the industry operate? Does it have a low tolerance for risk, or does it operate in a very slow-to-change environment? Companies must understand their own vision for the future and their tolerance for risk, and use them to define the scope of their innovation ambition. Many companies state lofty ambitions but focus their entire rewards and performance reviews system on quarterly goals. This leads to focus only on core innovation. But what is core innovation other than the acceptance of the status quo? Without clear alignment, any attempt at strategic innovation portfolio management is useless.

Strategic Alignment & Communication

Developing and aligning the strategy with action requires good communication between innovation managers and senior management. Senior managers should be actively involved in the development of the innovation-portfolio approach to help innovation departments not only fund projects to some level of success, but to prevent them from being orphaned when no one from the C-suite is interested in adopting the project into the core business. — a company may start with a clear portfolio strategy and only discover during execution a better, emergent strategy that requires a pivot. It is during this iterative portfolio management process that innovation managers and executives discover the insight needed to continuously improve their company’s innovation potential.

Portfolios Are About Interdependencies

The underlying premise of developing and using an innovation portfolio lies in balancing key aspects of the business: resources, time, risk, options, and last (but not least) profitability. Each of these elements can serve as the main perspective of a dedicated portfolio approach, or implicitly integrated into an alternate approach. In the early days of innovation portfolios, one of the central concerns was whether the company or business unit would have enough resources to support all of the innovation efforts, and a number of innovation portfolios were developed that tried to better understand or predict the resources involved in new product development. In 1992, Wheelwright and Clark developed a tool for mapping five types of development projects: derivative, breakthrough, platform, R&D, and alliances and partnerships. Their initial observation was that many companies initiate too many projects and ultimately lack the resources to follow through, leading to high failure rates. Companies would have to understand the nature of their projects to be able to balance the necessary resources for different types of innovation. One of the weaknesses of this approach is centered around the “going concern” principle. In other words, infrastructure is maintained, even if it might soon be obsolete — so investments in some platforms, alliances, and R&D capacity may also become obsolete. Accepting that some projects or capabilities will eventually be stopped makes it necessary to “overbook” the innovation pipeline, much like an airline overbooks seats. Some people are bound to cancel, so the seats are kept full. But what is the right amount of overbooking? This is where timing and throughput become critical. Two people can only afford to buy a half of a car.

Only four years later, in 1996, McKinsey consultants Baghai, Coley, and White published their “Three Horizons of Growth” model, which distinguishes between the current core business, emerging growth businesses, and options for future staircases. 

McKinsey's chart, The Three Horizons of Growth.

While the main focus here is on the timeline, there is also a link to risk in the sense that Horizon 1 is close to the existing core business and therefore less risky, while Horizons 2 and 3 lie farther away from the core business, and are therefore inherently more risky. And given that disruption is happening faster than ever, hoping that disruption is always 5-10 years away seems itself a risky proposition.

In 2012, Bansi Nagji and Geoff Tuff wrote about the Innovation Ambition Matrix to facilitate conversations about portfolio management based on risk and scale of ambition. The matrix is based on mathematician H. Igor Ansoff’s classic diagram to help companies allocate funds among growth initiatives, but it replaces Ansoff’s binary choices of product and market (old versus new) with a range of values. In addition to providing an overview of all innovation initiatives (which all portfolio approaches aim to do), this matrix focuses on the overall ambition for the company’s innovation portfolio and thus its appetite for risk.

Diagram of Innovation Ambition Matrix.

Although time may be an implicit consideration—transformational initiatives are more likely to be long-term — this approach clearly focuses on risk. Companies typically use such a risk matrix to allocate resources based on their ambition and risk tolerance.

A more recent approach, the 2017 Business Model Portfolio Map by Osterwalder and Pigneur, combines elements of the Innovation Ambition Matrix with a clear focus on business models. The Explore section on the left represents transformational projects that give way to more adjacent projects in the middle, while the Exploit section on the right represents the core or adjacencies that are ready for execution.

Explore and Exploit Business Model Portfolio Map. This model allows for adjacent projects to be compared to more transformational projects in terms of expected returns and “innovation risk,” which is another way of identifying the amount of validation a business model currently has. (An adjacent business model that only changes one element of the core business already has a high degree of validation.) so it’s not surprising that scholars like Rita McGrath focus on Arenas of opportunity. For McGrath, an arena is “a combination of a customer segment, an offer, and a place in which that offer is delivered.” Others may use different terms and talk about emerging trends or micro-battles, but McGrath’s main point is that these opportunities are transient and must be captured and exploited immediately. There is no sustainable, long-term advantage. As the consumer landscape shifts, companies can look for growing markets and invest more where the growth exists. McGrath developed a prescriptive portfolio approach based on understanding what type of options need to be developed in any given arena. For example, if a company is not well organized to address an arena and the market is unclear but the technology seems to already exist, then generating options by scouting existing companies is a viable path.

McGrath's portfolio.

Be Creative, Create Your Own!

The portfolio tool an innovation manager chooses serves as a lens through which they see the company’s innovation efforts, and will ultimately influence the decisions being made. So choosing the appropriate portfolio tool is a key part of the innovation manager’s job. This simple task can become increasingly complex as each executive demands that their viewpoint be included in the portfolio map. Some want to focus on a mix of projects leading to healthy returns in a certain timeframe, while others see disruption as more urgent and want to balance risk. New frameworks often attempt to combine one or more of these attributes.

The 4:3 Corporate Startup Portfolio framework by Dan Toma is exactly such a tool, combining the Three Horizons Model with the Innovation Ambition Matrix. Here, they have mapped out Alphabet’s innovation portfolio as an example.

Alphabet’s innovation portfolio.

Radar charts are another approach to combine several attributes, as they can compare different projects across multiple axes. Despite this flexibility, they tend to be difficult to use for a portfolio of more than a few dozen projects. They also don’t effectively show overall investment levels in any given area (although a cumulative radar chart can be used to this effect).

A radar chart.

A divided pie chart can roughly combine different Arenas of opportunity with either the Three Horizons Model or the Innovation Ambition Matrix. For example, the core business (Horizon 1) is the center of the pie chart while transformational (Horizon 3) is the outermost portion. The Arenas are represented by slices. This visually represents that there is more surface area in the outermost portion and thus more opportunity in transformational or Horizon Three projects. That’s simply due to the fact that there is more uncertainty and thus more possibilities. Those possibilities may collapse at some point, but the future generally has more options.

A pie chart.

There are additional options to represent investment by the size of the dot or the level of business model validation by color. But trying to make a visually impressive slideshow that represents everything at once can turn into a useless decision-making tool.


Pie Chart with Project Dots

Perhaps by now you’ve noticed that there is no right or wrong in portfolio management. You can and should create your own portfolio approach that takes your specific situation into account (or mix and match existing tools). You can choose what you want to focus on (resources, time, risk, options) and how you might integrate additional points of view.

Conclusion

Ultimately, innovation managers need to build frameworks that are useful for making decisions. They cannot be so complex that no one understands them, but they cannot be so simple as to remove rigorous thinking from the process. A good framework for building innovation portfolios should uncover where companies are overinvesting and where they are not investing. This transparency will allow executives to make coherent decisions on how to reallocate resources. Having multiple frameworks and dimensions to measure the portfolio is an absolute must. Managers should understand constraints and requirements in terms of resources, time frame, risk, and optionality, and how they fit into the overall strategy. Without that basis in strategy, any portfolio map is an academic waste of time at best, and innovation theatre at worst.

Lessons Learned:

  1. A portfolio framework without strategy is a performance, not a usable tool.
  2. Know what you are optimizing for (resources, timing, risk, options).
  3. Be creative: use existing tools, mix and match, and develop your own toolkit.

Special thanks to those who contributed early feedback to this post: Rob Aalders, Dan Toma, Franck Debane, Jorge Castellote, Esther Gons, Josh Berry, Chris Cannon, Megan Kennedy, Alexia van Schaardenburg.

Frequently Asked Questions

What is innovation portfolio management and why does it matter?

Innovation portfolio management is the process of allocating finite resources across opportunity arenas and specific projects to achieve strategic objectives. Rather than betting on individual projects, we diversify investments across different risk levels — much like a retirement fund — to make the inherently unpredictable nature of innovation more predictable and manageable overall.

What do I need before choosing an innovation portfolio tool?

Before selecting any tool, we need three prerequisites: a clearly defined innovation strategy (not just a slogan like “be the most innovative”), an honest understanding of our organization’s risk tolerance, and strong strategic alignment between innovation managers and senior leadership. Without these foundations, any portfolio map becomes innovation theatre rather than a useful decision-making instrument.

What are the main frameworks for innovation portfolio management?

Key frameworks include Wheelwright and Clark’s resource-based project mapping, McKinsey’s Three Horizons of Growth model (focused on time), Nagji and Tuff’s Innovation Ambition Matrix (focused on risk), Osterwalder’s Business Model Portfolio Map, and McGrath’s Arenas of opportunity approach. Each emphasizes different dimensions — resources, timing, risk, or options — and we can mix and match them to fit our specific context.

Should I create my own innovation portfolio framework?

Yes. There’s no single right answer in innovation portfolio management. We should feel empowered to combine existing tools or build custom approaches that reflect our specific strategic situation. The key is ensuring the framework helps uncover where we’re overinvesting or underinvesting, while remaining simple enough to drive actual decisions rather than just creating impressive slideshows.

Why shouldn’t I focus on tools first when managing an innovation portfolio?

Tools are only lenses through which we view innovation efforts — they shape the decisions we make. If we start with tools before understanding what we’re optimizing for (resources, timing, risk, or options) and how those interdependencies relate to our strategy, we risk making decisions based on whatever the tool happens to highlight rather than what actually matters strategically.

htmx 4.0.0 has been released!

Mike's Notes

More details from Carson about htmx 4.0.

Resources

References

  • Hypermedia Controls: From Feral to Formal

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

26/09/2026

htmx 4.0.0 has been released!

By: Carson Gross
HTMX: 28/08/2026

Carson Gross: I am a programmer comfortable with both front-end & back-end development. I currently teach at Montana State University.

My primary technical interests are hypermedia and programming languages, but I’m comfortable working in most areas of enterprise systems.

...

Release announcement, 2026-08-28.

htmx 4.0.0 Release

The htmx team is very happy to announce the release of htmx 4.0.0! This is the culmination of 8 months of work (plus a game) and we are very happy with the results.

The idea of htmx 4 started to germinate when I decided to create fixi and, in doing so, got more familiar with the fetch() API and async programming in JavaScript. (htmx had always used XMLHttpRequest due to backwards compatibility issues.)

One chance evening I was contacted by Christian, who had some interesting ideas around streaming HTML that got me thinking that moving the internals to fetch() would simplify things for him and for the library in general.

After a bit of work I managed to get Michael and Alex on board, and we were off to the races.

Development has been very smooth. We started a port of fixi + the htmx test suite. Over time, we rediscovered why htmx did many of the things that it did and moved our new implementation closer and closer to the old one. At this point the behavioral differences between 2.x and 4.x are relatively small and where they do diverge we have made explicit choices that we feel will put htmx-based applications in a good spot for being 100-year web services

Note that we are not marking 4.0 as latest in NPM because we do not want to force-upgrade users who are relying on non-versioned CDN URLs for htmx. Instead, 2.x will remain latest and the 4.0 line will remain next until some point in early 2027. The website, however, will reference 4.0.

Major Changes

As mentioned above, htmx 4, from a user’s viewpoint, is almost identical to htmx 2. There are three major changes:

  • Attribute inheritance is now explicit by default rather than implicit by default (this is the biggest upgrade item)
  • The htmx event names have been standardized & cleaned up. Some advanced users may need to change the events they listen for.
  • History support now does not use localStorage by default (which was a cause of many support headaches). Most people won’t notice this at all.

Internally, we migrated from XMLHttpRequest to fetch() but that should be transparent for most users of htmx.

Attribute Inheritance

In htmx 2 many attributes were “inherited” by default. This allows you to place attributes on parent elements and their behavior will apply to child elements. This behavior, which came from the intercooler.js days, was inspired by CSS and, unsurprisingly, worked out about the same as CSS: powerful but difficult to understand at times.

In htmx 4 attributes are not inherited unless you explicitly say so by adding an :inherited after the attribute name:

<!-- htmx 2 -->
<div hx-confirm="Are you sure?">
    <button hx-delete="/item/1">Delete</button>
</div>
<!-- htmx 4 -->
<div hx-confirm:inherited="Are you sure?">
    <button hx-delete="/item/1">Delete</button>
</div>

This will be the largest upgrade burden in migrating from htmx 2 to htmx 4. To make things easier, we have provided a command line tool to find places you need to mark as inherited.

Note that attributes like hx-disinherit, etc. are no longer required and should be removed.

Events

The events triggered by htmx 2 had grown organically over the life of the library and were not particularly well organized, making it difficult to know exactly which event was fired when.

In htmx 4, all events now follow htmx:phase:action[:sub-action]:

htmx 2 htmx 4
htmx:beforeRequest htmx:before:request
htmx:afterRequest htmx:after:request
htmx:beforeSwap htmx:before:swap
htmx:afterSwap htmx:after:swap
htmx:configRequest htmx:config:request

In addition, the following changes were made:

  • Most error events collapse into htmx:error. HTTP error responses fire htmx:response:error.
  • The htmx:xhr:* events are removed. htmx 4 uses fetch().
  • The htmx:validation:* events are removed in favor of native browser form validation.

The full table is in What’s New in htmx 4.

The command line upgrade checker flags old event names in hx-on attributes and in your JavaScript where it can find them.

History

History support has always been included in htmx, allowing you to implement back-button aware actions with simple attributes. In htmx 2, a cache in localStorage was used to snapshot pages for restoration. Unfortunately a large source of issues was that this snapshot could include DOM mutations by 3rd party JavaScript libraries. When the page was restored, those mutations remained but the underlying JavaScript logic was not.

htmx 4 does not cache pages in localStorage. On back navigation htmx re-fetches the page and swaps it into <body>, or into the [hx-history-elt] element if one is present. This allows 3rd party JavaScript libraries to “just work” in most cases and, with good request caching, is very fast.

If you want local caching instead, we now ship a very complete hx-history-cache extension that restores history from sessionStorage and is designed to integrate well with scripting solutions like Alpine.js, etc.

New Features

There are two big new features in htmx 4, both of which we are really excited about:

Morph Swaps

We now support morphing swaps out of the box with htmx. I created idiomorph and nearly included it in htmx 2.x but decided against it. In htmx 4, Michael has done great work improving on that algorithm and integrating it seamlessly into htmx.

<hx-partial>

Another major new feature is the <hx-partial> tag. This tag is similar to out-of-band swaps, but is much clearer when you want to do something beyond just replacing a single element with a new version of itself:

<hx-partial hx-target="#messages" hx-swap="beforeend">
    <div>New message</div>
</hx-partial>
<hx-partial hx-target="#count">
    <span>5</span>
</hx-partial>

Extensions

Much of the excitement in htmx 4 is in the extensions. Switching to fetch() internally let us rethink how extensions can and should work, and sparked the creation (and recreation) of many new extensions, for example:

  • hx-preload - preload content (e.g. on mouseover) to speed requests up
  • hx-download - native, fetch-based file downloads
  • hx-alpine-compat - smooths over compatibility issues between htmx and Alpine.js
  • hx-history-cache - caches history in sessionStorage, provides Alpine.js compatibility

Additionally, there are three new or updated streaming HTML extensions:

  • hx-sse streams over text/event-stream.
  • hx-ws streams and sends over WebSockets.
  • hx-multipart streams over multipart/mixed

Finally, we decided it was time to try our hand at our own small front-end scripting solution that tightly integrates with htmx. hx-live is inspired by Alpine.js, jQuery and hyperscript, and makes front end scripting pleasant and fun. It even supports what we are calling DOM-based, HATEOAS-friendly reactivity.

There is a new htmax.js bundle in the distribution which packages htmx with the most popular of these in a single file if you don’t want to think about which ones you want to pick.

Upgrading

For a complete upgrade guide see What’s New in htmx 4.

As mentioned earlier, we are providing an upgrade tool to help you:

$ npx htmx.org@4.0.0 upgrade-check -- ./templates

File extensions: .html, .php, .js, .ts, .jinja, .jinja2, .j2, .erb, .hbs
Use --ext to add more (e.g. --ext .vue --ext .svelte)

Scanning 1 file(s)...

Found 8 issue(s) in 1 of 1 file(s).

  • templates/index.html:1: [inheritance] hx-headers needs :inherited suffix (descendant on line 3 has hx-delete) (this looks like a CSRF token; without :inherited the header does not reach child elements and the server rejects the request)
  • templates/index.html:2: [inheritance] hx-target needs :inherited suffix (descendant on line 3 has hx-delete)
  • templates/index.html:2: [inheritance] hx-confirm needs :inherited suffix (descendant on line 3 has hx-delete)
  • templates/index.html:3: [renamed-attr] hx-disable -> rename to hx-ignore (hx-disable now means 'disable during request')
  • templates/index.html:4: [removed-attr] hx-vars is removed -> use hx-vals with js: prefix
  • templates/index.html:4: [removed-attr] hx-prompt is removed -> load the hx-prompt extension to keep the same syntax
  • templates/index.html:9: [old-event] old event name "htmx:afterRequest" -> "htmx:after:request"
  • templates/index.html:9: [old-api] htmx.addClass() is removed -> use element.classList.add()

We are also shipping an agent skill to assist in upgrading

Installing

htmx 4.0 can be installed via a package manager referencing version 4.0.0, or can be linked via a CDN:

<script src="https://unpkg.com/htmx.org@4.0.0/dist/htmx.min.js"></script>

or Downloaded

LLMs

Like it or not, a lot of people are using LLMs and we are providing the following skills files for LLMs:

  • htmx-guidance - core htmx skills for developing with htmx 4
  • htmx-debugging - diagnosing htmx issues during dev
  • htmx-extension-authoring - writing and debugging htmx 4 extensions
  • htmx-upgrade-from-htmx2 - migrating a codebase from htmx 2.x to 4.x

(Let’s leave aside if releasing a new version of a library in the LLM era is a good or bad thing!)

Conclusion

We hope you enjoy htmx 4. htmx 2 will continue to be supported indefinitely so don’t feel any pressure to upgrade.

I’d like to thank the following people for all their help with this release:

  • Michael West - Incredible teammate & grug-brained developer
  • Christian Tanul - Inspired htmx 4 & led the streaming & live extensions
  • Alex Petros - For keeping the ship on an even keel
  • Stephen Mitchell - The genius behind the game
  • Stu Kennedy - Our WebSockets expert
  • André Ahlert Jr. - Providing IDE & Editor Support
  • Dien Hoa Truong - For kicking the tires on early htmx 4 and helping fix many bugs

Upgrade Music

Wouldn’t be an htmx update without upgrade music: