The Xgemina architecture is a framework rather than a product or system. The conceptual distinction is important in that it drives design goals at every step. A framework enables creative solutions to problems that are limited only by the richness of the framework’s language.

A successful framework understands the requirements of its domain without imposing preset rules and conditions on how to approach the domain specific solutions. Examples are the type of edits required for a particular transaction. A product or system approach would offer a set of predefined edits (possibly controlled through a rich parameterization set or callback capabilities) from which a designer could choose.

No matter how rich the set of parameters, the product is still constrained by a finite set largely determined from its available code base. A framework does not assume to understand what edits are required. Only that edits are required (this is the domain knowledge). It expects the transaction to supply information detailing the type of edits it requires using the framework’s language (this allows the framework to self organize around a specific transaction without prior knowledge about the transaction). The job of the framework is to execute the edits as described by the transaction rather than actually editing the transaction.