What is a Full Switch?

We define a Full Switch as an analysis conducted against an account using custom data. Using our Profiles API to create usage and solar profiles with real world data and then supplying those as inputs into a Savings Analysis would constitute a Full Switch flow.

What is the difference between a Full Switch and a Quick Switch Analysis?

As noted above a Full Switch uses user supplied data profiles such a real-world hourly usage and solar production data that is housed in a profile. The use of a custom user-supplied profile in a Savings Analysis request will trigger a Full Switch. In contrast a Quick Switch uses Arcadia's Typical Baseline data as a approximation.

Full Switch Template

{
    "accountId": "4c6176b3-46c2-47d2-829f-5b8f842aa9ae",
    "fromDateTime": "2025-10-01",
    "useIntelligentBaselining": false,
    "propertyInputs": [
        {
            "keyName": "profileId",
            "dataValue": "676065b0fead7732016d4f85",
            "scenarios": "before,after"
        },
        {
            "keyName": "profileId",
            "dataValue": "676065d859a56939848a15b7",
            "scenarios": "after,solar",
            "operator": "-"
        },
        {
            "keyName": "rateInflation",
            "dataType": "DECIMAL",
            "dataValue": "1.9",
            "scenarios": "solar"
        },
        {
            "keyName": "rateInflation",
            "dataType": "DECIMAL",
            "dataValue": "3",
            "scenarios": "before,after"
        },
        {
            "keyName": "masterTariffId",
            "displayName": "Residential",
            "dataType": "INTEGER",
            "dataValue": "522",
            "scenarios": "before"
        },
        {
            "keyName": "lseId",
            "displayName": "Pacific Gas & Electric Co",
            "dataType": "INTEGER",
            "dataValue": "734",
            "scenarios": "before"
        },
        {
            "keyName": "tariffCode",
            "displayName": "E-1",
            "dataType": "STRING",
            "dataValue": "E-1",
            "scenarios": "before"
        },
        {
            "keyName": "territoryId",
            "dataValue": "3538"
        }
    ],
    "rateInputs": [
        {
            "chargeType": "CONSUMPTION_BASED",
            "chargePeriod": "MONTHLY",
            "transactionType": "BUY",
            "rateBands": [
                {
                    "rateAmount": 0.15
                }
            ],
            "scenarios": "solar"
        }
    ]
}

Supplemental Context:

As you can see above the request begins with our top level definitions such as the account identifier accountId (or providerAccountId if you choose), starting point (fromDateTime) and the indication that we are enabling intelligent baselining (useIntelligentBaselining).

`propertyInputs` List

The next component will be our property inputs. These are objects supplied as key/value pairs that have implications for the underlying calculation. These could be designations to pull in "Profile" data (example "keyName": "profileId"), or they could be criteria that influence cost, tiering, credits, or other account specific behavior impacting the analysis (example "keyName": "territoryId"). Our collection of properties are extensive, so we recommend a thorough read through of our Properties documentation to ensure you have a good grasp on how to identify, unpack, and facilitate their use in your savings analyses for optimal results.

Because this is a Full Switch we are defining our usage/consumption data and our solar production data via the profileId values that are associated with them:

// The property object below illustrates a profile housing our base consumption data. Since we do not expect that to change post solar intervention we supply the before ("before-solar") and after ("after-solar") scenario designations.
{
    "keyName": "profileId",
    "dataValue": "676065b0fead7732016d4f85",
    "scenarios": "before,after"
}

// The property object below illustrates a profile housing our solar production data. We track the implications of the production in our after ("after-solar") and solar scenario designations. this ensures that any PPA/Lease configurations for our system are factored into the total cost savings projections.

{
    "keyName": "profileId",
    "dataValue": "676065d859a56939848a15b7",
    "scenarios": "after,solar",
    // Since our solar production is offsetting our consumption we apply the "-" operator
    "operator": "-"
}

// In both cases the property `keyName` chosen to represent the Profiles is `profileId`, however if you choose to create your profiles with a `providerProfileId` field this can be supplied alternatively with the matching dataValue as well.

While Intelligent Baselining can be used when working with less granular data we are illustrating the use case where the data provided is in 8760 (hourly for 365 days) format. Since we do not need interpolation/extrapolation measures against our data we supply "useIntelligentBaselining": false as real world meter grade data will always yield the most accurate calculation results.

`rateInputs` List

This list houses any custom rates or adjustment we want to make to the calculation. You can read more about user adjusted rates and contracted rates with example request snippets to help guide your implementation. In this template we are mimicking a PPA at a $0.15/kWh rate. You could also include supplemental items that may not be captured by our Tariff models such as local or state taxes. On the subject of handling supplemental inputs like taxes and we outline our modeling policy here, please take a moment to review at your convenience.