Add MDS Audit Draft #326
Closed
Add MDS Audit Draft #326
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Document a common set of data definitions between MDS components.
whereissean
requested review from
hunterowens,
thekaveman and
a team
as code owners
added 3 commits
June 12, 2019 11:10
* Simplified/standardized audit details response * Fix formatting * Fixing lat type * Fix some data types
* Allow adjustment of the provider event window. * Fix headings * Clarify event viewport definition and default
marie-x
approved these changes
Jul 9, 2019
|
changing milestone for now. |
|
|
|
Should we consider for the 1.0.0 release? |
Closed
|
HI @drtyh2o can make sure to sign the CLA for your contribution? |
|
This PR will be closed per our call today in favor of #483. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explain pull request
Add new Audit API and associated schema for the evaluation of the technical compliance of providers.
Is this a breaking change
A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
ProvideroragencyWhich API(s) will this pull request impact:
provideragencyAdditional context
MDS enables cities or municipal operators to receive information directly from regulated / permitted entities ("providers") relating to the behavior of vehicles and devices in the public right of way. During initial onboarding of providers and thereafter for maintenance purposes, it may be necessary for the city or its agents to attempt to audit or otherwise ensure that this information is correct.
This question of auditable compliance relates both to the correct formatting of data (e.g., no malformed inputs), its accuracy, and its timeliness. These three factors together are important contributors to the evaluation of the technical compliance of a provider. This is to say, the compliance of regulated / permitted vehicles or devices with the specific requirements laid out both by MDS as a system of interfaces, and by the specific program terms or requirements (e.g. an event telemetry submission latency window, a telemetry temporal resolution requirement, and for the evaluation of the precision of such submissions consistent with GPS accuracy requirements or other program terms that may vary from city to city or within the scope of permitted and regulated program operations.
This specification defines an API which facilitates in-field data collection and evaluation of the technical compliance of providers. It is not intended as a substitute for other evaluative, cooperative, or corrective measures in the implementation or ongoing operations of MDS.