Individual Results are record-by-record results saved to a ProVal database during execution of the Experience Studies command.

Check the Save Individual Results box to save results, on a record-by-record basis, to a ProVal database file.

Select the Database file name, the name of the file in which you wish to store the individual record results of the Experience Study analysis, or click the New button to create a new database file in which to store the output.

Check the Delete all existing records before processing box if the selected Individual Results database file already contains records and you wish to "wipe the slate clean" without preserving existing records or database field values. Otherwise, the Experience Study results will be merged into the existing records, using the key field(s) specified in the Databases & Census Specifications topic.

The Experience Study results section presents the list of fields to be saved to the selected database, along with the key field(s) specified under the Databases & Census Specifications topic. Double-click an item’s row, or select an item and click the Edit button, to edit its Field name. For new fields: furnish a Description, format the field, and provide a column title for viewing the Individual Results database. The Individual Results output variables correspond to reports that are available through Experience Studies.

Identifying Information 

zYearBeg indicates the beginning of the annual period of the individual results data record. For example, if an experience study begins on 1/1/2014 and ends on 1/1/2016, there will be two blocks of data. The first block will have a zYearBeg of 2014, corresponding to the results between 1/1/2014 and 1/1/2015 and the second block will have a zYearBeg of 2015, corresponding to the results between 1/1/2015 and 1/1/2016. 

​zStatBegin and zStatEnd indicate the beginning and end of year ProVal status of each record (see Status Code Mappings for more details). zAge, zSex, zASV (actives only), zSpAge (inactives only), and zSpSex (inactives only) are used for table look-ups of decrement probabilities, election probabilities, and rates of salary growth, as well as to group the results for reports. Only information relevant to the assumptions selected to be studied are included on the output database. 

Active and Vested valued through active Decrements

Results are output for active participants and indicate decrement exposure (zEdis, zEdth, zEret, zEtrm), actual decrement incidence (zDdis, zDdth, zDret, zDtrm) and expected probability of decrement (zQdis, zQdth, zQret, zQtrm). If any contingency has multiple decrements (i.e. rates by benefit), then extra result fields are created (e.g. zEdis1, zDdis1, zQdis1, zEdis2, zDdis2, zQdis2). Only the retirement and death decrements apply to vested valued through active participants. If a Headcount weight is specified, a second set of headcount weighted fields will be included in the results. They will end with HW (i.e. zEdisHW, zEdthHW, zEretHW, zEtrmHW, etc...)

Active and Vested Valued through active Election Probabilities

Results are output for active participants and indicate the assumed probabilities (e.g. zPDP_Exposure_ben1) and actual experience (e.g. zPDP_Actual_ben1) of receiving the benefit. 

Continuing Actives Salary Growth

Results are output for active participants and indicate beginning of year salary (zSal_PriorYr), end of year actual salary (zSal_Actual), and end of year expected salary (zSal_Expected).

Inactive Mortality

Results are output for inactive participants and indicate mortality exposure (zEx, zEy), actual mortality incidence (zDx, zDy), and expected probability of mortality (zQx, zQy). x refers to member mortality and y refers to spouse mortality.

​The Additonal Fields section allows the user to take fields from the input databases and pass them through to the Individual Results database. The universe of potential additional fields is determined by the first input database. Once the additional fields have been specified, values will be retrieved for each record from the database in which that record is first found. For example, if a record is not in the 2014 database, but is in the 2015 database for a 1/1/2014-1/1/2015 data block, then the additional field will be populated from the 2015 database file.