# Filter policy playground Design and test policies for the proposed ground-up MeshCore forwarding engine. The playground models phased evaluation, immutable receive-time matches, explicit priority and stop behavior, ACL ownership, compact typed conditions, and accumulated forwarding decisions. Everything runs locally in this browser. Channel keys, packet facts, and policy drafts are not uploaded anywhere.
Engine design preview

This page targets the new policy-engine idea, not today's FPF7 file or existing set flood.* commands. Its readable policy language, JSON, and Base64 bundle are a prototype for design testing. Current firmware cannot install these policies yet.

## Build a policy
Load an example:

Rule builder

Create a policy rule

Identity and execution

Match immutable receive-time facts

Accumulate forwarding actions

Readable policy definition

Policy draft

Rules in execution order

Rules match the same immutable packet facts. Ordering is phase, then descending priority, then stable rule ID. Drop decisions are sticky.

Add a rule or load an example to start exploring.

    Immutable packet simulator

    Explain an evaluation

    Import and explain

    Paste readable policy or a saved draft

    Accepts one-line policy set ... when ... do ... definitions, playground JSON, or a playground Base64 bundle.

    Export

    Move or save this design

    Proposed human-readable definition. Current firmware does not accept it yet.

    ## Proposed evaluation contract The simulator uses these rules: 1. Every matcher reads the same immutable receive-time packet facts. 2. Rules run by phase, descending priority, then stable rule ID. 3. A drop decision is sticky and cannot be undone by a later rule. 4. The first matching scope, timing, queue, and retry action in execution order wins. 5. All matching token-bucket rate constraints remain attached to the decision. 6. `stop=phase` skips later rules in that phase. `stop=policy` skips later configurable rules, but never mandatory packet validation or radio safety. 7. Shadow rules report what they would do without changing the decision or stopping other rules. 8. Expensive facts such as channel authentication, decryption, and path-table lookup are resolved once per packet and reused by every matching rule. The byte-budget display is deliberately approximate until the packed firmware codec exists. It demonstrates why simple mappings should not reserve a maximum- sized structure for every possible condition and action.