Writing Decision Rules

See it run

(define (refund-decision days opened?)
  (if (and (<= days 14) (not opened?))
      '(decision allow)
      '(decision deny outside-refund-window)))
(refund-decision 9 #f)

(decision allow)

Walk through the pattern

1. Name every input. days and opened? arrive as ordinary data; the rule performs no hidden lookup.
2. Make the boundary visible. Fourteen days is accepted with <=; the first rejected day is therefore 15.
3. Return labelled data. The result names both the decision and, on denial, the reason an application can inspect.

How to reason about it

• Keep host data conversion outside the rule and pin the exact datum passed into the checked profile.
• Return a compact value whose interpretation is documented by the application, then test both accepted and rejected boundaries.
• Version source, input corpus, and receipts together so replay has an explicit denominator.
• Once a decision rule is stable, encode its exact reviewed bytes as a Lispex Image when you need a deterministic visual transport. Keep the ordinary source as the review and version-control surface.

Check yourself

What should the rule return for (refund-decision 14 #f), (refund-decision 15 #f), and (refund-decision 9 #t)?

A common mistake

A decision receipt does not decide whether the business policy itself is fair or correct.

Keep going

The first-project lesson builds and tests this rule from scratch. Lispex Images can carry the exact reviewed source without changing its meaning.

First decision rule · Lispex Images