Should these five rules carry timeframe_type/timeframe_num?

[ktalons]

Sharing a consistency check I ran in a personal capacity while building against the consolidated rules dataset.

I'm planning to maintain an open-source tool that computes VDR and VER response deadlines by reading fedramp-consolidated-rules.json rather than embedding the numbers, so that a change to a cadence upstream reaches the tool without a code change. That means every timeframe has to be derivable from the data. I walked all 246 FRR rules at v2026.07.14.01 to find the ones where it is not.

What holds, and it holds cleanly. The dataset encodes timeframes in two shapes and is consistent about both, and AGENTS.md documents both placements: it lists simple timeframes among the fields a class-specific variant may carry, and again among the "other useful top-level fields" a requirement may carry. Rules that vary by class put timeframe_type and timeframe_num inside each varies_by_class entry. Flat rules carry the same pair at the top level, and 17 of them do: AFC-FRP-PNT (bizdays 10), CDS-CSO-FRC (weeks 2), CDS-UTC-AAD (bizdays 5), six REC-IAS-* rules, five SCN-* rules, and VER-TFR-MHR (months 1) and VER-TFR-MAV (days 192). No rule mixes the two shapes. As a consumer that is genuinely nice to work against.

The exceptions. Five flat rules state a numeric timeframe in the statement and encode nothing:

Rule	Force	Prose timeframe
VDR-TFR-NMV	MUST	at least once every 3 months
CCM-OCR-AVL	MUST	every 3 months
IVV-CSF-MCA	MUST	every 3 years
MKT-IIP-DLA	MUST	within 2 years
MKT-CAS-RFR	MUST	within 5 business days

A sixth, CCM-QTR-SAR, states a two-sided window ("at least 3 business days after ... AND within 10 business days of such release") that a single timeframe_type / timeframe_num pair cannot express, so I have left it out rather than counting it as a gap.

To be clear about what this is not: nothing here is a schema violation. dependentRequired in frr_requirement and frr_requirement_level only pairs the two fields when one is present, so the file validates today either way. This is about what a consumer can derive.

Consumer consequence. Any tool that builds a compliance calendar from timeframe_type / timeframe_num silently drops these five cadences, and all five are MUST rules. VDR-TFR-NMV is the one that bites me directly: every other timeframe in my VDR and VER calculations comes out of the data, and this one has to be hardcoded, which is exactly the failure the structured fields prevent. VDR-TFR-PDD sits one rule below it and its Class A value is months / 3, the same cadence NMV states in prose.

The question. Is the omission deliberate on some or all of these? I can see an argument that a verification cadence is a different kind of thing from a response clock and was left unencoded on purpose. If so, I would rather record that as a documented decision than carry a hardcoded exception. If it is simply a gap, each is a two-line addition, and I am happy to open a PR if that is useful.

Also worth linking: @badgerinspace raised VDR-TFR-NMV from the interpretation side in this comment on #146 on 2026-08-05, still unanswered. Different question, same rule.

Kyle Versluis (personal capacity)

[pete-gov]

Catching up - I did the timeframes mostly by hand and probably missed these. I will add it to my list for an update to fix!