Mapping: FedRAMP Rules → OSCAL

This document maps every field defined in the FRR portion of fedramp-consolidated-rules.schema.json to its corresponding location in the OSCAL catalog produced by src/frr2oscal.py. Fields with no current mapping are marked NOT MAPPED and noted with a brief description of the data they contain.

1. Schema Hierarchy Overview

FRR                                  (object, keyed by frr_document_key)
└── {FRR-key}                        e.g. "AFC", "AGU"
    ├── info                         frr_document_info
    └── data                         data_container_frr
        ├── all                      frr_requirements_map  ← processed
        ├── 20x                      frr_requirements_map  ← processed
        └── rev5                     frr_requirements_map  ← processed
            └── {subset-key}         frr_requirements_subset_group
                └── {rule-id}        frr_requirement
                    └── varies_by_class.{a|b|c|d}   frr_requirement_level

All three data scopes (all, 20x, rev5) are now converted. Rules from each scope carry a path prop (FedRAMP namespace) identifying which scope they belong to. Child group IDs include a scope qualifier for 20x and rev5 to prevent collisions with all groups whose subset keys overlap (e.g. VDR/TFR appears in all three scopes).

2. FRR Document → OSCAL Top-Level Group

Each top-level key in FRR (pattern ^[A-Z]{3}$) becomes a top-level group in the catalog.

2.1 FRR.{key} → group

2.2 FRR.{key}.info fields (frr_document_info)

2.3 FRR.{key}.info.subsets (frr_info_subsets)

Subset metadata describes each named group of rules within a ruleset. It is present in the info block but is not present in the current data for any ruleset. No subset has an info block in any scope.

3. FRR.{key}.data → Data Scope Selection

All three scopes are processed. Child group and control IDs reflect the scope they originate from.

4. FRR.{key}.data.{scope}.{subset} → OSCAL Child Group

Each subset key within a scope becomes a child group nested under the parent ruleset group.

The frr_requirements_subset_group schema allows any frr_requirement_id as a property key alongside an optional info entry. When info is present, its title and purpose fields map to group.title and group.parts[name=overview].prose respectively.

5. FRR.{key}.data.{scope}.{subset}.{rule-id} → OSCAL Control

Each rule entry (frr_requirement) maps to one OSCAL control. The schema enforces a mutual exclusion: a rule has either statement + force (simple rule) or varies_by_class (class-conditional rule), never both.

5.1 Simple Rule (has statement and force, no varies_by_class)

5.2 Varies-by-Class Rule (has varies_by_class, no statement or force)

The rule becomes a parent control with a fixed statement, and each class variant becomes a child control nested in the parent's controls list (see MISSING_FROM_OSCAL_LIBRARY.md §4 for the library workaround).

Parent control:

6. varies_by_class.{a|b|c|d} → OSCAL Child Control (frr_requirement_level)

Each class key (a, b, c, d) becomes a child control appended directly to the parent control's controls list.

7. Supporting Types Summary

8. Summary of Unaddressed Fields

The following fields appear in the source data but are not yet mapped to OSCAL output. They are recorded in data/unhandled.json at runtime.