Forests (Licences and Permits) Regulations 2019

This ruleset asks one question: “which licences or permits does this application need?” The applicant describes what they intend to do in a State forest, and for each intended activity the rules switch on a matching requirement.

You provide a fact · Rules work out a conclusion.

Seven independent checks each look at what the applicant intends and, if it matches, switch on the matching requirement. They don't interact — an application can trigger any number.

Two triggers are compound — more than one condition must line up:

One final rule ties the checks together. If the application has triggered a licence or permit, stating a purpose becomes Obligated — the applicant must do it. (The check ORs eight of the nine requirement flags together; one — taking away forest produce — is left out, and a never-set grazing flag is left in. See Observations.)

Mandatory applicant details: title, given name and family name, plus the address's street number, street name, suburb, state and postcode are Required; the unit number is Optional.

Additional activities are handled with a “for each” check: for every extra activity the applicant lists, the permitted act and the person or class it applies to are required, and an additional-activity request is recorded (which in turn obliges a purpose).

Coverage here is genuinely assertive: 21 of the 22 scenarios check an outcome, and the suites are organised one-per-permit. Every permit-required flag carries both a positive case (trigger present → permit required) and a negative one (trigger absent → not required) — exactly the shape you want — and the two compound triggers are tested on both sides: the restricted-area suite pairs a “known experimental area” (required) with an “unknown experimental area” (not required), and the research suite separates “for experimentation” from “used in research”.

Since the previous review, two scenarios that asserted nothing now assert a value: 8 Applications → Information not required… now checks that isPurposeSpecified comes out False when no permit fires, and the (7) Additional activities scenario now asserts isAdditionalActivityRequested is True. The gaps worth closing: (1) the purpose obligation is still untested — no scenario asserts the Obligated modality on isPurposeSpecified; (2) the remaining assert-nothing scenario, 8 Applications → Data required for licence, leaves the applicant name/address requirements unverified; (3) the grazing-licence flag is never asserted, consistent with no rule setting it (see Observations); (4) the additional-activities suite has only a positive case — and, confusingly, the scenario is named “No additional activities…” yet supplies one activity and asserts the request flag True (there is no genuine empty-list case); and (5) no scenario triggers several permits at once, so the independence of the checks is untested. The restricted-area suite also omits the nursery and fenced branches.