Data Foundations Roadmap
| Document field | Value |
|---|---|
| Version | 0.1 |
| Status | Working baseline; not yet approved |
| Last updated | 2026-08-25 |
| Format | Living Markdown document maintained in Git |
| Delivery system of record | Azure DevOps (ADO) |
| Planning source | Froggware Data Docs Repository |
Table of contents
- 1. Executive program description
- 2. Work packages
- 3. Planned sprints
- 4. Delivery-item catalogue
- 5. Document change log
- Appendix A: Program goals
- Appendix B: Roadmap review, additions, and approval
- Appendix C: Delivery gates
- Appendix D: Current planning uncertainties
1. Executive program description
The program's high-level goal is to replace the existing data warehouse with authoritative, governed data products while establishing reusable delivery capabilities, accountable ownership and stewardship, observable quality, and the approved target level of Data Governance maturity. The program organizes its intended value around Clarity in definitions and accountability, Quality in products and controls, Measurement of delivery and outcomes, and Management that establishes future monitoring and optimization so improvements in Data Governance are sustained. Superseded products and unapproved copies will be decommissioned as governed replacements become operational.
At a high level, the program includes the living roadmap and delivery backlog; prioritized regulatory, mortgage, sales, broker, deposit, and accounting data areas; the complete source products required by approved products; reusable data-engineering, testing, validation, lineage, catalogue, observability, and governance capabilities; product-level ownership and steward enablement; and controlled transition from legacy products to governed replacements.
The program does not include broader development-process improvement, enterprise change management, general source-remediation and data-quality-issue processes, creation of enterprise governance processes, responsible-AI processes, or delivery of the separately managed data-retention program. These may appear as external dependencies where they affect Data Foundations.
The program methodology will have each data product flow through specific steps:
- Research: inspect existing code, lineage, data, designs, documentation, and operational evidence to identify current behaviour, dependencies, uncertainties, and draft requirements that business participants can review.
- Design: confirm material requirements and outcomes with accountable participants; resolve architecture, governance, ownership, control, test, and operating decisions; and define work with sufficient evidence and acceptance expectations for development.
- Develop: build the approved reusable capabilities and dependency-ready data products, including automated requirements and quality tests, documentation, metadata, observability, and the evidence needed for review.
- Deliver: deploy and validate the product, obtain applicable approval, transfer ownership and controls into operation, communicate the release, measure outcomes, cut consumers over, and decommission superseded legacy products before progressing through the next ready roadmap priorities.
Detailed goals and their current certainty are maintained in Appendix A.
2. Work packages
The roadmap progresses from Planning into reusable Technical Capabilities, then Core Regulatory and Core Finance delivery. Later work packages remain TBD until planning evidence supports their definition.
| Short name | Work package | High-level description | Known dependencies or sequencing |
|---|---|---|---|
Planning |
Phase 1 — Planning | Establish the roadmap, program governance and engagement models, planning confidence, requirements and backlog, and the architecture and process basis for delivery. | Begins before September 2026 and is expected to take four to six weeks. Delivery may begin on September 30 or October 14, subject to the externally governed executive-approval gate and backlog readiness. |
Technical Capabilities |
Technical Capabilities | Establish the reusable governance and development capabilities needed to deliver, validate, operate, and improve governed data products. | Begins through Planning and enables Core Regulatory delivery. Includes the Data Governance Tooling and Platform Standards work packages. |
Data Governance Tooling |
Data Governance Tooling | Establish the tooling and supporting capabilities for ownership, stewardship, catalogue, lineage, classification, data quality, issue management, evidence, dashboards, approvals, and required integrations. | A Technical Capabilities work package. Its exact contents are determined through the Data Governance Tooling definition and must support governed product delivery and operation. |
Platform Standards |
Platform Standards | Establish development-related coding and AI standards, change-management and code-promotion processes, unit-testing expectations, and related engineering practices and controls. | A Technical Capabilities work package. Standards must be defined sufficiently to guide Core Regulatory development. |
Core Regulatory |
Core Regulatory | Deliver RESL, then Full Warehouse, then TBSM, plus the complete source products required by each. | Follows sufficient Technical Capabilities. Required source products precede only the products that depend on them; exact dependencies remain subject to evidence. |
Core Finance |
Core Finance | Deliver the next finance-oriented data products and capabilities confirmed through planning. | Follows Core Regulatory; exact contents, ordering, and dependencies remain to be defined. |
TBD |
Later work packages | Hold the place for later work packages until their scope and sequence are supported by accepted planning evidence. | Follows Core Finance at this level of the roadmap; decomposition remains TBD. |
The data-retention program is parallel and outside this roadmap's delivery scope. Coordination points and dependencies with it remain to be defined.
Phase 1 Planning timeline
Phase 1 Planning is a planning and engagement period. It does not itself deliver production data products or platform capabilities. Requirements, backlog, data-architecture, and platform-architecture work continue until the Phase 2 entry conditions are met.
| Period | Dates | Focus and intended outcomes |
|---|---|---|
| Timeline establishment | By 2026-08-21 | Establish and communicate the Phase 1 timeline. |
| Week 1 | 2026-08-31 through 2026-09-04 | BDO, the Data Foundations program lead, and Wade Campbell discuss the program-governance model, confirm the high-level roadmap, and draft the executive presentation. |
| Week 2 | 2026-09-07 through 2026-09-11 | Kick off Phase 1; reach out to Domain Owners and stakeholders; meet with Credit, Finance, and Operations leaders Don Keefer, Leona Lansing, and Jim Harper to establish the engagement model, communications, and project expectations; begin executive-presentation review with VP Transformation and Executive Sponsor Charlie Skinner; begin detailed requirements gathering from existing code and designs; and begin environment-architecture and delivery-process discussions with BDO and internal technical leads. Hold recommended follow-up meetings with managers or team leads near the end of the week or early in Week 3. |
| Week 3 | 2026-09-14 through 2026-09-18 | Continue detailed requirements and backlog generation; complete recommended follow-up engagement with managers and team leads and begin engaging SMEs for requirements confirmation; and continue environment, data, and platform architecture and process discussions with BDO and internal technical leads. |
| Week 4 | 2026-09-21 through 2026-09-25 | Seek executive approval of the roadmap, intended spend, and Phase 2 delivery; continue backlog generation, requirements confirmation, and architecture work. |
| Week 5 | 2026-09-28 through 2026-10-02 | If executive approval and backlog readiness are sufficient, begin Phase 2 delivery in 2026-Q3-S7 on September 30. Otherwise, continue requirements confirmation, backlog generation, and data/platform architecture work. |
| Week 6 | 2026-10-05 through 2026-10-09 | If the longer engagement is required, continue preparation and close remaining requirements, backlog, architecture, process, and delivery-readiness gaps. |
| Final contingency | 2026-10-12 through 2026-10-13 | Close any remaining preparation gaps before the next available delivery sprint, 2026-Q4-S1, begins on October 14. |
Executive approval is a hard gate for Phase 2 delivery. The responsible executives and program participants determine and communicate whether that gate has passed; this roadmap records the gate and the resulting delivery timing but does not govern or infer the approval decision.
Phase 1 contracted deliverables
All three deliverables must be provided in an agreed format, reviewed with relevant Froggware stakeholders, updated for feedback within Phase 1 scope, and accompanied by recorded unresolved assumptions, dependencies, decisions, risks, or readiness gaps with an owner or follow-up action.
| Deliverable | Required outcome | Minimum acceptance summary |
|---|---|---|
| Transformation Roadmap | A 1-to-3-year view of intended transformation at the known level of granularity, with the first three months sequenced at approximately monthly granularity, anticipated Froggware resource requirements, target release months, and an initial 90-day execution plan. | Sequence the first three months of known priorities; identify material datasets, platform components, reports, and governance capabilities with target months; identify participation and major dependencies; record assumptions, risks, decisions, and gaps; support executive review and high-level resource planning. |
| Program Delivery Model | Operating model and POD design for defining, approving, accepting, governing, resourcing, and commercially controlling Data Foundations work. | Define roles, responsibilities, decision rights, escalation, intake-to-release process, funding/estimate/budget/forecast and cost/resource-burndown tracking, Steering Committee reporting, dependencies, resource-scaling triggers, and owned follow-up for unresolved items. |
| Development Backlog | Prioritized backlog and sprint plan establishing executable scope for the future delivery phase and provisional work expected to follow. | Identify at least four weeks of development-ready work and at least four additional weeks of provisional work; include inputs, business logic, outcomes, applicable unit-test scenarios, and mutually agreed estimates for ready items; state what provisional items still need; record dependencies and owned readiness gaps. |
The Phase 1 executive readout validates the current-state findings, target direction, roadmap, delivery model, commercial controls, assumptions, dependencies, and prioritized backlog. The Go/No-Go outcome identifies what is recommended for a future backlog-driven delivery engagement and what remains deferred or unresolved. Acceptance does not authorize implementation; future delivery requires separate written authorization, SOW/PO funding, and completion of required security and privacy onboarding.
3. Planned sprints
Delivery sprints run for two weeks from Wednesday through Tuesday and use the ADO-aligned name YYYY-Q#-S#. Phase 2 delivery may begin with 2026-Q3-S7 on Wednesday, September 30, 2026 if executive approval and backlog readiness are sufficient. Otherwise, the planned start moves to 2026-Q4-S1 on Wednesday, October 14, 2026 while Phase 1 preparation continues. Sprints are listed with the newest or furthest-planned entry first and the oldest or first entry last. Allowed status values are:
tentative: proposed content, timing, or cost that has not been approved;approved: the authorized sprint plan; andactual: the sprint record updated to reflect what was delivered and spent.
When a delivery item is not completed in its assigned sprint, its active planned assignment is moved to the next planned sprint until it is delivered. The change log and Git history retain the former plan.
| Sprint | Timeline | Status | Focus | Planned delivery items | Cost |
|---|---|---|---|---|---|
| 2026-Q4-S6 | 2026-12-23 through 2027-01-05 | tentative | TBD based on backlog readiness and results from preceding sprints. | TBD; undelivered items from S5 move here when applicable. | TBD |
| 2026-Q4-S5 | 2026-12-09 through 2026-12-22 | tentative | TBD based on backlog readiness and results from preceding sprints. | TBD; undelivered items from S4 move here when applicable. | TBD |
| 2026-Q4-S4 | 2026-11-25 through 2026-12-08 | tentative | TBD based on backlog readiness and results from preceding sprints. | TBD; undelivered items from S3 move here when applicable. | TBD |
| 2026-Q4-S3 | 2026-11-11 through 2026-11-24 | tentative | TBD based on backlog readiness and results from preceding sprints. | TBD; undelivered items from S2 move here when applicable. | TBD |
| 2026-Q4-S2 | 2026-10-28 through 2026-11-10 | tentative | Continue the highest-priority development that is sufficiently defined and dependency-ready. | TBD; undelivered items from S1 move here when applicable. | TBD |
| 2026-Q4-S1 | 2026-10-14 through 2026-10-27 | tentative | Begin Phase 2 delivery if the September 30 gate was not met; otherwise continue the highest-priority development that is sufficiently defined and dependency-ready. | TBD after Planning research, work definition, dependency confirmation, and the result of 2026-Q3-S7 when applicable. |
TBD |
| 2026-Q3-S7 | 2026-09-30 through 2026-10-13 | tentative | Earliest possible Phase 2 start, conditional on executive approval and sufficient backlog readiness; otherwise this remains a planning period rather than a delivery sprint. | TBD after Planning research, work definition, dependency confirmation, and gate outcome. | TBD |
No sprint has yet been recorded as approved or actual in this roadmap.
Phase 1 Planning establishes sufficient program, architecture, dependency, and backlog confidence for Phase 2. It continues until the external executive-approval gate and backlog-readiness conditions are met; possible Phase 2 starts are 2026-Q3-S7 on September 30 and, if additional preparation is required, 2026-Q4-S1 on October 14.
4. Delivery-item catalogue
This catalogue grows as capabilities, reports, products, and other deliverables become sufficiently defined. An ADO feature link is added when the authoritative feature exists. TBD — not linked means the need is known but no authoritative feature link has been confirmed in this roadmap.
| Delivery item | Kind | Business-value / architectural area | High-level outcome | Priority or timing | ADO feature |
|---|---|---|---|---|---|
| Target governance maturity | Governance capability | Cross-domain governance | Approved, observable program terminal maturity and assessment method. | Cross-cutting | TBD — not linked |
| Requirements-confirmation escalation | Delivery-enablement capability | Cross-domain program delivery | Delayed requirements decisions, examples, validation, or feedback are time-boxed, evidenced, routed, and escalated, including when the accountable business participant is uncertain or unavailable. | Required for product definition and validation | TBD — not linked |
| Data Governance Tooling | Governance capability | Technical Capabilities | Tooling and supporting capabilities provide ownership, stewardship, catalogue, lineage, classification, data quality, issue management, evidence, dashboards, approvals, and required integrations. | Cross-cutting | TBD — not linked |
| Data Steward training program | Training capability | Cross-domain governance | Stewards are prepared to validate products, manage rules, handle sensitive data, and participate in escalation and operational ownership. | Cross-cutting | TBD — not linked |
| Transformation test scenarios and results dashboard | Engineering capability | Cross-domain platform | Transformation logic is unit-tested against scenarios and results are visible to users. | Required for first product | TBD — not linked |
| Platform Standards | Delivery-enablement capability | Technical Capabilities | Coding and AI standards, change-management and code-promotion processes, unit-testing expectations, and related development controls are agreed and applied through the relevant repository guidance and workflows. | Phase 1 planning priority; implementation timing TBD | TBD — not linked |
| Steward-defined output validation | Data-quality capability | Cross-domain platform | Custom queries apply steward-defined rules to produced data and expose validation results. | Required for first product | TBD — not linked |
| Shared data-product controls | Engineering capability | Cross-domain platform | Versioning, cataloguing, lineage, observability, and reusable controls support governed products. | Cross-cutting; decomposition TBD | TBD — not linked |
| Cross-domain data contracts | Engineering and governance capability | Cross-domain products | Producer and consumer obligations for meaning, schema, timeliness, quality, lineage, access, approved use, and change notification are explicit and monitorable. | Required as cross-domain products are defined | TBD — not linked |
| Exception and product-status reporting | Reporting capability | Cross-domain platform and program delivery | Users and accountable participants can see product quality, test and exception status, platform function, and delivery progress. | Required for first product; decomposition TBD | TBD — not linked |
| Current-to-target staging bridge | Platform-transition capability | Cross-domain platform | Products can transition between current and target environments under controlled staging, comparison, and cutover conditions. | Dependency driven | TBD — not linked |
| WB Qlik-to-Snowflake integration | Candidate integration | Cross-domain platform | Confirm and deliver the required integration between WB Qlik workloads and Snowflake. | Priority and current applicability TBD | TBD — not linked |
| Production-environment consolidation | Candidate migration work | Cross-domain platform | Remove unnecessary duplicated production environments while sustaining required product delivery and controls. | Sequence TBD | TBD — not linked |
| Historical-data reconciliation | Candidate migration and validation work | Cross-domain platform and products | Reconcile required historical data across legacy and replacement environments with retained evidence of material differences. | Per-product or shared scope TBD | TBD — not linked |
| Ontologies and data-product identification | Architecture feature | All accepted architectural areas | Define the shared approach, five area ontologies, tentative product inventories, dependencies, research spikes, and candidate delivery work. | Planning priority | TBD — not linked |
| Partner data mart | Candidate source data product | Core regulatory | Provide cleansed, identified, or calculated partner inputs required by RESL where dependency research confirms them. | Before the dependent RESL scope only | TBD — not linked |
| Credit data mart | Candidate source data product | Core regulatory | Provide cleansed, identified, or calculated credit inputs required by RESL where dependency research confirms them. | Before the dependent RESL scope only | TBD — not linked |
| Mortgage Application | Candidate source data product | Core regulatory; Mortgages | Provide governed mortgage-application inputs required by RESL where dependency research confirms them. | Before the dependent RESL scope only | TBD — not linked |
| Mortgage Transaction | Candidate source data product | Core regulatory; Mortgages | Provide governed mortgage-transaction inputs required by RESL where dependency research confirms them. | Before the dependent RESL scope only | TBD — not linked |
| Mortgage Portfolio | Candidate source data product | Core regulatory; Mortgages | Provide governed mortgage-portfolio inputs required by RESL where dependency research confirms them. | Before the dependent RESL scope only | TBD — not linked |
| RESL | Regulatory report/data product | Core regulatory | Rebuild the highest-priority regulatory product using governed source data products. | Product priority 1a | TBD — not linked |
| Full Warehouse | Regulatory data product | Core regulatory | Rebuild the next prioritized core regulatory product and its confirmed dependencies. | Product priority 1b | TBD — not linked |
| RMUP | Candidate board-reporting product | Core regulatory | Reuse confirmed Full Warehouse foundations while separately defining, validating, productionizing, approving, and operating RMUP. | Priority and dependency confirmation TBD | TBD — not linked |
| Credit Exception | Candidate board-reporting product | Core regulatory | Reuse applicable Full Warehouse or RMUP foundations while remaining a separately validated and operated product. | Priority and dependency confirmation TBD | TBD — not linked |
| TBSM | Regulatory report/data product | Core regulatory; Deposits; Accounting | Rebuild the third prioritized core regulatory product and establish its confirmed cross-area dependencies. | Product priority 1c | TBD — not linked |
| Mortgage and mortgage-pipeline products | Product group; decomposition TBD | Mortgages | Deliver governed mortgage data and pipeline metrics after product definition. | Product priority 2 | TBD — not linked |
| Sales and broker products | Product group; decomposition TBD | Sales and Broker | Deliver governed sales and broker metrics after product definition. | Product priority 3 | TBD — not linked |
| Deposits products | Product group; decomposition TBD | Deposits | Define and deliver deposits products beyond any confirmed TBSM needs. | Priority TBD | TBD — not linked |
| Accounting products | Product group; decomposition TBD | Accounting | Define and deliver accounting products beyond any confirmed TBSM needs. | Priority TBD | TBD — not linked |
| Legacy-product decommissioning | Operational delivery | Per product | Remove superseded warehouse products and unapproved copies after governed replacement and cutover. | Per-product final gate | TBD — not linked |
The Partner and Credit data marts and the Mortgage Application, Mortgage Transaction, and Mortgage Portfolio products are candidate RESL dependencies, not yet confirmed delivery scope. Detailed lineage and code investigation must determine the minimum complete source-product work needed before RESL development and how the named candidates relate to one another. RMUP, Credit Exception, and the named integration and migration work are also candidates rather than approved scope; their current applicability, priority, and dependencies require confirmation.
5. Document change log
Git history is the authoritative archive of document versions. Version and change-log entries are updated when the roadmap is ready to be committed, using the differences between the preceding and new commits to summarize material changes. Edits made while preparing the initial commit remain version 0.1; version 0.2 is created only when the roadmap is ready for its second committed revision.
| Date | Version | Change | Approval state |
|---|---|---|---|
| 2026-08-13 | 0.1 | Established the initial roadmap structure and populated confirmed objectives, goals, work packages, tentative planning increments, delivery candidates, gates, and known uncertainties. | Working baseline; not yet approved |
Appendix A: Program goals
This table is intentionally extensible. Goals will be added or refined as planning tasks and approved architectural work produce new evidence.
Within this roadmap, Management means establishing the ownership, operating evidence, monitoring, review, and optimization needed to sustain and improve Data Governance after initial delivery. It does not mean routine project administration.
| ID | High-level goal | Primary values | Expected evidence or outcome | Current certainty |
|---|---|---|---|---|
| G01 | Establish a single living program roadmap | Clarity; Management | Versioned roadmap connects objectives, priorities, work packages, sprint intentions, delivery items, and ADO features. | Confirmed |
| G02 | Replace the existing warehouse with governed data products | Clarity; Quality | Required legacy capabilities are rebuilt as authoritative domain-oriented products and superseded copies are decommissioned. | Confirmed; detailed product inventory TBD |
| G03 | Begin product development from sufficiently confirmed work | Clarity; Quality | Explicit requirements, examples, dependencies, acceptance evidence, and reusable delivery capabilities give product work sufficient confidence to enter development. | Confirmed outcome; supporting method handled separately |
| G04 | Deliver prioritized regulatory data products | Quality | RESL, Full Warehouse, and TBSM are delivered in that order, with only their required source products completed ahead of them; RMUP and Credit Exception are incorporated when their priority and dependencies are confirmed. | Core sequence confirmed; related-product scope TBD |
| G05 | Extend trusted data products into additional value areas | Management | Mortgages and mortgage pipeline, then sales and broker metrics, are addressed after core regulatory work; Deposits and Accounting are retained as areas for definition. | Confirmed at area level |
| G06 | Achieve the approved target Data Governance maturity | Clarity; Quality; Measurement; Management | Cross-domain measures, proactive issue identification, accountable owners and stewards, sensitive-data controls, and steward training demonstrate the approved terminal state. | Direction confirmed; exact target TBD |
| G07 | Establish accountable product operation | Clarity; Management | Data Owners approve reports and products; Domain Owners and Data Stewards/SMEs take operational responsibility as products complete; the Data Department owns technical platform functions. | Confirmed |
| G08 | Make transformation and produced-data quality observable | Quality; Measurement | Transformation scenarios and unit tests are dashboarded for users, and steward-defined queries validate produced data. | Confirmed capability need |
| G09 | Measure program throughput and data quality | Measurement; Management | Delivery throughput and quality measures are reported; budget and capacity remain program-management inputs rather than transformation outcomes. | Confirmed; metric definitions TBD |
| G10 | Prevent delayed business feedback from silently stalling product delivery | Clarity; Management | Requirements decisions, examples, validation, and feedback are time-boxed, traceable, and escalated when accountable business participants are uncertain, unavailable, or unable to respond in time. | Confirmed boundary; capability details TBD |
Appendix B: Roadmap review, additions, and approval
The detailed process for proposing, reviewing, adding, versioning, and approving roadmap content is not yet defined.
Known decision rights are:
- Executives approve architectural areas and priorities quarterly.
- The program team manages specific deliverables and backlog decisions within approved areas.
- Data Owners approve reports and data products.
- The Data Department owns technical platform functions.
- Data Governance Operations approves the elaborated governance-maturity model and its evidence.
This appendix will later define update ownership, review cadence, change classifications, approval evidence, version-labeling rules, ADO link maintenance, and treatment of items that split, merge, close, or are superseded.
Appendix C: Delivery gates
The methodology uses four gates. Each gate confirms that the current step has produced enough evidence for the next step without implying that later product approval or governance adoption is already complete.
Research complete
Existing code, lineage, data, designs, documentation, and operational evidence have been examined sufficiently to describe current behaviour, identify material dependencies and uncertainties, and produce draft requirements or hypotheses that accountable participants can review. Evidence sources and unresolved questions are recorded. Research completion means the work is ready for Design; it does not approve the product or its requirements.
Design complete
Material requirements and intended outcomes have been confirmed with accountable participants. Applicable architecture, governance, ownership, controls, test expectations, operating responsibilities, dependencies, and acceptance evidence are defined sufficiently for development. Consequential unresolved decisions are either resolved or explicitly prevent affected work from entering Develop. Design completion is the development-readiness gate.
Develop complete
The approved product or capability has been built with its required automated tests, documentation, metadata, observability, and review evidence. This gate may unblock dependent development. Preferred evidence is explicit Data Owner approval that results are fully accurate for the agreed scope. If the Data Owner cannot identify further business-logic corrections or refinements but cannot give positive accuracy approval, passing the agreed transformation-unit and requirements tests is an acceptable fallback. Develop completion does not claim that deployment, governance adoption, operational handoff, cutover, or decommissioning is finished.
Deliver complete
This is the final governed outcome. The product has been deployed and validated, applicable approval has been obtained, release communication is complete, and ownership and controls have transferred into operation. Evidence includes steward enablement, issue handling, lineage and transformation documentation, classification, applicable data contracts, quality and performance baselines, deployment and monitoring evidence, support handoff, outcome measurement, cutover, and applicable governance controls. Superseded legacy products and unapproved copies have been decommissioned. Operations may perform decommissioning, but Deliver completion cannot be claimed while additional unapproved sources remain available.
Appendix D: Current planning uncertainties
- Precise target-governance maturity criteria, assessment units, evidence, aggregation rules, and approval record.
- Requirements-confirmation response expectations, time boxes, escalation routes, decision rights, authoritative tooling, evidence, and handling of unavailable or uncertain business participants.
- Data Governance Tooling capability scope, existing-tool reuse, authoritative systems, integrations, ownership, and resulting backlog work.
- Baseline-quality and program-measure definitions, methods, targets, ownership, and reporting cadence.
- Platform Standards for coding, AI-assisted development, change management, code promotion, testing, documentation, operation, exceptions, authoritative storage, and adoption.
- Work-definition templates, requirements-gathering tools, readiness rules, and ADO handoff conventions.
- Exact RESL, Full Warehouse, and TBSM source-product dependencies, supported by lineage and code evidence.
- The relationship among Mortgage Application, Mortgage Transaction, Mortgage Portfolio, Partner, and Credit candidate RESL dependencies.
- RMUP and Credit Exception priority, scope, and dependency relationships.
- Current applicability, decomposition, and sequencing for cross-domain data contracts, exception/status reporting, the staging bridge, WB Qlik-to-Snowflake integration, production-environment consolidation, and historical-data reconciliation.
- Exact contents, product sequence, and dependencies of Core Finance.
- Which later areas belong under the
TBDwork package and when they should be defined. - Sprint focus, capacity, costs, approval state, and committed delivery-item assignments.
- Confirmed ADO feature identifiers and links for delivery items.
- Product cutover, comparison-run, and decommissioning criteria and evidence.
- Coordination with the parallel data-retention program.
- Roadmap review, addition, version-labeling, and approval process.
- The authoritative program-charter artifact and version, and the material differences that Wade Campbell and Sloan Sabbith must reconcile with the program definition, roadmap, and overview.