When talking about Photo Supreme, the name usually refers to the application: the interface used to organize images and work with a catalog. Architecturally, Photo Supreme has long moved toward an important distinction. Underneath the application sits the collection of capabilities that make Photo Supreme what it is: working with the catalog, managing metadata, searching, organizing assets, handling catalog labels, and applying the rules that connect those things. Those capabilities belong to the Photo Supreme Framework.

More than reusable code

Cataloging an image isn't fundamentally a user-interface operation. Neither is searching a catalog or assigning a catalog label. The interface initiates those operations, but the knowledge required to perform them lives in the framework. The framework knows how Photo Supreme works. The application knows how to interact with it.

This isn't simply about code reuse. The framework contains the rules and decisions that define how Photo Supreme behaves. It is the place where catalog operations, metadata decisions, search logic, and classification behavior are implemented consistently.

What is actually being shared is behavior.

A cataloging rule doesn't belong to the desktop application simply because that is where its result becomes visible. It belongs to the framework. The desktop application is therefore a consumer of Photo Supreme's behavior rather than its owner.

One engine, different applications

That distinction has an important consequence. If the behavior that defines Photo Supreme is independent of the desktop application, the desktop application doesn't have to be its only consumer.

Different applications can use the same framework. They don't need to look alike or even run in the same environment. What they share is the part that matters: the same cataloging behavior.

In that sense, the framework acts as an engine. The Photo Supreme desktop application is one product built on that engine: It doesn't have to be the only one.

Improvements flow both ways

Sharing behavior also means that improvements aren't confined to one product. A correction or new capability added to the framework can benefit every product built on it. Likewise, requirements encountered by another product can improve the framework and, as a consequence, Photo Supreme itself.

Development can flow in both directions. The products don't have to replace one another. They can evolve alongside each other while strengthening their shared foundation. They can be siblings.

Photo Supreme, underneath Photo Supreme

For most of Photo Supreme's history, this distinction has remained largely invisible. There is Photo Supreme the application: the desktop product and interface. And there is the Photo Supreme Framework: the engine that defines the cataloging behavior on which that application is built.

An architectural decision made from the beginning now makes something more possible:

New things can be built with Photo Supreme without having to build Photo Supreme again.