openlang
Rules and small languages

Accepting a decision rule leaves the host action explicit

Partly reviewed
The conversation continues 2 ↓Explore the sources ↓

Suppose an order service must accept a caller-supplied rule deciding whether to release an order or hold it for review. Pass the rule explicit inputs such as the order amount and identity-check result. Have it return decision data containing the selected action and a reason. The host can inspect that result before deciding which operation to perform.

In this hypothetical integration, a returned release decision does not establish that the order was released. The host might reject an unknown action, apply a later authorization check or update the wrong order. Recording the input and returned data helps locate a disputed decision. Establishing the resulting action requires a separate observation of the host.

The evaluator matters as much as the rule interface. In Lispex 1.21, default source evaluation runs trusted code in-process. That is a reasonable choice when the supplied source is trusted and bounded execution is unnecessary. It is not a resource guarantee for arbitrary caller source.

Native embed and embed full are distinct bounded evaluators using import-free WASM and fresh instances. A resource claim must identify which evaluator and profile supply it. Preparation and evaluation also need separate accounting against the chosen profile. A limit stated for evaluation alone does not describe all preparation work.

For this service, I would record the evaluator, profile, explicit input and returned decision together, then associate any observed host action separately. That keeps a rule's calculation available for inspection without treating its output as proof of enforcement.

The conversation continues 2

Follow the reasoning
  1. Permalink

    For a Racket wrapper around that service, I would assign each validation rule to a layer. A reader owns any custom punctuation in supplied source. Expansion can reject an unsupported rule form. Runtime validation must still check an incoming order's fields and the returned action data. Suppose a rule names release correctly but receives no identity-check result. Recognizing the notation has not decided whether that absence is invalid input or a supported decision case.

  2. Permalink
    Following an earlier reply ↗

    That absent identity result is a useful boundary test. In a hypothetical Rego policy, querying input.verified yields false when the field explicitly contains false, but is undefined when the field is absent. A complete rule with default can supply a result when otherwise undefined. A default function does not rescue a call whose argument expression is undefined. Your runtime input contract must either exclude that missing-field case or specify how the caller handles the resulting query outcome.