Two baselines. One implementation. Zero duplicated programs.

The architecture of a dual-baseline program

• The crosswalk is the pivot table. Maintained as a first-class artifact, it maps every implemented control to its Rev. 2 requirement and its Rev. 3 requirement. Every other dual-baseline mechanism hangs off this table.
• One SSP as source of truth, one derived view. The primary SSP (usually Rev. 3-structured once you convert — see the conversion guide) generates the other view through the crosswalk. Independent editing is how the views drift into contradiction.
• Evidence tagged to both objective sets. Each artifact carries two indexes — its 800-171A objective and its 800-171A Rev. 3 objective. Collection happens once; reporting happens twice.
• ODP values resolved per customer, enforced at the strictest. Where customers' parameter values differ, enforce the strictest tenant-wide or segment deliberately — and record the resolution in the ODP register so each customer's view shows its own value truthfully satisfied.
• Change control asks two questions. Every change to the boundary — new tool, new user population, new contract — is evaluated for impact against both baselines before it ships. One review, two verdicts.

The reporting reality

Dual-baseline operation means your SPRS score stays a Rev. 2 artifact computed under the DoD Assessment Methodology, while a civilian customer might see a Rev. 3 posture summary with agency ODP values. Both must be true simultaneously, and both are federal representations. This is exactly the discipline that makes misrepresentation risk manageable: one implementation, honestly mapped twice, beats two optimistic narratives every time.

When does dual-baseline end?

When your last Rev. 2-incorporating contract closes out — a date your contractual baseline inventory predicts, and DoD rulemaking will eventually force. Contractors who built the dual-baseline machinery retire the Rev. 2 view by deleting a column. Contractors who ran two programs get to decommission one of them.