SESL Product Overview

Using SESL with an LLM

SESL integrates with ChatGPT, Claude, and other LLMs via the Model Context Protocol (MCP), a standardized interface for AI tools. When you connect SESL as an MCP server, the LLM can invoke SESL commands directly: loading models, adding rules, editing scenarios, running inference, and retrieving results. The LLM acts as a conversational interface for SESL, translating natural language requests ("add a rule that checks age", "run this scenario") into SESL commands. Critically, SESL models execute on SESL's own server, not inside the LLM. The LLM receives only the final results (facts, traces, errors), ensuring that decision logic remains deterministic and auditable. This architecture lets you leverage LLMs for rule drafting, model exploration, and natural language queries while maintaining SESL's strict execution guarantees.

Generate rules

Build a scenario

Evaluate results

Structure of a SESL program

A SESL model is a structured YAML file that defines rules, facts (scenarios), and optional constants. Providing a simple structure for allowing decision logic, inputs, and shared values to stay organised and easy to maintain.

The rules section contains each rule’s name, conditions (if), actions (then), optional LET formulas, priorities, explanations, and an optional stop flag; rules fire in priority order using forward-chaining so one rule’s output can influence another.

The facts section provides one or more scenarios—each with input data, an optional name, a result object (where outputs are written), and automatically injected constants. The constants section stores shared configuration values accessible to all rules. Finally, all outputs are written into the scenario’s result object, which may also include engine metadata such as starting facts, LET dumps, monitoring traces, and support tracking, keeping all conclusions and debugging information in one place.

const:
  MIN_ADULT_AGE: 16

rules:

  - rule: check_age
    priority: 10
    if:
      - applicant.age < MIN_ADULT_AGE
    then:
      result.eligible: false
    because: "Applicant is under the required adult age."

  - rule: check_nationality
    priority: 20
    if:
      - applicant.nationality != "British"
    then:
      result.eligible: false
    because: "Applicant is not a British national."

  - rule: check_previous_passport
    priority: 30
    if:
      - applicant.has_previous_passport == true
    then:
      result.eligible: false
    because: "Applicant has already had a UK passport."

  - rule: verify_documents
    priority: 40
    if:
      all:
        - docs.birth_certificate == true
        - docs.identity_evidence == true
        - docs.photo_ok == true
    then:
      facts.docs_ok: true
    because: "All required documents are provided."

  - rule: final_decision
    priority: 100
    if:
      - facts.docs_ok == true
      - result.eligible != false
    then:
      result.eligible: true
    because: "All requirements satisfied."

facts:
  - name: Scenario1
    applicant:
      age: 22
      nationality: "British"
      has_previous_passport: false
    docs:
      birth_certificate: true
      identity_evidence: true
      photo_ok: true

          

In summary, a SESL model cleanly separates rule logic, scenario data, and shared constants while providing a dedicated result structure for outputs. This organisation makes SESL models easy to read, easy to test, and highly maintainable, while supporting powerful reasoning features like LET formulas, priority handling, and truth-maintenance tracking.

How SESL processes rules

The rules engine starts by loading the rules you wrote in YAML. Each rule has conditions (the “IF”), actions (the “THEN”), optional LET formulas, and a priority. The engine turns each rule’s conditions into a logic structure (like a tree of AND/OR/NOT blocks) so it can evaluate them quickly and consistently. LET expressions are also prepared in advance so the engine can compute temporary values for each rule during processing.

When the engine runs a scenario, it enters a loop that keeps applying rules until nothing changes anymore. For each rule, the engine first calculates the LET values for that rule, then tests whether the rule’s conditions are true using the current facts. If the conditions match, the rule is allowed to fire. The engine also keeps track of which parts of the data changed so it doesn’t waste time re-evaluating conditions unnecessarily.

If a rule fires, the engine performs its actions—which means it writes new values into the scenario facts (usually inside the result section). If a higher-priority rule has already written to the same output, the lower-priority rule is skipped for that specific value. The engine also uses a simple “truth maintenance system” to record which rules are supporting each result; if a rule later stops being true, the results depending on that rule can automatically be removed.

The engine keeps looping through all rules until it reaches a stable state—meaning no rule changed anything during that iteration. When this happens, it stops and returns the final results. If a monitor is turned on, the engine also produces a step-by-step explanation showing which rules were evaluated, which ones fired, which actions were taken, and why. This makes it easy to understand exactly how the engine arrived at its final answer.

The engine uses a forward-chaining approach where it repeatedly applies rules to the current facts until no more changes occur, gradually building up conclusions step by step. Unlike a RETE engine—which builds an optimized network of condition nodes for extremely fast pattern-matching across large rule sets—this engine uses a simpler but more transparent evaluation cycle: each rule is checked in priority order, with dependency tracking to avoid unnecessary re-evaluation, LET expressions for per-rule computed values, and a truth-maintenance system to ensure results remain logically consistent when rules stop applying. This design trades RETE’s heavy optimisation structures for clarity, easier debugging, and deterministic behaviour, while still achieving efficient re-runs by only re-evaluating conditions linked to recently changed parts of the fact set.