169 requirements across five business requirements documents, each traced to the method that verifies it. This matrix is the check that the suite hangs together: a requirement with no verification method is an intention, and a test with no requirement behind it is effort nobody asked for.
A traceability matrix is only worth reading if it can embarrass the program, and this one has a gaps section because of that. A matrix showing complete coverage of everything usually means the requirements were written to match the tests, or the gaps were quietly excluded from scope. §09 records five places where traceability is genuinely incomplete — including the largest schedule risk on the program, which has no requirement at all because it is a risk rather than a requirement. ⚠ Recording that is more useful than a clean matrix, because a reader tracing schedule exposure through this document would otherwise conclude it is covered.
Contents
- Purpose and how this matrix is built
- Coverage summary
- Verification method distribution
- BRD-01 — Identity Resolution
- BRD-02 — Core Administration
- BRD-03 — Integration Layer
- BRD-04 — Data Warehouse
- BRD-05 — Preserved Capabilities
- Traceability gaps — recorded, not hidden
- How to read this against the program
01 — Purpose and how this matrix is built
Every requirement in the five business requirements documents appears here with the method that verifies it. The matrix exists to answer three questions an auditor or an incoming program manager will ask: is every requirement verified, is every verification traceable to a requirement, and what is not covered.
This matrix is derived from the requirements documents rather than maintained alongside them, and that is a deliberate choice about which failure to avoid. A hand-maintained matrix is written once, accurately, and then diverges: a requirement is renumbered, one is added late, another is dropped in review, and nobody re-reads a 169-row table to notice. Deriving it means the matrix cannot claim a requirement that does not exist, and cannot miss one that does — the two failures that make a traceability matrix worse than none, because both are invisible to the reader trusting it.
02 — Coverage summary
| Workstream | BRD | Requirements | Must | Traced to a method |
|---|---|---|---|---|
| Member Identity Resolution & EMPI | BRD-01 | 32 | 29 | 32 |
| Core Administration Consolidation | BRD-02 | 41 | 39 | 41 |
| Integration Layer & Interfaces | BRD-03 | 29 | 27 | 29 |
| Enterprise Data Warehouse | BRD-04 | 37 | 35 | 37 |
| Preserved & Best-of-Both Capabilities | BRD-05 | 30 | 26 | 30 |
| Total | 169 | 156 | 169 |
03 — Verification method distribution
| Verification method | Requirements | What it means here |
|---|---|---|
| Demonstration | 14 | Shown working under realistic conditions — parallel run, restore test, rehearsal, deliberate failure injection |
| Test | 87 | Executed against defined cases with a pass criterion |
| Inspection | 39 | Evidence exists and is examined — a register, a signed definition, a runbook, a named owner |
| Analysis | 19 | Measured against a numeric threshold — latency, throughput, adequacy, a rate against a baseline |
| Audit | 10 | ⚠ Verified by a party outside the team that delivers it |
The Audit row is small and it is the one that matters most. Those requirements are verified by a party outside the team that delivers them — principally the false-positive audit on identity matching, which is checked by the Privacy Officer's function rather than by the data workstream. Classifying it as "Test" would have been tidier and would have hidden the only thing that makes it work: every other quality signal on that workstream improves by matching more aggressively, so the one measure that gets worse cannot be owned by the people whose thresholds cause it.
04 — BRD-01 Member Identity Resolution & EMPI (32 requirements · owner Dr. A. Ravindran)
| Req ID | Requirement (from BRD-01) | Priority | Verification method |
|---|---|---|---|
| FR-01 | Internal resolution before cross-entity matching ⚠ Target duplicates are resolved within the target population first. Matching two dirty populations against ea | Must | Test |
| FR-02 | Deterministic pass Exact match on government identifier plus date of birth, or on a shared member identifier. Expected to resolve | Must | Test |
| FR-03 | Name standardization Nickname and diminutive tables, suffix and prefix handling, phonetic encoding for surname variation | Must | Test |
| FR-04 | Address standardization Postal reference validation and change-of-address lookup applied to both populations before comparison | Must | Test |
| FR-05 | Blocking ⚠ Candidate pairs generated by blocking keys. Pairwise comparison of 1,800,000 against 420,000 is not computat | Must | Test |
| FR-06 | Probabilistic scoring Weighted agreement and disagreement per attribute, producing a single comparison score | Must | Inspection |
| FR-07 | Three configurable thresholds Auto-match above the upper threshold, auto-reject below the lower, clerical review between them. Approximately | Must | Inspection |
| FR-08 | Threshold asymmetry ⚠ Thresholds are set so that uncertainty resolves toward review, never toward merge | Must | Analysis |
| FR-09 | Every decision auditable Score, contributing attributes, rule version and outcome retained per pair — including auto-decisions | Must | Audit |
| FR-10 | Rule versioning A change to rules or thresholds is versioned, and prior decisions identify the version that produced them | Should | Inspection |
| FR-11 | Re-run capability Ability to re-score a cohort under revised rules without discarding steward decisions | Should | Test |
| FR-12 | Survivorship is per attribute ⚠ Each field has its own source-of-truth rule. "Newest record wins" applied globally is prohibited. | Must | Test |
| FR-13 | Coverage history is a union ⚠ Every coverage period from both sources is retained. A merge may never shorten a member's entitlement. | Must | Inspection |
| FR-14 | Address from most recent claim activity Not from the most recently updated record — a record touched by a batch process is not evidence of where | Must | Test |
| FR-15 | Government identifier from enrollment Enrollment is the attested source. Claims-sourced identifiers are not authoritative. | Must | Test |
| FR-16 | Accumulator balances reconciled, not selected ⚠ Running totals are computed from the union of claims, never taken from one side | Must | Demonstration |
| FR-17 | Source values retained Every non-surviving value is retained and viewable. Survivorship selects what is presented, not what is kept. | Must | Inspection |
| FR-18 | Side-by-side comparison Both candidate records with agreeing and disagreeing attributes highlighted, plus the score and its contributo | Must | Test |
| FR-19 | Three steward outcomes Match, not a match, ⚠ and refer. A steward who is unsure must not be forced to guess. | Must | Test |
| FR-20 | Reason capture A structured reason on every decision, not free text alone. ⚠ Reasons are what make the audit meaningful. | Must | Audit |
| FR-21 | Immutable audit trail Steward, timestamp, decision, reason, record version. ⚠ Append-only. | Must | Audit |
| FR-22 | Queue prioritization by risk Active members, dual coverage, high-cost claimants and open care management cases worked first | Must | Test |
| FR-23 | Throughput and aging visible Queue volume, decisions per steward per day, and age of oldest item reported daily | Must | Analysis |
| FR-24 | Independent false-positive audit ⚠ A sample of auto-matched pairs re-reviewed by the Privacy Officer's team — not by the workstream that | Must | Audit |
| FR-25 | Second review on high-risk merges Two stewards required where both records show active claims history | Should | Test |
| NFR-01 | Cross-reference lookup latency Under 100 ms at the 95th percentile — it sits in the eligibility path | Must | Analysis |
| NFR-02 | Batch matching throughput Full population re-scored within a single weekend window | Must | Analysis |
| NFR-03 | Steward workbench availability Business hours, Tier 1. ⚠ Queue downtime is queue days lost and they cannot be recovered. | Must | Test |
| NFR-04 | Audit retention Statutory period, append-only, restorable | Must | Audit |
| NFR-05 | Data residency ⚠ United States only, enforced by platform policy rather than by undertaking | Must | Test |
| NFR-06 | Recovery Per service tier, with a tested restore before go-live — not a configured backup | Must | Test |
| NFR-07 | Access control Role-based; steward access is scoped to the queue and logged per record viewed | Must | Test |
05 — BRD-02 Core Administration Consolidation (41 requirements · owner W. Ferriday)
| Req ID | Requirement (from BRD-02) | Priority | Verification method |
|---|---|---|---|
| FR-01 | Reproduce adjudication outcomes Each target plan configured so that a claim adjudicates to the same outcome, allowed amount and member liabili | Must | Test |
| FR-02 | Plan-by-plan configuration register Every target product mapped to its ACME configuration, with the person who verified it named | Must | Inspection |
| FR-03 | Expected-difference register ⚠ Every intended behavioral difference documented before parallel run, with the reason and an approver | Must | Demonstration |
| FR-04 | Near-identical plans reconciled Where the target has plans that appear identical, the differences are identified and either preserved delibera | Must | Demonstration |
| FR-05 | Provider contracts and fee schedules loaded Reimbursement terms reproduced. ⚠ A pricing difference is a contract breach, not a configuration defect. | Must | Test |
| FR-06 | Configuration peer review No plan goes to parallel run on one person's word | Must | Demonstration |
| FR-07 | Configuration derived from templates Where the ACME hierarchy allows, so future changes propagate rather than being edited plan by plan | Should | Test |
| FR-08 | Adjudication outcome equivalence Pay, deny or pend decisions identical for the same claim. ⚠ There is no third category between "same" and "def | Must | Inspection |
| FR-09 | Claims edit inventory with a decision per edit ⚠ Every edit on the retiring platform classified port, drop, or replace, each with a named decider and a state | Must | Inspection |
| FR-10 | Undocumented edits escalated An edit with no discoverable reason is escalated to the Chief Medical Officer and Compliance rather than defau | Must | Inspection |
| FR-11 | Denial and adjustment code mapping Local codes mapped to the surviving code set. ⚠ The mapping is a deliverable and is itself tested. | Must | Test |
| FR-12 | Pricing equivalence Allowed amount identical to the cent. Rounding behavior verified explicitly. | Must | Test |
| FR-13 | Timeliness preserved Adjudication cycle time within regulatory limits throughout, including the cutover period | Must | Test |
| FR-14 | Auto-adjudication rate maintained ⚠ A drop pushes volume to manual review, which becomes a staffing problem presenting as a systems one | Should | Analysis |
| FR-15 | Group and eligibility structure reproduced Employer groups, subgroups, classes and rate structures | Must | Test |
| FR-16 | Coverage history complete ⚠ Every period retained. A member's demonstrable coverage may not shorten. Consumes the identity resolution ou | Must | Inspection |
| FR-17 | Retroactive terminations and reinstatements ⚠ Retroactivity behaves as on the retiring platform, including re-adjudication of affected claims | Must | Test |
| FR-18 | Effective dating on all entities Benefits, providers, groups and members all carry effective dates and are adjudicated as at service date, not | Must | Test |
| FR-19 | 834 processing per trading partner Full-file and change-file semantics preserved per partner. ⚠ These are not interchangeable. | Must | Test |
| FR-20 | Accumulator balances reconcile exactly Deductible, out-of-pocket and visit limits agree to the cent at cutover. ⚠ Zero variance. | Must | Demonstration |
| FR-21 | Accumulators computed, not copied ⚠ Recomputed from the union of claims and reconciled to the source balance — a copied balance carries an | Must | Demonstration |
| FR-22 | Mid-year cutover handled Plan-year-to-date balances continue without reset. ⚠ A reset is a member paying a deductible twice. | Must | Test |
| FR-23 | Family and individual accumulation Both tiers reproduced, including cross-application rules | Must | Test |
| FR-24 | Coordination of benefits Primacy determination, order of benefits and secondary calculation reproduced | Must | Test |
| FR-25 | COB information retained Other-coverage records migrate with the member. ⚠ Losing them makes the plan primary by default and overpays. | Must | Inspection |
| FR-26 | Pended claims disposition Every pended claim either resolved before cutover or migrated with its pend reason and age intact. ⚠ The regul | Must | Test |
| FR-27 | Open appeals complete where they started ⚠ A case completes in the system that opened it, with its evidence and correspondence. Statutory timeframes co | Must | Test |
| FR-28 | In-flight payment cycles A payment run initiated before cutover completes before cutover. ⚠ No payment cycle spans the boundary. | Must | Test |
| FR-29 | Adjustments and recoveries in progress Migrate with their linkage to the original claim | Must | Test |
| FR-30 | Submission freeze and drain Defined quiet window; submissions received during it queue and process after, with receipt dates preserved | Must | Analysis |
| FR-31 | Post-cutover claims to the surviving platform only ⚠ Including claims for services rendered before the cutover date | Must | Test |
| FR-32 | Explanation of benefits content preserved Regulated content reproduced. ⚠ A change is a filed change, not a design choice. | Must | Test |
| FR-33 | Trading partner re-registration Each partner re-registered and test-exchanged before their channel moves | Must | Inspection |
| FR-34 | Payer identifier transition Old and new identifiers both accepted through a defined window | Must | Analysis |
| FR-35 | Business-level acknowledgment ⚠ Every EDI interface carries a control total. A syntactic acknowledgment is not acceptance. | Must | Test |
| FR-36 | 835 reconciles to payment issued Across both paying platforms during coexistence | Must | Demonstration |
| NFR-01 | Adjudication throughput Combined daily volume within the existing processing window, with headroom | Must | Analysis |
| NFR-02 | Eligibility response ⚠ Real-time at the point of care. Latency here is a member turned away at a pharmacy counter. | Must | Analysis |
| NFR-03 | Availability Tier 0. Recovery objectives per the Quality Plan, restore tested. | Must | Demonstration |
| NFR-04 | Auditability Every adjudication reproducible with the configuration version that produced it | Must | Audit |
| NFR-05 | Cutover window ⚠ One weekend. No rollback after the payment cycle resumes. | Must | Analysis |
06 — BRD-03 Integration Layer & Interfaces (29 requirements · owner K. Stallworth)
| Req ID | Requirement (from BRD-03) | Priority | Verification method |
|---|---|---|---|
| FR-01 | One canonical representation per entity Member, coverage, provider, claim, authorization, accumulator. Each platform maps to and from it. | Must | Test |
| FR-02 | Canonical model is versioned ⚠ A change is a versioned change with a migration path, not an edit | Must | Inspection |
| FR-03 | Definitions agreed before mapping ⚠ "Member", "coverage period", "final" and "closed" are defined once and signed by both sides before any mappi | Must | Inspection |
| FR-04 | No business logic in the layer ⚠ It translates and routes. A rule that decides something belongs in a system of record, and a request to add | Must | Test |
| FR-05 | Mapping is declarative and inspectable A reader can determine what a field becomes without reading code | Must | Test |
| FR-06 | Unmapped fields fail loudly ⚠ An unmapped field is an error, not a silent null | Should | Test |
| FR-07 | Guaranteed delivery No message lost. Delivery confirmed by the receiving system, not by the layer. | Must | Test |
| FR-08 | Idempotency ⚠ A message delivered twice produces the same result as once. Retry is the primary recovery mechanism and it i | Must | Test |
| FR-09 | Ordered delivery where order matters Accumulator and coverage changes are order-sensitive; provider updates are not. Stated per interface. | Must | Test |
| FR-10 | Business-level control totals ⚠ Every interface reconciles on counts and amounts. A syntactic acknowledgment is not acceptance — a pip | Must | Demonstration |
| FR-11 | Replay within a bounded window Messages replayable for a defined period. ⚠ Bounded deliberately — an unbounded store is a data store, a | Must | Demonstration |
| FR-12 | Failures alert with context Which interface, which record, which side, what failed. Not a generic error. | Must | Test |
| FR-13 | Accumulator synchronization is near real time ⚠ Latency here is a wrong member liability quoted at the point of service | Must | Analysis |
| FR-14 | Accumulator conflicts resolved by recomputation ⚠ Not by last-writer-wins. Both sides' claims are summed; the balance is derived, never chosen. | Must | Test |
| FR-15 | Write-back failures surface on both sides ⚠ A failed write into the retiring platform must alert both systems' operators | Must | Test |
| FR-16 | Write-back is reconciled daily Independent comparison of what should have been written against what is present | Must | Audit |
| FR-17 | Registered consumer list ⚠ Every consumer registers at connection time. An interface with unknown consumers cannot be switched off. | Must | Inspection |
| FR-18 | Traffic observable per interface per consumer Volume by consumer, so zero traffic can be evidenced rather than assumed | Must | Analysis |
| FR-19 | Retirement is evidenced by zero traffic ⚠ A defined quiet period with no traffic from any registered consumer — not a belief that nothing uses i | Must | Inspection |
| FR-20 | Interface-level shutdown Interfaces retire individually. ⚠ The layer is not all-or-nothing. | Must | Test |
| FR-21 | No persistent store beyond the replay window ⚠ State makes the layer a system of record, and a system of record cannot be deleted | Must | Analysis |
| FR-22 | New business rules are refused ⚠ A change request adding logic to the layer is rejected and redirected to the owning system, with the refusal | Must | Inspection |
| FR-23 | Decommissioning documented per interface What it did, what replaced it, when traffic stopped | Should | Inspection |
| NFR-01 | Eligibility response latency ⚠ Within the point-of-service window. This sits in front of a pharmacy counter. | Must | Analysis |
| NFR-02 | Accumulator propagation Near real time, measured end to end rather than at the layer boundary | Must | Test |
| NFR-03 | Throughput Peak daily claim and enrollment volume with headroom for catch-up after an outage | Must | Analysis |
| NFR-04 | Availability Tier 1. ⚠ An outage does not lose messages — it delays them. | Must | Test |
| NFR-05 | Security Encrypted in transit and at rest; PHI never logged in clear | Must | Test |
| NFR-06 | Observability Per-interface, per-consumer volume and error rates, retained through retirement | Must | Inspection |
07 — BRD-04 Enterprise Data Warehouse (37 requirements · owner Dr. A. Ravindran)
| Req ID | Requirement (from BRD-04) | Priority | Verification method |
|---|---|---|---|
| FR-01 | One definition per measure, signed by both entities ⚠ Member month, covered life, paid claim, incurred date, allowed amount. Agreed and signed before the model is | Must | Inspection |
| FR-02 | Conformed member dimension Keyed on the enterprise member identifier, with both source identifiers retained | Must | Inspection |
| FR-03 | Conformed provider dimension ⚠ A provider contracted with both entities is one provider with two contracts, not two providers | Must | Test |
| FR-04 | Conformed date dimension Service, incurred, paid and processed dates distinguished. ⚠ Reports must state which they use. | Must | Test |
| FR-05 | Slowly changing dimensions Member, provider and benefit attributes carry effective dating. A report as at March uses March's attributes. | Must | Test |
| FR-06 | Source system lineage Every fact traceable to its source system and load | Must | Inspection |
| FR-07 | Business glossary published Definitions visible to consumers, not held in the model only | Should | Inspection |
| FR-08 | Both histories loaded Claims and enrollment history from both entities for the statutory retention period | Must | Test |
| FR-09 | History restated to conformed definitions ⚠ Prior periods recomputed on the agreed definitions, so a trend line crossing the merge is comparable | Must | Test |
| FR-10 | Pre-merge and post-merge distinguishable A consumer can always separate the combined view from either legacy view | Must | Test |
| FR-11 | Restatement is documented and dated ⚠ Any restated figure carries the basis and the date of restatement | Must | Inspection |
| FR-12 | Archive retrievable after source retirement ⚠ The retiring platform's history survives the platform. It is loaded, not referenced. | Must | Test |
| FR-13 | Measure calculation to specification Quality measures computed to the accrediting body's published specification, not to a local interpretation | Must | Test |
| FR-14 | Measurement year integrity ⚠ A measurement year is not switched mid-cycle. Cutting over mid-year invalidates the rates for that year. | Must | Test |
| FR-15 | Submission-ready extracts In the regulator's required format, with the audit trail supporting each figure | Must | Audit |
| FR-16 | Reproducibility ⚠ A filed figure can be reproduced later from retained data and the calculation version that produced it | Must | Inspection |
| FR-17 | Combined-entity reporting from the first full cycle No cycle reported on a partial population without disclosure | Must | Test |
| FR-18 | Load reconciliation Record counts and financial totals reconciled to source on every load | Must | Demonstration |
| FR-19 | A failed load does not partially publish ⚠ Either the load completes and reconciles, or the prior state stands. A half-loaded warehouse produces confid | Must | Demonstration |
| FR-20 | Late-arriving data handled Claims received after a period closes update the period and are flagged as restating it | Must | Test |
| FR-21 | Completeness monitoring Expected versus received volume per source per day, alerting on absence rather than only on error | Must | Analysis |
| FR-22 | Data quality dashboard Visible to consumers, so a report's reliability is knowable without asking | Should | Test |
| FR-23 | Documented RTO and RPO agreed with the business owner and recorded in the Quality Plan | Must | Inspection |
| FR-24 | Geo-redundant backup configured to the Azure paired region | Must | Test |
| FR-25 | Immutable or soft-delete protection against ransomware and accidental deletion | Must | Test |
| FR-26 | ⚠ Business associate agreement confirmed to cover the backup location and secondary region | Must | Test |
| FR-27 | Full restore tested end to end, with evidence retained for audit | Must | Audit |
| FR-28 | DR runbook with named roles and a named accountable owner | Must | Inspection |
| FR-29 | Recovery obligations carried in the risk register with a residual rating | Must | Inspection |
| FR-30 | Retention of seven years, above the HIPAA floor, driven by state insurance record rules. Restore re-tested annually. | Must | Test |
| NFR-01 | Load window Daily load completes and reconciles before the reporting day begins | Must | Demonstration |
| NFR-02 | Query performance Standard measure calculations complete within the reporting cycle | Must | Analysis |
| NFR-03 | Availability Tier 2 — ⚠ 72 hour RTO. Deliberately not Tier 0; see the opening callout. | Must | Demonstration |
| NFR-04 | Durability ⚠ 24 hour RPO with geo-redundancy. This, not availability, is the binding requirement. | Must | Test |
| NFR-05 | Data residency United States only, enforced by platform policy | Must | Test |
| NFR-06 | Access control Role-based; ⚠ identified member data restricted to roles with a documented need | Must | Inspection |
| NFR-07 | Audit logging Write-once. Query access to identified data logged and reviewed. | Must | Audit |
08 — BRD-05 Preserved & Best-of-Both Capabilities (30 requirements · owner Dr. M. Ellsworth)
| Req ID | Requirement (from BRD-05) | Priority | Verification method |
|---|---|---|---|
| FR-01 | Performance baselined and reported ⚠ Readmission and chronic-condition engagement rates baselined pre-close and reported quarterly. Preservation | Must | Analysis |
| FR-02 | No member migrated mid-episode ⚠ An open care management episode completes on the platform that opened it | Must | Test |
| FR-03 | ACME members onboarded, not target members moved The platform is preserved and extended. ACME's population migrates to it. | Must | Test |
| FR-04 | Care manager team retained ⚠ The platform without the people is not the capability. Retention coverage for the clinical leads is a requir | Must | Inspection |
| FR-05 | Named owner and budget line post-program ⚠ A preserved system with no owner and no budget degrades by default. Both named before program close. | Must | Inspection |
| FR-06 | Vendor support and version currency maintained ⚠ A preserved platform must not fall out of supported versions while attention is elsewhere | Must | Inspection |
| FR-07 | Member feed from the surviving core platform IF-09. Enrollment, coverage and claims context for the combined population | Must | Test |
| FR-08 | Clinical protocols documented What makes the program work is written down rather than held by the team that runs it | Should | Inspection |
| FR-09 | Target's clinical criteria configuration retained Criteria sets, review pathways and escalation rules | Must | Inspection |
| FR-10 | ACME's authorization workflow retained Intake, routing, turnaround management and provider portal integration | Must | Inspection |
| FR-11 | The seam is specified, not discovered ⚠ Exactly where criteria hand off to workflow, defined and documented. Best-of-both fails at the join, not at | Must | Inspection |
| FR-12 | Turnaround times preserved Regulatory decision timeframes met throughout. ⚠ A slower authorization is a member access problem. | Must | Test |
| FR-13 | Authorization status available to both platforms IF-08. A claim adjudicating on either side can see the authorization | Must | Test |
| FR-14 | Single provider-facing experience ⚠ A provider should not need to know which entity a member came from | Should | Test |
| FR-15 | Both service platforms operate to Day 100 No member-visible change to how they contact their plan in the first hundred days | Must | Test |
| FR-16 | Agents can serve either population ⚠ Read access across both, so a member reaching the wrong number is helped rather than transferred | Must | Test |
| FR-17 | The Day 100 decision has evidence and a decider ⚠ Absorb or extend, decided on the date by a named owner against stated criteria. Deferral is a decision and i | Must | Inspection |
| FR-18 | Portal migration sequenced after ID card reissue ⚠ Members are not asked to change portal and card in the same period | Must | Test |
| FR-19 | Contact history migrates with the member An agent sees prior contacts regardless of which platform recorded them | Must | Inspection |
| FR-20 | Single knowledge base Agents work from one source, even while two systems run | Should | Test |
| FR-21 | Combined-population provider analysis Cost, utilization and quality across both books on conformed definitions | Must | Test |
| FR-22 | Overlap identified Providers contracted with both entities, with both rate structures visible | Must | Test |
| FR-23 | Renewal-dated action ⚠ Rate alignment happens at contract renewal. A renewal date is a constraint, not a target. | Must | Test |
| FR-24 | Network adequacy maintained ⚠ Regulatory adequacy tested before any termination. Rationalization may not create a gap. | Must | Analysis |
| FR-25 | Provider-facing change minimized A provider experiences one change, not one per system | Should | Test |
| NFR-01 | Care management availability Tier 1. ⚠ Clinical staff work in it during business hours; an outage is deferred care. | Must | Test |
| NFR-02 | Authorization turnaround Within regulatory decision timeframes, measured end to end across the seam | Must | Test |
| NFR-03 | Member service response Existing service levels maintained through coexistence | Must | Test |
| NFR-04 | Clinical data handling ⚠ Care management data is clinical PHI. Access restricted beyond standard member data. | Must | Test |
| NFR-05 | Preserved platform currency ⚠ Within vendor-supported versions at all times. Tracked, not assumed. | Must | Inspection |
09 — Traceability gaps, recorded not hidden
| Ref | Gap | Why it matters |
|---|---|---|
| G-01 | No BRD covers organizational change, communications or retention | ⚠ Those are managed through plans 17, 18 and 19 rather than as requirements. Deliberate — they have owners and measures, but no testable acceptance criteria, and forcing them into a requirements format would produce statements nobody could verify. |
| G-02 | Finance, HR and facilities consolidation have no BRD | Straight absorption onto existing ACME platforms with no configuration decisions of consequence. ⚠ Recorded so the absence is a judgment rather than an oversight. |
| G-03 | Requirements for the retiring platforms' decommissioning are thin | Covered by BRD-02 acceptance criterion 8 and the wave plan. ⚠ A decommissioning that is one line in someone else's acceptance criteria is the shape of work that slips. |
| G-04 | BRD-05 FR-01 depends on a baseline set by the party being measured | ⚠ Unavoidable — only Cumberland Valley holds the pre-transaction clinical data. Mitigated by the baseline being signed by both medical officers rather than accepted. |
| G-05 | No requirement covers what happens if identity resolution overruns | ⚠ The single largest schedule risk on the program has no requirement, because it is a risk rather than a requirement. It sits in the risk register as R-01 with a named owner. Recorded here because a reader tracing schedule exposure through this matrix will not find it. |
G-05 is the one to read twice. The largest schedule exposure on this program — that member identity resolution proves materially harder than the deal model assumed — appears nowhere in this matrix, because it is a risk rather than a requirement. The requirements say what the system must do; they cannot say how long it will take when the volume is unknown. ⚠ It is owned in the risk register with a named owner and an active mitigation, which is the right place for it. But a reader tracing program exposure through a traceability matrix would find complete coverage and conclude, wrongly, that the exposure is covered. That is exactly why the gaps section exists.
10 — How to read this against the program
| Question | Where this matrix answers it |
|---|---|
| Is every requirement verified? | §02 — requirements traced equals requirements written, per BRD |
| How is it verified? | §03 and the method column in each BRD section |
| What is verified by someone independent? | ⚠ The Audit rows — and only those |
| What is not covered? | §09, including one gap that is a risk rather than a requirement |
| Where is the design that satisfies a requirement? | The traceability section inside each BRD, which names the design artifact and the evidence |
The useful test to run on this matrix, and the one an interviewer might: pick any requirement and follow it forward. It should reach a named design artifact, a verification method, a person who owns the evidence, and an acceptance criterion that says what "done" looks like. Where that chain breaks, the break is either recorded in §09 or it is a defect in the suite — and either answer is more useful than a matrix that only demonstrates that a matrix was produced.
Related artifacts: BRD-01 · BRD-02 · BRD-03 · BRD-04 · BRD-05 · 26 — Quality Plan · 28 — Risk Register