[Policy API] add rate options to other rule types

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

Cities want to be able to assess a fee due to non-compliance - for example a 10¢ fee for vehicles over a cap, or a 25¢ fee for each time a vehicle goes over the speed limit.

Describe the solution you'd like

Instead of creating separate rate rules, it would be nice to be able to attach a rate to one of the existing rule type (counts, time, speed).

Is this a breaking change

No?

Impacted Spec

For which spec is this feature being requested?

• policy

Describe alternatives you've considered

Currently no way this can be represented in the Policy API format.

Additional context

Add any other context or screenshots about the feature request here.

[marie-x]

I think count rules are trickier than time rules for applying fees, but also, I had originally wanted to put fines in a separate API (I tentatively named it "Enforcement") that consumed the output of the Compliance service (which takes events, policies, and geographies as inputs and emits measurements against them).

In this case, I could imagine an over-cap policy, 25 cents per vehicle over the cap, that looks like this:

{
  "name": "Over-Cap Fee",
  "description": "$0.25 per vehicle over cap of 1000",
  "policy_id": "2800cd0a-7827-4110-9713-b9e5bf29e9a1",
  "start_date": 1558389669540,
  "publish_date": 1558389669540,
  "end_date": null,
  "prev_policies": null,
  "provider_ids": [],
  "rate_recurrence": "once",
  "currency": "USD",
  "rules": [
    {
      "name": "1000 vehicle cap",
      "rule_id": "9cd1768c-ab9e-484c-93f8-72a7078aa7b9",
      "rule_type": "count",
      "geographies": ["0c77c813-bece-4e8a-84fd-f99af777d198"],
      "statuses": { "available": [], "non_operational": [] },
      "vehicle_types": ["bicycle", "scooter"],
      "maximum": 1000,
      "rate_amount": 25
    }
  ]
}

But that the possible asks here can be pretty varied. Is it $0.25 for each vehicle over the cap, or $0.25 times the total number of vehicles? Or is it a flat $0.25 for busting the cap at all, rather than per the overage? With what frequency and recurrence does this fee take effect, e.g. is it the same fee for busting the cap momentarily vs. keeping it busted for hours? Agree that this is tricky, and exposes the limitations of the current bolt-on to Policy.

I can't speak for @quicklywilliam, but I think this was never intended to cover every possible case; someday I'd like to revisit the Enforcement API, which I haven't shown anyone outside E&A.

[quicklywilliam]

Yep, @Karcass is right - we didn't intend to cover this use case. Internally, we distinguish between "fees" (paying for use of the ROW) and "fines" (penalties for non-compliance). There's definitely some grey area here, because often you can take a fine and think about it as a fee. For example, "a 500 vehicle cap with a fine of 25 cent per vehicle over it" => "a fee of 0 cents per vehicle up to 500 and 25 cents per vehicle above 500". The fee could be modeled using the existing API, along the lines of what @Karcass is suggesting. The fine cannot.

Technically, the point of distinction for us was that fees can be expressed and evaluated with a single policy rule, but fines need a way to refer back to another rule – the one that is being violated. That dependence means that in order to evaluate a fine you first need to evaluate compliance, which in turn means that a fine rule object needs to encode information about the evaluation of the compliance rule. I think there may be a way to do this that is graceful and extensible, we just decided not to bite that off and to focus the release on fees (and subsidies).

FYI a lot of convo about this also in #631

Posting an update from presentation MDS Policy Extensions 15 July 2021

• Compatible with 1.1 (spec does not forbid rate info on non-rate Rules)
• Clarifications needed for interpretation if we want to make this more robust for 1.2
• May be possible to drop the rate Rule-type
• Proposal: add clarifications in a PR for 1.2
• Proposal: consider dropping separate rate type

[schnuerle]

@marie-x can take ownership of this and make a PR in the next 2-3 weeks, for review by @jean-populus and @quicklywilliam and the WG community.

[marie-x]

@avatarneil's PR for #631 should cover this

[jiffyclub]

@avatarneil @marie-x Can you elaborate on how this is addressed by #658?

[avatarneil]

@jiffyclub There is nothing in the spec as far as I can tell that disallows rate options being applied to other rule types as the spec stands today. #658 provides examples of those options being used on another rule type, time. Perhaps there should be another PR describing what the semantics should be if this was used on a count rule type or speed rule type too, but #658 at least somewhat satisfies this issue I'm pretty sure.

[schnuerle]

@avatarneil will be presenting PR #658 in today's Working Group meeting.