Decision sheets: the rules travel with the data

Spectrum data moves between systems, but the rules for using it stay buried in each system's code, and when two nodes make different calls nobody can say why. Decision sheets put the rules in the record, in a form a spectrum manager can read.

What a decision sheet looks like

A decision sheet is a table. The left columns are the conditions, the right columns are the answers, and each row is one rule. If more than one row matches, the sheet's policy says which one wins. The cells use a small standard notation, explained below the example. In NEMESynth-EMSO the PACE triggers, alternate-frequency choices, priority rules, compliance checks and import rules are all sheets.

Here's the sheet that decides when a net moves down its PACE plan in the Halcyon exercise. It runs whenever something changes for a net: the power drops, a fiber is cut, a link budget stops closing, someone starts jamming the band.

Part of the comm plan PACE sheet. The first matching row wins; rows 6, 7 and 9 are left out here. A second table on the same sheet decides who gets told. Going to emergency always notifies the spectrum manager and net control, and any move on a safety-of-life or medical net notifies the spectrum manager.

Reading the cells: S-FEEL

Each cell holds a short test or value written in S-FEEL (Simple Friendly Enough Expression Language), the cell language of the OMG Decision Model and Notation (DMN) standard. It has only values, comparisons, ranges, lists and "not", so you can read a sheet, check it and change it yourself. Because it's a published standard, a rule means the same thing in any tool that supports DMN.

So row 3 reads: if the net is on its primary and the link margin is short, go to the alternate and log "primary margin short". Row 10 catches everything else and holds.

Why put the sheets in SFAFx

Draft §3.7 of the SFAFx standard makes a sheet an SFAFx record, with its inputs and outputs, tables, S-FEEL cells, worked examples, validity checks and the order its tables run in. A set then carries its rules and its data under one hash.

GRIPS, the engine underneath

GRIPS (Goose Rule-based Integrated Production System) is our port of the CLIPS 7.0 rule engine to the Goose language, built for this kind of work. Since 29 October 2026 NEMESynth-EMSO runs its decision sheets on GRIPS directly, and keeps CLIPS for the web build.

Rules over the live picture

GRIPS and the application share one in-memory database. Once a change is final it gets published. Incoming readings become facts. A command from another system becomes a fact inside a transaction: it's answered if the transaction commits, and refused with a reason if it rolls back. Spotting energy where nothing's authorized is just an ordinary rule:

(defrule unauthorized-energy
  (observation (freq-hz ?f) (power-dbm ?p&:(> ?p -90)) (site ?s) (at ?t))
  (not (assignment (lo-hz ?lo&:(<= ?lo ?f)) (hi-hz ?hi&:(>= ?hi ?f))
                   (area ?a&:(within ?s ?a)) (in-force-at ?t)))
  =>
  (assert (anomaly (freq-hz ?f) (site ?s) (at ?t))))

An example. It's part of the sensor-reading work that is Planned.

Goals over the rules

Sheets are steps toward a goal, alongside commands and the optimizer. Each goal says what counts as done and what each step costs. The scheduler picks the steps that get there, and you approve the plan.