Guided Rule Authoring

L2Proxy includes a local Rule Authoring Workbench that helps OT engineers move from an operational requirement to a valid protocol-aware expression without memorizing parser abbreviations or helper APIs.

Industrial outcome: create and review precise rules faster, with fewer typing, field-selection, value, ordering, and expression errors before deployment.

This chapter contains the workbench capabilities and representative workflow for offline and printed review. The customer does not need access to a demonstration address to evaluate the authoring experience described here.

More than a text editor

The workbench brings the Rule Engine vocabulary and the l2proxy-dissector field catalog into one guided workflow:

Authoring capability	Practical value
Contextual autocomplete	Suggests functions, protocol layers, fields, operators, values, indexes, and connectors at the current cursor position
Protocol-aware filtering	Narrows field suggestions after a protocol layer is selected
Searchable field tree	Lets an engineer find a decoded item by industrial name or parser abbreviation and insert it into the expression
Typed field access	Shows whether a value is a string, integer, float, Boolean, or repeated field and recommends a compatible accessor
Value hints	Presents known function codes, message types, and other enumerated values with readable labels
Syntax and context guidance	Shows required preceding fields, valid layers, and parser-derived branch conditions
Helper explorer	Documents helper signature, arguments, return type, role, category, example, semantics, and missing-value behavior
Metadata guidance	Distinguishes policy predicates from typed accessors intended for structured rule-match evidence
Live validation	Combines catalog lint with compilation against the L2Proxy Rule Engine expression environment
Industrial rule library	Provides searchable templates and learning paths that can be loaded into the editor and adapted

The editor uses Monaco—the editing component familiar from VS Code—and is delivered with local assets. Rule content and catalogs do not need to be sent to a public cloud service for authoring or validation.

Parser-aligned discovery

The catalog generator scans the actual l2proxy-dissector source. It records field names, abbreviations, value types, compatible accessors, known values, repeatable fields, layer requirements, ordering hints, and parser contexts. This reduces drift between documentation and the parser version deployed with the product.

The currently generated catalog contains 1,602 fields across 28 protocol layers. It includes full parser-field coverage reported by the generator for DNP3, IEC 60870-5-104, Modbus, S7comm, OPC UA, and other decoded layers. Parser-field availability does not, by itself, imply that every protocol has the same semantic-helper or enforcement maturity; see Capability Status.

Guided expression workflow

An engineer can build a condition incrementally:

Figure — Guided rule authoring remains traceable from expression to mapped enforcement.

HasLayer("dnp3")
        ↓ choose a DNP3 helper
dnp3.IsRequest()
        ↓ choose the operation and target predicate
dnp3.IsDirectOperate() && dnp3.HasCanonicalEndpoints()
        ↓ compile with the Rule Engine
valid expression

The resulting condition can be placed in a reviewed YAML policy:

- name: review-direct-operate
  order: 20
  condition: >
    dnp3.IsDNP3() && dnp3.IsRequest() &&
    dnp3.IsDirectOperate() && dnp3.HasCanonicalEndpoints()
  action: log
  log: true
  meta:
    policy: '"direct_operate_review"'
    master: 'dnp3.Master()'
    outstation: 'dnp3.Outstation()'
    targets: 'dnp3.ControlTargetCount()'

meta values use the same typed expression environment as conditions. They are evaluated only for a matching rule when logging is enabled, allowing useful evidence without adding metadata work to every packet.

Built-in industrial starting points

The current library contains 288 templates organized by protocol, operational topic, and difficulty:

Protocol	Current templates	Example topics
DNP3	82	reads, controls, points, quality, files, secure authentication, and advanced objects
IEC 60870-5-104	55	ASDU direction, commands, measurements, quality, time tags, and control workflow
Modbus	62	function codes, reads, writes, addresses, values, exceptions, and transaction behavior
S7comm	89	session and message structure, read/write operations, blocks, diagnostics, and control-related fields

Templates are starting points, not site policy. Device roles, addresses, point or register maps, engineering permissions, process limits, and final accept or drop decisions remain customer-specific and must be validated with representative traffic.

DNP3 semantic guidance

DNP3 currently provides the deepest helper authoring experience. The workbench exposes more than 200 flat, modular, and metadata-oriented helper entries covering traffic role, function codes, device addresses, objects and points, values, quality, controls, IIN, file transfer, secure authentication, and other protocol details.

For each helper, the engineer can inspect its signature, typed arguments and return value, industrial meaning, example, request/response semantics, fields read, and missing-data behavior. This is particularly useful when selecting safe Boolean predicates for condition and simple-value accessors for meta.

Validation before rollout

The workbench checks complementary classes of error:

1. Catalog checks identify unknown abbreviations, incompatible accessors, incomplete syntax, and ordering or context concerns.
2. Engine compilation verifies that the expression is accepted by L2Proxy's typed expression environment.
3. Traffic validation remains the deployment gate: run the complete YAML rule against representative PCAPs and normal, abnormal, retry, timeout, and malformed cases.

Autocomplete and compile success improve authoring quality; they do not prove that a customer's operational policy is safe. Inline blocking still requires OT ownership, change control, test evidence, and rollback planning.

Why this is a practical differentiator

A protocol-aware engine is most useful when engineers can discover its vocabulary and turn process intent into reviewable policy quickly. By generating knowledge from the deployed parser, explaining helpers in industrial terms, offering reusable examples, and validating expressions locally, L2Proxy shortens the path from decoded traffic to an auditable rule while preserving customer control over the final policy.