Gensym G2

Gensym G2 is a commercial real-time, rule-based expert system development environment created by Gensym Corporation in Cambridge, Massachusetts. Founded in 1986 by Lowell B. Hawkinson and colleagues with roots in the MIT AI Lab and Lisp Machine Inc., Gensym demonstrated a G2 prototype in 1987 and released the product commercially around 1988. G2 was designed to do something that the earlier generation of expert-system tools — KEE, ART, and OPS5-based systems — generally did not: run online, against live data, in continuous industrial processes, where rules must fire on time-stamped sensor data and reasoning must keep up with the physical system being monitored.

Unlike a conventional general-purpose programming language, G2 is best described as a knowledge-based application platform with several intertwined languages: a structured natural-language rule syntax (“if the temperature of any tank T is greater than 100 then …”), an object-oriented knowledge base of classes and instances with inheritance, a graphical schematic builder in which applications are assembled as connected diagrams of objects, and a procedural sub-language for procedures, functions, and methods. A G2 application is typically authored in the G2 IDE rather than as plain text files, and its source of truth is the knowledge base rather than a directory of source code.

History & Origins

Gensym Corporation was founded in 1986 by Lowell B. Hawkinson and a small group of co-founders, including Robert L. Moore, several of whom had worked at Lisp Machine Inc. (LMI) and the MIT AI Lab. The founders’ premise was that the first commercial generation of expert-system tools, which had focused on offline knowledge engineering for diagnostic and configuration problems, was poorly matched to the needs of industrial process operators. Refineries, chemical plants, and power stations did not want a system that answered questions in batch; they wanted a system that watched the process continuously, integrated with the plant’s data sources, fired rules as conditions changed, and recommended or automated actions.

A G2 prototype was publicly demonstrated in 1987, and the system was released commercially around 1988. Early academic publications by Moore, Hawkinson and colleagues described G2 as a forward-chaining real-time expert system with a structured natural-language rule syntax, an object-oriented knowledge base, and integration mechanisms for live data sources. From the outset, the system was implemented in Common Lisp on workstation-class machines and packaged for the Unix workstations and proprietary minicomputers that dominated industrial computing at the time.

Through the 1990s, Gensym layered a series of products on top of the G2 core: the G2 Diagnostic Assistant (GDA) for block-diagram diagnostic applications, NeurOn-Line for embedding neural networks alongside rule-based reasoning, Optegrity for operations and process optimization, Telewindows for multi-user client/server thin-client access, and the G2 Gateway / G2 Standard Interface (GSI) for bridging G2 applications to external systems written in C and C++. By the early 2000s, G2 had become the standard reference for real-time expert systems in the process industries, with deployments across refining, chemicals, pulp & paper, power, and aerospace.

In 2013, Versata Enterprises (part of ESW Capital) acquired Ignite Technologies, the company that would become the corporate home of the Gensym product line. In 2015, Gensym Corporation and IgniteTech publicly formalized their affiliation, and the product moved to year-based release versioning under the IgniteTech / Gensym brand. G2 continues to be maintained and sold; a recent release surfaced in vendor materials as G2 2024.1, and IgniteTech has also announced a newer cross-platform successor called G3, positioned as an AI-native evolution of the G2 approach.

Design Philosophy

Several principles distinguish G2 from both earlier expert-system tools and conventional programming languages:

• Real-time first. G2 was designed from the beginning to run online against live data, with a rule engine that scans rules against time-stamped sensor values, handles latency and missing data, and reasons about how stale a given value is.
• Structured natural-language rules. Rules are written in a constrained English-like syntax. The classic example — “if the temperature of any tank T is greater than 100 then conclude that T is overheated” — is intended to be readable and reviewable by domain engineers (chemical engineers, process operators) rather than only by programmers.
• Object-oriented knowledge base. G2 organizes the application’s world as a set of classes with inheritance and instances with attributes, into which rules and procedures reach to read and write values. The same class definitions drive both reasoning and the graphical schematic.
• Graphical schematic programming. A G2 application is largely assembled by drawing diagrams: instances of classes are placed on workspaces, connected with relationships and connections, and parameterized through dialog boxes. The diagram is not a separate documentation artifact — it is part of the application.
• Concurrency and time as first-class concepts. Rules can be scanned periodically, triggered by changes, or focused on specific objects; data can be historized; and the system can reason explicitly about how recent or stale a value is, an essential property for any system that monitors a physical process.
• Integration with external systems. G2 was always intended to live inside a larger plant or operations environment. The G2 Standard Interface (GSI), G2 Gateway, OPC bridges, JMSLink, and ActiveXLink were introduced over time to connect the knowledge base to historians, DCS systems, message buses, and other operational software.

Language Overview

A G2 knowledge base typically contains four kinds of definitions:

• Class definitions, describing the structure of objects in the domain (a tank, a pump, an alarm).
• Instances and connections, the actual objects in the application and the relationships among them, usually arranged on graphical workspaces.
• Rules, written in the structured natural-language syntax, that perform monitoring, diagnosis, and control.
• Procedures, methods, and functions, written in a more conventional procedural sub-language, used when iteration, branching, or imperative side effects are easier to express than as rules.

A G2 rule, in its characteristic syntax, reads more like an English sentence than a line of code. A simplified example, in the spirit of G2’s published documentation:

if the temperature of any tank T is greater than 100
then conclude that T is overheated
     and inform the operator that "Tank " followed by the name of T
                                  followed by " is overheated"

The rule quantifies over instances of the tank class (any tank T), reads an attribute (the temperature of T), and, when the condition holds, performs actions: setting a derived property on T and posting a message to the operator. Rules can also be scoped — focused on particular objects, scanned at particular intervals, or invoked on specific events — which is how G2 controls the cost of rule scanning in a live application.

The procedural sub-language is used for cases where rule-based expression is awkward, such as walking through a list, doing arithmetic-heavy computations, or invoking external systems. Procedures use familiar constructs (if/else, for, while, local variables, calls to other procedures) and operate over the same knowledge base of objects and attributes that the rules see.

Architecture

A G2 application is typically structured around three layers:

1. The G2 inference engine and runtime, which holds the knowledge base in memory, scans rules, executes procedures, manages time-stamped data, and drives the graphical interface.
2. Integration components — historically the G2 Standard Interface (GSI) and the G2 Gateway, later augmented with OPC, JMS, and ActiveX bridges — which connect the knowledge base to external data sources such as plant historians, distributed control systems, and message buses.
3. Client access via the G2 IDE for development and Telewindows for runtime multi-user access, with operators and engineers connecting to a running G2 application from thin clients.

In production, a G2 application typically runs on a server, ingests real-time data through GSI/Gateway connections, fires rules against that data, updates its object model, and presents the resulting state to operators through schematic displays.

Platforms

Historically, G2 ran on a wide range of Unix workstations and minicomputers — including Sun Solaris (SPARC), HP-UX, IBM AIX, DEC VMS/Alpha, and SGI IRIX — and on Windows NT and successor server editions. The specific list of supported platforms has changed across major releases, and for any particular version the authoritative source is the corresponding Gensym / IgniteTech release notes; recent releases under the IgniteTech / Gensym brand are documented as running on current Windows Server and Linux distributions.

Evolution

Across more than three decades of releases, G2 has evolved along several axes while preserving its core model of real-time, rule-based, object-oriented reasoning over a graphical knowledge base:

• Core engine and language. The rule syntax and object model have remained recognizable from the earliest releases; successive versions have added expressiveness in rules and procedures, richer class facilities, and more sophisticated control over rule scanning and concurrency.
• Add-on products. GDA, NeurOn-Line, Optegrity, ReThink (business-process modeling), and e-SCOR (supply-chain modeling) extended the G2 core into specific application areas.
• Connectivity. Successive integration products — GSI, G2 Gateway, OPC bridges, JMSLink, ActiveXLink — connected G2 to the data sources and message buses that plant and operations environments came to standardize on.
• Deployment model. Telewindows introduced a multi-user thin-client model in the late 1990s, allowing operators and engineers to share a running G2 application from multiple workstations.
• Ownership and packaging. Under IgniteTech, G2 moved to year-based release versioning, and the company has announced a newer G3 platform positioned as an AI-native, cross-platform successor.

Current Relevance

G2 is a niche but commercially active platform. Its strongest concentration of use is in continuous-process industries — refining, chemicals, pulp & paper, power, pharmaceuticals — and in aerospace systems-health applications, where its real-time orientation and the long lives of installed applications give it a durable footprint. NASA’s documentation of an Integrated Systems Health Management toolkit built on G2 is one publicly visible example of this kind of long-lived deployment.

In greenfield projects, real-time monitoring and diagnosis are now more often built on a combination of stream-processing infrastructure, time-series databases, custom rule engines, and machine-learning models, rather than on a single proprietary expert-system platform. G2’s niche today is largely the one it has occupied for decades: existing industrial applications whose knowledge bases represent years of captured operating experience, and new applications by customers who value the combination of real-time rule scanning, graphical schematic programming, and the structured natural-language rule syntax.

Why It Matters

G2 is one of the longest-lived examples of a commercial real-time expert system platform. The first generation of commercial expert-system tools in the 1980s — KEE from IntelliCorp, ART from Inference Corporation, OPS5 and its descendants — were largely designed for offline knowledge engineering, and most of them either disappeared or were absorbed into other product lines as the AI winter took hold in the early 1990s. G2 survived for a specific reason: it was designed not for the laboratory but for the control room, with real-time data, time-stamped reasoning, graphical schematic programming, and structured natural-language rules aimed at domain engineers rather than only at AI specialists.

The platform is also a useful artifact of an alternative path in programming-language design — one in which the primary expressive medium is not a textual source file but a graphical schematic backed by a knowledge base of typed objects and structured rules. That model is rare among the languages that dominate modern programming, but it remains a defining example of what a domain-specific environment for real-time industrial reasoning can look like when language design, interactive graphics, and integration with the physical world are taken seriously as a single problem.