Add "current-source" to snapshot limits

[aidan-short-gevernova]

It maybe be useful to include the "current-source" that determined the limit for each duration in the snapshot spec. This could follow the same pattern used with "limiting-analysis" where we only specify the source if it differs from the default value in the header.

A specific use case for this is a TO that is using the TROLIE SDK to automatically pull snapshots from an ISO, and they want to know the source of each limit if it differs from the source of the proposals they submitted.

[catkins-miso]

Hi @aidan-short-gevernova could you elaborate a little and respond to the following?

• Why isn't provenance enough? Requesting a detailed snapshot includes all the ratings proposals that were used to clear the limits. If there's an override, it should be there, same with another TOs ratings on ties.
• A limit has both continuous and emergency ratings that may come from different sources, e.g., one TO's continuous rating may be limiting while the other TO's emergency rating may be limiting. Moreover, the Clearinghouse Provider might override the ratings from just one of the TOs, resulting in a similar situation.
• Edge case: A Ratings Provider might have had a proposal rejected in the clearinghouse having been initially accepted by TROLIE. This would manifest in the detailed snapshot as the rejected proposal not being included in the provenance.

Overall I contend that accounting for all the "whys" of which rating in a limit was cleared is most robustly done with provenance, I believe.

[aidan-short-gevernova]

Hi @catkins-miso, my thought process here is to make things easier on the client.

I completely agree with you that all of this information can be derived from the provenance. However, I think it can be assumed that the Clearinghouse Provider knows the source that was limiting for each of the continuous and emergency limits when the snapshot is generated. Therefore, I think it could be helpful to just directly tell the client what the sources are, rather than expecting them to parse the provenance to determine each source. If they want more information than that, they could just go look at the provenance.

From the perspective of the TROLIE SDK use case, this would also allow users to get the limit sources from the TROLIE server without needing to fetch the whole detailed snapshot if they don't need all of that additional provenance information.

Please let me know what you think.

[catkins-miso]

Thanks @aidan-short-gevernova I have two additional requests to mark this as a proposal and consider it further.

1. I'd like to better understand the use case: Why does the RP need this information? If it's for something in operations, it would inform the docs for the attribute to understand how it is intended to be used, since it is effectively redundant.
2. Please provide a JSON snippet (or accept my suggestion below).

Following the header source, I believe the most straightforward and consistent way to implement what you're looking for is to add an optional provider to the limit types

"periods": [
    {
        "period-start": "...", //elided for clarity
        "period-end": "...",
        "continuous-operating-limit": {
            "mw": 160,
            "pf": 1,
            "provider": "TO1" //new optional attribute reuses named identifier schema
        },
        "emergency-operating-limits": [
            {
                "duration-name": "DAL",
                "limit": {
                    "mw": 190,
                    "pf": 2,
                    "provider": "TO2" //new optional attribute reuses named identifier schema
                }
            }
        ]
    }
]

[aidan-short-gevernova]

Thanks @catkins-miso, I don't think I gave a clear description of what I'm thinking for this so I'll go into more details below.

The use case that I'm thinking of is a TO that is a ratings provider for a tie-line within an ISOs footprint. Once the ISO has completed it's clearing house process, the TO wants to know details about the rating source of each rating, to see if the limit is different from the value they submitted. Rather than specifying a optional provider for each limit type, I was thinking more along the lines of reusing the existing current-source schema to specify the source of each value. This would explicitly show whether each value came from an AAR, recourse rating, override, etc. since they can be different for each duration.

These rating source theoretically be derived from the provenance details by processing the proposals considered, temporary AAR exceptions, and overrides details for each resource, but I think it would be better to make it explicit in the limits for the following reasons:

1. Requiring the TO to process the provenance details to find the source of the limit would essentially require the TO to run their own clearing house process. I believe this has a high chance of resulting in discrepancies between the ISO's limits and the TO derived values.
2. The Java TROLIE SDK only supports the default snapshot format. With the current spec, we would have to update it to allow for the detailed snapshot as well if the TO wanted to get the limit source data.

A possible approach would be to use the current-source schema, and follow the pattern setup with limiting-analysis to only specify the current-source for each duration if it is different from the continuous limit.

For example:

"periods": [
    {
        "period-start": "...", //elided for clarity
        "period-end": "...",
        "continuous-operating-limit": {
            "mw": 160,
            "pf": 1
        },
        "emergency-operating-limits": [
            {
                "duration-name": "EMERG",
                "limit": {
                    "mw": 170,
                    "pf": 1
                },
                "current-source": "Estimated" // Estimated rating was used for this emergency limit
            },
            {
                "duration-name": "DAL",
                "limit": {
                    "mw": 190,
                    "pf": 2
                }
                // This emergency limit used a "Calculated" limit and doesn't need to be specified.
            }
        ],
        "current-source": "Calculated" // continuous limit source. Could be omitted if we assume "Calculated" is the default.
    }
]

Hopefully this clears up what I'm thinking here. I also think your suggestion about adding "provider" could be useful if we want to include the limiting segment for each limit as well. The combination of current source and limiting segment would make it very explicit how the ISO determined each limit. I will leave that for another discussion unless you think it would be beneficial to discuss both together.