Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include an attribute for result generation timestamp #206

Open
ASL-rmarshall opened this issue Jul 26, 2023 · 1 comment
Open

Include an attribute for result generation timestamp #206

ASL-rmarshall opened this issue Jul 26, 2023 · 1 comment
Labels
consider_for_v1 Model updates to be considered for inclusion in v1 release

Comments

@ASL-rmarshall
Copy link
Collaborator

ASL-rmarshall commented Jul 26, 2023

The date/time of result generation (or analysis result program execution) is usually needed for auditing purposes and may be included in, for example, display footers.

This also raises the question of whether it should be possible represent results from multiple executions of the analysis result programs. If this is necessary (e.g., so that it's possible to compare results from separate executions of the the same version of the analysis), then it may be necessary to introduce to introduce something like "result sets" as timestamped sets of results, e.g.:

@ASL-rmarshall ASL-rmarshall added the consider_for_v1 Model updates to be considered for inclusion in v1 release label Sep 26, 2023
@ASL-rmarshall
Copy link
Collaborator Author

This was discussed on 2024-03-13 and it was agreed that this change should be considered for a future version of ARS because additional consideration is required. For example, while the proposal above suggests creating resultSets within the Analysis class, it's unclear whether it might be better to allow "result sets" to include results from more than one analysis. One option for consideration could be to move results out of analyses (e.g., to be a separate component of the reporting event itself). These results would need to retain a reference to the analysis that generated them (e.g., via analysisId), but could possibly be grouped in different ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consider_for_v1 Model updates to be considered for inclusion in v1 release
Projects
None yet
Development

No branches or pull requests

1 participant