Stateful vs. Non-stateful policy distinction required for accurate compliance evaluation

[nelsonsantryl]

Is your feature request related to a problem? Please describe.

Count-type policies need to know if they should evaluate a vehicles’ compliance only when the last event occurred, or on a rolling basis (stateful vs. non-stateful). Put another way, if a vehicle’s latest event was compliant, and then the vehicle does nothing for a period of time and is now governed by a new rule of a policy - how should a compliance evaluator understand this vehicle's compliance?

For example, say I want to create a policy where I allow 100 scooters during the day, and 0 scooters at night. My policy might look something like this:

{
  "policy_id": "ecc534e6-0169-42bf-bed2-147603aacbca",
  "provider_ids": [],
  "name": "Scooters only allowed during the day",
  "description": "100 scooters allowed during the day, and banned at night",
  "start_date": 1637308800000,
  "end_date": null,
  "prev_policies": null,
  "rules": [
    {
      "rule_id": "87dcd660-c04b-4ee9-9733-9dfc365f2c1a",
      "rule_type": "count",
      "geographies": [
        "c6b05565-d4a3-4952-be0b-5f7ffad36c3a"
      ],
      "vehicle_types": [],
      "statuses": {},
      "name": "100 Scooters allowed during the day",
      "maximum": 100,
      "start_time": "09:00:00",
      "end_time": "17:00:00"
    },
    {
      "rule_id": "585a6548-0268-4cba-a35f-61af10f61fbc",
      "name": "No scooters allowed at night",
      "rule_type": "count",
      "geographies": [
        "c6b05565-d4a3-4952-be0b-5f7ffad36c3a"
      ],
      "vehicle_types": [],
      "statuses": {},
      "maximum": 0,
      "start_time": "17:00:00",
      "end_time": "09:00:00"
    }
  ]
}

If a scooter is in geography during the day (assuming there are fewer than 100 scooters for a given provider), then it is compliant. And, once it hits 17:00:00 it is no longer compliant if it is still within the geography.

Now, let’s say we have a policy where the agency only allows providers to drop off scooters in the morning between 5am - 10am, and they are not allowed to drop off any more scooters after this time. The policy would look something this:

{
  "policy_id": "ecc534e6-0169-42bf-bed2-147603aacbca",
  "provider_ids": [],
  "name": "Morning drop off policy",
  "description": "Providers are only allowed to drop off scooters between the hours of 5am - 10am",
  "start_date": 1637308800000,
  "end_date": null,
  "prev_policies": null,
  "rules": [
    {
      "rule_id": "87dcd660-c04b-4ee9-9733-9dfc365f2c1a",
      "rule_type": "count",
      "geographies": [
        "c6b05565-d4a3-4952-be0b-5f7ffad36c3a"
      ],
      "vehicle_types": [],
      "statuses": {
        "available": [
          "provider_drop_off"
        ]
      },
      "start_time": "05:00:00",
      "end_time": "10:00:00",
      "name": "Providers can only drop off scooters during the morning",
      "minimum": 0
    },
    {
      "rule_id": "585a6548-0268-4cba-a35f-61af10f61fbc",
      "name": "Providers are not allowed to drop off scooters after 10am",
      "rule_type": "count",
      "geographies": [
        "c6b05565-d4a3-4952-be0b-5f7ffad36c3a"
      ],
      "vehicle_types": [],
      "statuses": {
        "available": [
          "provider_drop_off"
        ]
      },
      "maximum": 0,
      "start_time": "10:00:00",
      "end_time": "05:00:00"
    }
  ]
}

Now, if a provider does a provider_dropoff at 9:50am, that would be considered compliant. And we do NOT want to evaluate this vehicles’ compliance again. Because, if we evaluate at 10:01, and the scooter has not undergone any state change, then the compliance evaluator could use the logic from the first example, and label this vehicle as non-compliant.

Describe the solution you'd like

Add a new field to the policy json to indicate if the policy should be evaluated statefully (ongoing), or non-statefully (once at the time of the event). This field would be on the policy level (not the rule level).

Is this a breaking change

• No, not breaking

However, updates to companies’ respective compliance engines could be required.

Impacted Spec

For which spec is this feature being requested?

• policy

Describe alternatives you've considered

none.

Additional context

none.

[schnuerle]

Interesting problem, thank you for sharing it.

I'm going to tag some other people who deal with policy implementations and see what they think, and if there is an existing solution to this problem. @jean-populus @marie-x @avatarneil @quicklywilliam

[quicklywilliam]

My inclination is that rather than adding a new (very abstract) field, it might be better to better define what we mean by a count rule and potentially add new rule_types. In general I think there is a lot implicit in how different rule_types are evaluated and it would be great to make it explicit.

To take the second example given, an event (ie drop-offs) that is explicitly disallowed seems like a pretty distinct use case and could be represented by a disallowed_states type or some such. I'm not sure that would cover every use case we could come up with, so perhaps a good next step would be to come up with more use cases and then think through how a new statefulness field might clarify vs adding new rule_types.

[schnuerle]

With MDS 2.0 how we define policies like this has changed and is clearer now. If you disagree please reopen this issue to discuss.