Blaze Advisor (SRL)

Structured Rules Language (SRL) is the rule authoring language of Blaze Advisor, a business rules management system (BRMS) whose Java lineage dates to Neuron Data’s Elements Advisor in 1998 and which took the Blaze Advisor name in 1999. It is a declarative language in the production-rule tradition — you write what the policy is, not when to evaluate it — but wrapped in a deliberately English-like syntax so that an underwriter, actuary, or credit analyst can read a rule and tell you whether it is right.

That last goal is the whole point. SRL exists because a certain class of software logic — who qualifies for this loan, which claim gets referred to a human, what fee applies to this vehicle registration — changes on the business’s schedule rather than the engineering team’s, and because regulators increasingly demand that such decisions be explainable. SRL is the artifact of an industry-wide attempt in the late 1990s to lift that logic out of Java and COBOL and into a place where the people accountable for the policy could see it.

History and Origins

The lineage starts well before Blaze Advisor. Neuron Data was founded in June 1985 by Alain Rappaport, Patrick Perez, and Jean-Marie Chauvet, and its first product, Nexpert, was a C-based expert system shell offering both backward-chaining goal pursuit and forward-chaining, data-driven inference. Through the late 1980s and early 1990s Neuron Data was best known in two markets at once: expert systems, and cross-platform GUI toolkits (its Open Interface product was named “Best Cross-Platform Toolkit” by X Journal in 1995).

Java changed the company’s trajectory. Neuron Data acquired Microline Software in January 1997 to bolster its Java expertise, and by 1998 — with new management under CEO Thomas F. Kelly — it had moved its rules engine onto the JVM, selling it as Elements Advisor. Where Nexpert had been an expert-system shell for AI practitioners, this product was pitched at enterprise developers building transactional systems — the same inference heritage, repackaged as infrastructure for business policy. The Blaze Advisor name arrived with the company’s own rebranding: Neuron Data renamed itself Blaze Software in August 1999 and announced the Blaze Advisor Solutions Suite that autumn.

What followed was one of the more eventful ownership histories in enterprise software. Blaze Software went public on 23 March 2000 (Nasdaq: BLZE), pricing above its stated range. It agreed that June to be acquired by the German internet-security firm Brokat, a deal completed in September 2000. When Brokat collapsed in the dot-com aftermath, HNC Software bought the Blaze Advisor business unit’s assets on 15 August 2001 for a reported US$20 million in cash. Less than a year later, on 5 August 2002, Fair Isaac completed its merger with HNC in a transaction valued at approximately US$810 million — and Blaze Advisor found the home it still occupies, as a FICO product.

Four owners in four years is usually a death sentence for a developer tool. Blaze Advisor survived because Fair Isaac needed it: the company’s business is automated decisions, and a rules engine it owned outright could be embedded in every analytic product it shipped.

Design Philosophy

SRL is built around a small number of convictions, most of them aimed squarely at the gap between the person who writes the rule and the person who owns the policy.

Rules are the unit of thought, not the unit of control flow. A rule declares a condition and the actions that follow from it. The engine — not the author — decides when a rule fires, how many times, and in what order relative to other rules, using forward-chaining inference over a working set of business objects.

Readability is a language feature. SRL notoriously supports several ways to express the same navigation through an object graph, so that different audiences can each read comfortably:

All three mean the same thing. A developer can write dot notation; a business analyst reading the same repository sees prose. This is unusual — most DSLs pick one surface syntax and enforce it — and it is the design decision most people remember about SRL.

The rule is only one of several faces on the same logic. Rules in Blaze Advisor can be authored and viewed as SRL text, but also as decision tables, decision trees, scorecards, rule flows, and decision graphs. SRL has an associated XML representation used to define templates for these metaphors. A pricing matrix that a developer would write as fifteen rules is often better shown to an analyst as one table — and in Blaze Advisor it is the same underlying artifact either way.

Business users edit; developers build the editor. Rather than exposing the full language to non-programmers, Blaze Advisor developers construct rule maintenance applications (RMAs) from templates, so an analyst gets a web form with exactly the degrees of freedom the policy permits. Later releases added freeform editing and point-and-click formula builders alongside the template-driven approach.

Key Features

A rule in SRL has a shape close to what you would guess from its description:

rule GoldCustomerDiscount priority 10 is
  if the category of the customer is "gold"
    and the total of the shoppingCart > 100.00
  then
    apply a 10% discount to the shoppingCart of the customer

The priority clause (also written at) sets rule precedence, with higher numbers favoured when several rules are eligible to fire; an else clause is optional. (Examples here are illustrative of the documented syntax rather than transcriptions of a specific product manual — SRL admits several equivalent surface forms.)

Beyond the basic rule form, SRL is a real language rather than a configuration format:

• Rulesets group rules by task — customer profiling rules in one, product selection rules in another — so that a decision service invokes a coherent bundle rather than a global soup of rules.
• Rule flows sequence rulesets, tables, trees, and scorecards into an orchestrated decision, with branching and iteration between stages.
• Object orientation: classes, objects, inheritance, and methods, plus direct binding to existing Java or .NET object models so rules operate on the application’s own domain objects rather than a copy.
• Business-domain primitives, including types for monetary values — a detail that matters more than it sounds when the alternative is floating-point currency.
• Imperative escape hatches: loops, conditionals, functions, and database access, for the parts of a decision that genuinely are procedural.
• Model import: Predictive Model Markup Language (PMML) files can be imported, and SAS data steps converted into SRL — reflecting FICO’s world, where a statistical scorecard and a policy rule are two halves of one decision.

The Rete III engine

Production-rule systems live or die on match performance: naively re-testing every rule against every fact on every change is quadratic misery. The classic answer is Charles Forgy’s Rete algorithm, which caches partial matches in a network so that only the consequences of a change are recomputed.

In September 2005 Fair Isaac acquired assets of RulesPower, Inc., co-founded by Forgy himself, and with them the Rete III execution engine; Blaze Advisor 6.1, released in January 2006, was the first version to integrate it. Fair Isaac positioned Rete III for “data- and rules-intensive” organisations where execution performance is critical. It is worth being precise about what that does and does not tell you: the vendor’s claims of faster, more efficient execution of complex, high-volume rule sets were marketing statements, not published benchmark results with a stated workload, hardware configuration, and baseline. Anyone sizing a Blaze deployment has always had to benchmark their own rule set — the performance of a Rete network depends enormously on rule and fact-pattern shape.

Evolution

Blaze Advisor’s release history tracks the industry’s shifting idea of who a BRMS is for.

The 6.x line (6.0 in May 2005 through 6.6 in December 2008) was about scale and governance: rule repositories segmented per business domain with accountable owners, query and update tooling across the repository, version and project comparison, CVS and ClearCase integration, rule verification that flags overlapping ranges and unreachable decision-tree nodes, and operational plumbing such as Log4J logging and JMX/MOM monitoring of deployed decision services. This was the era in which “we have a rules engine” gave way to “we have hundreds of thousands of rules and need to manage them.”

Blaze Advisor 7, generally available 1 November 2011, moved the Java product into the Eclipse IDE and introduced the Decision Graph — a visual metaphor for decision trees intended to keep very large rule sets comprehensible. The 7.x line has continued through the 2010s and into the 2020s — FICO’s community site carries release announcements for 7.6, 7.7, and 7.8, the most recent version documented there — with Blaze Advisor increasingly presented as one component of FICO’s Decision Management Suite alongside the browser-based Decision Modeler.

The language itself, though, has been essentially stable for a long time. SRL in a 7.x repository is recognisably the SRL of the mid-2000s. That stability is exactly why the language reads as dormant even though the product is not: FICO ships and supports Blaze Advisor commercially, but nobody is adding paradigms to SRL.

Portability was always multi-platform in an enterprise sense — Java and .NET editions, a COBOL edition for mainframe deployment, deployment as web services and Java EE components — but the specific operating systems, JDKs, and application servers supported vary by release and are documented only in FICO’s per-version platform support matrices. Anything more precise than “Java, .NET, and COBOL editions have existed” should be checked against the release you actually have.

Current Relevance

Blaze Advisor occupies an odd position: commercially alive, intellectually finished, and largely invisible.

It remains a FICO product, listed and supported, and it is one of the small handful of BRMS platforms — with IBM Operational Decision Manager (the former ILOG JRules), Red Hat Decision Manager (Drools), and Pegasystems — that carried enterprise rules management from the 1990s into the present. Its deployments skew heavily toward financial services, banking, and insurance: third-party technology-tracking profiles of the sort published by appsruntheworld and enlyft reportedly put information technology and services, financial services, banking, and insurance at the top of its user base — figures derived from vendor and web-signal data rather than from FICO disclosures, but consistent with what you would expect of a product owned by the company behind the FICO score.

It is also invisible in a way few languages are. Blaze Advisor is embedded inside FICO’s own applications — Falcon Fraud Manager among them — so SRL rules are evaluating card transactions at institutions that have never heard the name. There is no open-source implementation, no package ecosystem, no Docker image, and essentially no presence on GitHub or Stack Overflow. Learning it means a commercial licence, FICO’s community site, and vendor training. The living community is a labour market — “Blaze Advisor developer” is a recognised contract role in US banking and insurance — rather than a public commons.

Where new work goes today is mostly elsewhere: to FICO’s own Decision Modeler and cloud platform, to DMN (Decision Model and Notation) as an interchange standard, and to open engines like Drools. But the installed base is large, old, and load-bearing, which in enterprise software is a very long life expectancy.

Why It Matters

SRL is worth studying for three reasons that outlast the product.

It is a serious attempt at a genuinely readable DSL. Most “English-like” languages are a thin veneer over programmer syntax that fools nobody (COBOL’s ADD 1 TO COUNTER being the ancestral case). SRL went further by admitting multiple equivalent surface forms for the same semantics, letting each audience read the language in the register it prefers. Whether that succeeded is debatable — polysemy has costs in tooling and in code review — but it was a real experiment in a question DSL designers still argue about.

It carried the Rete algorithm into commercial infrastructure. The line runs from Forgy’s OPS5-era work through Neuron Data’s Nexpert shell, and then — via the 2005 RulesPower acquisition that brought Forgy’s Rete III engine into version 6.1 — back into the same product. Blaze Advisor is one of the clearest cases of 1970s and 1980s AI research surviving the AI winter by becoming unglamorous plumbing. The expert systems boom did not die; it got a job in a bank.

It made the case for policy-as-data. The premise that business logic should live in a governed, versioned, queryable repository owned by the business rather than compiled into an application is now conventional wisdom, visible in feature-flag systems, policy engines like OPA, and the DMN standard. Blaze Advisor argued that case in 1998, when it was contentious, and it built the auditing, verification, and templating machinery to back it up. The rules-engine category it helped establish is why “who is allowed to change this logic, and can we prove what it did last Tuesday?” is a question modern systems are expected to answer.