@brian-ruf, so you wanted us to discuss this in the afternoon, and potentially live code as a group?

OK I didn't quite understand 100% understand how we proposed the use of the entity. I am not sure that will work with the internalized templated variables. I will code the constraint as best as I can perhaps back port it in after the fact.

@Gabeblis agreed to work on this spike with me and try the manual approach, and we compare-contrast approaches with the team later today or Monday.

OK so an update on the spike and a path forward after a day or two of experimentation. As it stands we have a few options to approach the collection of constraints work scoped in #809, particularly how to simplify the maintenance of these first few constraints as a sequence of 25-50, maybe more, in the table in #809 (comment) for constraints to check foundational mandatory attachment checks (level="ERROR") and other optional ones in a subsequent comment's table that are recommended (level="WARN"). @Gabeblis and I are going to split up trying the different approaches and reporting back in the beginning of next week and discuss with the team.

1. Write them out manually, assess the level of effort and maintenance concern
2. Use an out-of-band data in a file, encoded in JSON/YAML/what-have-you/flavor-of-the-week, and splice in the code (@brian-ruf had proposed this code generation approach; I will have to consider that)
3. Use the XML entity structure proposed in SSP Completeness Checks: Appendices C, D, F, G, H, I, N, P #809 (comment) (see entity definition and call site in an OSCAL model for details.
4. Build a map, with statement IDs as keys with the value as a single string value, a sequence, or "map of maps" approach to parameterize all the content, like a more Metapath-focused approach that mimics 3, but with more data locality next to the constraint than 3 with a more expansive use of XML entities than we do with allowed-values (and I was not sure would be possible, more below)
5. Put this information in the catalog, through FedRAMP profiles, with a novel prop, and build indices in the constraint to drive the requirement as a possibly more maintenance-friendly approach in the long-term.

Gabe started evaluating 1 today and will likely do so Monday until we sync, probably during standup.

I have spent time on option 4, and after confirming a series of related bugs in the metaschema-java and oscal-cli tooling, I was able to workaround it. Unfortunately, as the table in #809 (comment) would encourage a lot of paramterization for custom constraint IDs, stubbing prop[@name="help-url"]s, and importantly a context-specific message for a constraint, only the message can be parameterized anyway. This short-coming makes this possible if we narrowly scope the message requirement as the only data to map with the ID. Unfortunately, we would still have to forgo the maintenance of the control statement ID to attachment requirement inline in the constraints itself. I put the WIP work in #989 for the team to review and discuss further, but there is already muddled interest in this approach.

The above shortcomings for 4 make 3 problematic and not very useful, so for now I am going to skip it. 1, 2, and 5 are still on the table.

I am now going to move onto approach 5 in a WIP branch with the profile changes and index to see how that goes, since casual discussion in today's standup confirms that's probably the best way forward (especially with index and index-has-key approach I reasoned about in my head).

More to follow!