SGA Dental Partners • Internal Meeting Recap

Data Architecture & Enterprise AI Strategy

Date: June 9, 2026
Present: Dakota Milner (SGA Growth); Matt Redding (Data / Full Stack Engineer)
Status: Discovery. No decisions locked.
Distribution: Internal only. Not shared with Matt.

Matt and I opened a hard look at SGA's entire data architecture: how we aggregate our disparate sources into one data warehouse, build a semantic layer on top, and activate that layer with AI inside a compliant, PHI-aware framework. This was a scoping conversation. Matt cannot give an exact recommendation until he understands our use cases, user journeys, and data sources, so the immediate next step is ours: write a requirements document. That document is the critical path.

1.What We Asked Matt to Take On

I framed the mandate as the full chain, not a single tool. We need to design and stand up:

Data flow and pipeline — how every disparate source moves and lands.
A single data warehouse — one place the portfolio's data aggregates into.
A strategic semantic layer — a governed model that defines our metrics and entities once, so AI and reporting read from the same source of truth.
An activation strategy — how we put that layer to work, with AI as the leading consumer.

Sitting over all of it, we need an enterprise AI strategy that answers four questions: how we leverage our data to create value, how we protect it inside a compliant methodology, where we build the capability and how we expose access to it, and how we handle PHI specifically given the healthcare context.

2.Matt's Read

Matt was direct that the right answer depends on inputs he does not have yet. Without a full picture of our use cases, user journeys, and source systems, any recommendation is a guess. He would rather scope it correctly than name a stack on day one.

The core trade-off

He broke the design space into two ends of a spectrum:

A robust central engine that holds everything at full depth. It gives completeness and a single source of truth, but it can be slow to query as it scales.
A dedicated reporting playground shaped specifically for querying and analysis. It is fast and clean for the people running reports, but it is another layer to build and keep in sync with the engine.

Two questions that decide the design

Altitude: at what level of aggregation do we actually consume the data? Raw and granular, or rolled up?
Refresh frequency: hourly is a fundamentally different system than nightly. If we need near-real-time, that rules whole categories of architecture in and out. If a nightly poll is enough, the build is simpler and cheaper.

The fastest path to AI value

On where AI pays off first, Matt's view was practical: build discrete agents that save time and generate insights. Narrow, purpose-built agents are the quickest route to value while the larger platform takes shape, rather than waiting for the full architecture before anyone benefits.

3.Where We Landed

Nothing is locked. What we aligned on:

Treat this as one enterprise-wide architecture effort, not a series of point fixes.
The recommendation is blocked on requirements, not on Matt's ideas. He has options in mind and needs our inputs to choose among them.
We can pursue near-term AI wins (discrete agents) in parallel with the longer architecture and governance work.

4.Open Questions to Resolve

These are the inputs Matt needs from us. They also form the spine of the requirements document.

What are all our data sources? Marketing, practice management, financial, operational, and any PHI-bearing systems.
What are the use cases and user journeys? Who consumes the data, for what decision, and how.
At what altitude do we need the data? Granular versus aggregated.
How fresh does it need to be? Hourly versus nightly, likely varying by use case.
What are the guardrails? Compliance posture, PHI handling, and who gets access to what.
Robust engine, reporting layer, or both? The answer falls out of the questions above.

5.Next Actions

#	Action	Owner	Status
1	Write the requirements document covering every data source plus the specific asks, inputs, and guardrails. This is what Matt explicitly asked for and what unblocks his recommendation.	Dakota + team	Critical path
2	Catalog every data source across the portfolio.	Dakota	To do
3	Document use cases and user journeys: decision, altitude, and frequency for each consumer.	Dakota	To do
4	Define the compliance and PHI guardrails: protection, location, access model, and PHI segregation.	Dakota + compliance	To do
5	Identify candidate quick-win agents to ship in parallel with the platform build.	Dakota + Matt	To do
6	Reconvene with Matt on the requirements doc; he returns with a concrete recommendation.	Dakota	Pending #1

6.How This Connects to Work Already Moving

We are not starting from zero. The Marketing Data Warehouse and Reporting/BI work is already live: a Postgres operational store with a ClickHouse analytics layer, Temporal for orchestration, and Power BI for executive reporting, with Google Ads as the first source feeding real spend data into the intranet.

Matt's mandate is the enterprise generalization of that effort: extend past marketing to every source, formalize the semantic layer, and add the AI activation and PHI/compliance framework the marketing build did not need to solve. The requirements document should fold the existing stack and its settled decisions in as the starting point, not relitigate them.

Prepared by SGA Dental Partners Growth Team | Confidential