FedRAMP needs a style guide for constraints

[aj-stein-gsa]

This is a ...

improvement - something could be better

This relates to ...

• ~the FedRAMP OSCAL Registry~
• ~the FedRAMP OSCAL baselines~
• ~the Guide to OSCAL-based FedRAMP Content~
• ~the Guide to OSCAL-based FedRAMP System Security Plans (SSP)~
• ~the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)~
• ~the Guide to OSCAL-based FedRAMP Security Assessment Results (SAR)~
• ~the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M)~
• ~the FedRAMP SSP OSCAL Template (JSON or XML Format)~
• ~the FedRAMP SAP OSCAL Template (JSON or XML Format)~
• ~the FedRAMP SAR OSCAL Template (JSON or XML Format)~
• ~the FedRAMP POA&M OSCAL Template (JSON or XML Format)~
• [X] the FedRAMP OSCAL Validations

User Story

As a developer on the FedRAMP OSCAL constraints, I would like a guide for how to design and implement Metaschema constraints, individually and how they combine together, to make it clear to FedRAMP staff and community contributors on how to add, change, or remove tests to conform with the preferred style of the program.

Goals

• [ ] Clear guidelines on how a constraint should be formatted and implemented
• [ ] Clear guidelines on how multiple constraints should be organized
  • [ ] from a general organizational perspective
  • [ ] specifically how related constraints (same data structure, same logical theme) are organized with each other

Dependencies

No response

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.

Other information

Based on conversation from today's standup #610 and #669.

[aj-stein-gsa]

Given receptivity and interest in #720 and review of #735. I would say we will need to start this guide up to address that first style requirement if approved.