There is a point in every engineer’s journey where data modeling stops feeling intuitive.

What starts as a clean schema becomes harder to reason about. Relationships blur. Query paths multiply. Small changes ripple across different steps.

This is where data modeling reveals its real challenge: not just storing data but preserving clarity as systems scale.

And this is where GitHub Copilot became a practical accelerator for us.

WHEN DATA MODELS STOP SCALING WITH OUR THINKING
Data modeling is rarely blocked by SQL syntax. It is blocked by architecture decisions.

As architects and data engineers, we repeatedly ask:

• What are the true domain entities versus temporary implementation details?
• Which relationships must be strict, and which can stay flexible?
• How do we model for today without breaking six months later?

Traditionally, we solved this through whiteboarding, manual DDL rewrites, and slow iteration cycles. It worked, but velocity was low.

GitHub Copilot changed that loop. It reduced the distance between intent and a concrete model draft.

We used GitHub Copilot Chat in VS Code. Inline suggestions helped during DDL refinement, while Chat mode helped more with architecture reasoning and constraint validation.

THE REAL EXAMPLE
SaaS control plane: 

A SaaS control plane is the administrative backbone of a multi-tenant platform. It is separate from the actual application workload (the data plane) and is responsible for tenant lifecycle management: who gets access to what, under which terms, in which environment, and in what deployment state. Think of it as the system that answers the question "who is running what, where, and in what condition" at any point in time.

It is used because multi-tenant SaaS products cannot afford to manage tenant provisioning, subscription entitlements, and infrastructure allocation manually at scale. The control plane automates and tracks these operations consistently, reliably, and with full auditability.

We used Copilot to accelerate a control-plane style data model where:

1. A tenant is onboarded
2. The tenant selects an application
3. The tenant selects a service tier
4. The tenant selects a target environment
5. A deployment is orchestrated
6. Required infrastructure is provisioned
7. Deployment and infrastructure details are captured for audit and operations

This was not a toy schema. Every entity had lifecycle states, ownership boundaries, and downstream consumers in data engineering and observability.

THE DIFFICULTIES WE FACED WITHOUT COPILOT
Boundary confusion
We initially mixed desired state (what should happen) and runtime state (what actually happened). That caused inconsistent query behavior and weak auditability.

Relationship drift
As deployment history and infra tracking were added, early cardinality assumptions changed. A simple one-to-one became one-to-many after redeployments and rollbacks.

Iteration cost
Every revision required manual rewrites across table definitions, constraints, and foreign key references. Naming drift became a recurring review issue.

Team alignment friction
Architecture discussions moved faster than our ability to create review-ready schema drafts.

HOW GITHUB COPILOT HELPED
Faster first draft
We described onboarding and deployment flow in plain language and got a complete relational baseline quickly. A process that previously took long whiteboard sessions and multiple rewrite cycles reached reviewable shape in one focused afternoon.

Pattern recall at the right time
Copilot consistently surfaced useful structures:

• A subscription pivot entity to decouple tenant, application, tier, and environment
• Immutable deployment history records
• Infra resource catalog with resource typing
• Deployment event trail for auditability

Rapid refinement
When assumptions changed, Copilot regenerated affected structures consistently. We did not need to manually patch every dependent reference.

Better design conversations
Because drafts appeared faster, reviews shifted from syntax fixes to architecture quality:

• Is tenant isolation explicit?
• Is deployment history trustworthy?
• Are infrastructure dependencies traceable?
• Can data engineering build analytics without fragile joins?

CORE RELATIONSHIPS FINALIZED

• Tenant to Tenant App Subscription: one-to-many
• Application to Tenant App Subscription: one-to-many
• Service Tier to Tenant App Subscription: one-to-many
• Environment to Tenant App Subscription: one-to-many
• Tenant App Subscription to Deployment: one-to-many
• Deployment to Infra Resources: one-to-many
• Deployment to Deployment Events: one-to-many

LOGICAL RELATIONSHIP VIEW
Tenant -> Tenant App Subscription
Application -> Tenant App Subscription
Service Tier -> Tenant App Subscription
Environment -> Tenant App Subscription
Tenant App Subscription -> Deployment
Deployment -> Infra Resources
Deployment -> Deployment Events

SAMPLE PROMPTS WE USED
Prompt 1
Design a relational schema for a multi-tenant onboarding flow where tenants select application, service tier, and environment, followed by deployment and infrastructure tracking. Include relationship rationale.

Prompt 2
Given this schema, identify possible cardinality mistakes and suggest safer constraints for repeat deployments.

Prompt 3
Refine the model so deployment records are immutable history, while subscription stores current desired state.

Prompt 4
Suggest naming and normalization improvements so data engineers can build reliable analytics models from these tables.

Prompt 5
List operational risks in this model and which table-level attributes improve troubleshooting and auditability.

Prompt 6

Tenant license generation is now required before a tenant can access a selected application. Propose a minimal schema change that captures license issuance, validity period, and status without breaking existing subscription and deployment records.

THE THOUGHT PROCESS SHIFT
Before Copilot, most effort went into translating architecture ideas into SQL artifacts.

With Copilot, that translation became fast enough that evaluation became the primary activity:

• Is tenant isolation explicit in schema or hidden in app logic?
• Is deployment history append-only and safe?
• Are infra resources independently traceable?
• Can analytics teams consume this model cleanly?

That shift from authoring to evaluating is where design quality improved.

SCHEMA EVOLUTION LESSONS
Two changes arrived mid-design:

1. License generation became a required step before a tenant could access a selected application. The license needed to capture issuance date, validity period, and revocation status.

2. Service-tier entitlements became time-variant

In both cases, we described the evolution requirement in Copilot Chat with the existing schema as context. Copilot proposed additive changes: a new tenant license table linked to the subscription for the first case, with license status and validity tracked independently, and a separate tier entitlement history table for the second.

WHERE ENGINEERING JUDGMENT STILL MATTERS
Copilot gives possibilities, not guarantees. Engineers still need to own:

• Domain truth and lifecycle semantics
• Cardinality correctness
• Performance and scale trade-offs
• Governance, compliance, and retention
• Backward-compatible migration strategy

Copilot output should always go through architecture review before production.

CLOSING THOUGHT
Data modeling is still an architectural discipline. What changed is iteration speed.

GitHub Copilot helps teams move from idea to structure faster, compare alternatives earlier, and focus on design quality rather than mechanical authoring.

The bottleneck is no longer writing schemas. It is thinking clearly about the problem. That is where AI-assisted modeling delivers real value.

TRY IT YOURSELF

1. Open GitHub Copilot Chat in VS Code
2. Describe your core entities and lifecycle questions
3. Ask for at least two schema alternatives
4. Compare constraints and operational trade-offs
5. Share your lessons with the community
   
   

    

The Traditional ML Pipeline: What It Was Built For

Traditional ML pipelines typically look like this:

• Data ingestion and preparation
• Model training (often batch‑oriented)
• Model validation and versioning
• Deployment via APIs or batch jobs
• Monitoring focused on accuracy and drift

This approach worked well for:

• Predictive models (forecasting, classification)
• Periodic retraining cycles
• Isolated use cases owned by data science teams

However, in enterprise environments, these pipelines often became fragile and slow to evolve:

• Tool sprawl across data, ML, DevOps, and security
• Limited visibility for platform and operations teams
• Governance added late, often as manual controls
• Difficult to extend beyond “model → API” patterns

Azure AI Foundry: A Platform Built for AI Applications, Not Just Models

Azure AI Foundry reflects a fundamental shift: AI is no longer just a model it’s part of an application and workflow.

Instead of centering everything around training pipelines, Foundry brings together:

• Model access (including foundation and generative models)
• Agent and application orchestration
• Grounding with enterprise data
• Built‑in evaluation, observability, and governance
• Integration with broader Azure and Microsoft ecosystems

In practical terms, this means teams can move from:

“How do we deploy this model?”
to
“How do we operate AI safely, reliably, and at scale across the organization?”

Key Differences That Matter in the Enterprise

1. From Model‑Centric to Application‑Centric

Traditional pipelines optimize for model performance.
Azure AI Foundry optimizes for end‑to‑end AI applications, including agents, copilots, and workflows.

This is critical when AI interacts with:

• Business systems
• Knowledge stores
• Human users
• Other AI agents

2. Built‑In Governance Instead of After‑Thought Controls

In classic ML pipelines, governance is often layered on later—manual approvals, separate monitoring tools, or custom dashboards.

Azure AI Foundry brings governance into the platform itself, with:

• Centralized access control
• Policy‑driven resource management
• Built‑in evaluation and observability

For enterprises operating under compliance, security, and audit constraints, this is not optional—it’s foundational.

3. Operational Readiness from Day One

One of the most common failures I’ve seen is AI solutions that work in demos but collapse in production.

Traditional ML pipelines often struggle with:

• Monitoring beyond accuracy metrics
• Cost visibility for inference and experimentation
• Coordinating updates across multiple teams

Foundry emphasizes production readiness:

• Standardized deployment patterns
• Central observability across models and agents
• Alignment with Azure monitoring, security, and operations

4. Designed for Continuous Evolution, Not Static Deployment

Generative and agentic AI systems evolve constantly prompts change, data sources change, tools change.

Traditional pipelines assume:

• Clear training → deployment boundaries
• Infrequent updates

Azure AI Foundry assumes:

• Continuous iteration
• Human‑in‑the‑loop workflows
• Rapid experimentation with guardrails

This aligns far better with how AI solutions are actually built and operated today.

When Traditional ML Pipelines Still Make Sense

This is not an either‑or decision.

Traditional ML pipelines are still a good fit for:

• Well‑understood predictive models
• Stable data and training cycles
• Narrow, isolated use cases

In fact, many enterprises will continue to run both approaches side by side.

The key difference is what you optimize for:

• Pipelines optimize for models
• Foundry optimizes for AI systems

Why This Matters for Architects and Enterprise Teams

From an enterprise architecture perspective, Azure AI Foundry helps answer questions that traditional pipelines struggled with:

• How do we standardize AI development across teams?
• How do we enforce governance without slowing innovation?
• How do we observe and manage AI systems at scale?
• How do we prepare for agentic and autonomous workloads?

These are platform questions, not model questions and that’s why the distinction matters.

Closing Thoughts: A Shift in Mindset, Not Just Tooling

Azure AI Foundry is not simply a replacement for traditional ML pipelines. It represents a shift in how enterprises think about AI from isolated models to integrated, governed, and continuously evolving systems.

For organizations serious about scaling AI beyond experimentation, this shift is not optional. It’s inevitable.

After a quick round of Apple dev updates, James and Frank dive into Matter — why Frank went from skeptic to devotee and why it’s poised to fix IoT chaos. They break down how Matter (an app-layer protocol running over Wi‑Fi/IPv6) and Thread (an open mesh transport) simplify secure onboarding with QR/Bluetooth, enable true interoperability across Apple/Google/Amazon, and make DIY devices easy to build and integrate.

Follow Us

• Frank: Twitter, Blog, GitHub
• James: Twitter, Blog, GitHub
• Merge Conflict: Twitter, Facebook, Website, Chat on Discord
• Music : Amethyst Seer - Citrine by Adventureface

⭐⭐ Review Us ⭐⭐

Machine transcription available on http://mergeconflict.fm

Support Merge Conflict

Links:

• List of currently defined spec device types — Matter documentation
• project-chip/connectedhomeip: Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
• arduino-esp32/libraries/Matter/examples at master · espressif/arduino-esp32
• Amazon.com: 5pcs Type-C ESP32-C3 Development Board ESP32 C3 Mini WiFi Bluetooth 160MHz Running Frequency 2.4GHz Wi-Fi & Bluetooth 5.0 ESP32 C3 Super Mini for Arduino : Electronics

If you've spent time deploying traditional large language models (LLMs), you've likely wrestled with the classic tradeoff between accuracy and performance. Typically, we're forced to make a rigid architectural choice: Do you deploy a massive, slow model for deep reasoning, or a small, lightning-fast one for everyday chat? Often, we end up gluing these models together with complex semantic routers. What if we didn't have to choose? Diffusion LLMs offer a way out of this trap, alongside a host of other potential benefits.

Why the shift and how it works

Traditional auto-regressive (AR) models use causal next token prediction. They predict the next token one by one, moving strictly from left to right. It works, but it's rigid.

A diffusion LLM (dLLM) flips the script, offering a refreshing, dynamic alternative. Instead of guessing one word at a time, a dLLM drafts a sequence of text and then refines it, using two techniques:

• Bidirectional attention: Unlike AR models that can only look at the past, a dLLM looks at both the past and the future tokens it is drafting. This creates incredibly coherent, context-aware output.
• Iterative refinement: Think of it like a game of fill-in-the-blank. Instead of writing a sentence word-by-word, the model drafts a full sentence with blanks—like "The quick [MASK] fox jumps over the [MASK] dog." In the next step, it looks at the whole sentence to perfectly fill in "brown" and "lazy." It loops back to enhance the quality and logic of the draft with each pass.

Figure 1 shows the progression from a standard causal mask of auto-regressive models to the full bidirectional mask of early diffusion LLMs.

The runtime tradeoff

So why is this architecture so different? The magic is a beautifully simple, dynamic runtime tradeoff. With standard AR models, the compute spent on a token is baked into the architecture. If you want more intelligence, you need a bigger model or complex, latency-heavy test-time compute loops.

A dLLM fundamentally rewrites these rules. Because a dLLM drafts multiple tokens simultaneously and refines them over multiple "steps" (similar to how an AI image slowly comes into focus), you can tune quality against latency on the fly.

Need instant, real-time speed for a voice assistant? Run the exact same model at fewer steps.

Need deep, complex reasoning for a coding task? Turn the steps up to let the model refine its draft.

There's no need to swap models, maintain multiple endpoints, or build complex routing logic. You deploy one single model and flex its performance to meet the exact needs of the moment. It's elegant, efficient, and incredibly powerful.

Figure 2 shows some example real-world statistics for a dLLM.

The evolution of diffusion LLMs

This architecture is rapidly evolving across three distinct generations:

• First generation (the pioneers): Early models like LLaDA 1.0, and Dream used a full context approach. They were groundbreaking, but because they tried to refine the entire sequence at once and could not use standard KV caching, they were computationally heavy and slow.
• Second generation (the pragmatists): Models like SDAR, LLaDA 2.0, and Fast-dLLM2 got smarter by shifting to a blocked causal context. By operating on smaller chunks (typically 8 to 64 tokens at a time) and enabling block-wise KV caching, they drastically improved inference speed and made dLLMs practical for real-world use.
• Third generation (the frontier): New models and innovations are popping up every day. LLaDA 2.1 with token editing, and WeDLM with stream decoding, just to name two. That's just the beginning for this self-reinventing third generation.

The need for speed and scale

The demand is undeniable, and the open source community is moving fast. Popular models like LLaDA2.0-mini, LLaDA2.1-flash, Fast_dLLM_v2_1-1.5B, and SDAR-1.7B are experiencing a surge in downloads on Hugging Face, with some reaching 150,000 monthly downloads.

We're seeing trending dLLMs like the open source LLaDA 2.X hitting over 800 output tokens per second (TPS), while the Mercury 2 is crossing the 1000+ TPS threshold. When looking at the data, models like WeDLM and LLaDA 2.1 are outperforming baseline vLLM auto-regressive models, as shown in Figure 3.

Building the future at Red Hat

At Red Hat, we believe in taking brave leaps forward along with the rest of the open source community. We aren't just watching this dLLM trend happen, we're actively exploring this promising architecture to build the infrastructure that supports it. The journey into diffusion LLMs is just beginning, and it's full of brilliant possibilities. Stay tuned for more updates, and as always, keep building with curiosity!

You can also leverage the no-cost 60-day Red Hat AI trial to test leading and emerging models and experience the benefits they can unlock for your unique business use cases.

Learn how to generate reusable email HTML using Razor Views in ASP.NET Core with strongly-typed models.

The page The best way to create email templates in .NET appeared on Round The Code.

With the Data API builder, you can easily generate an API on top of an existing database. However typing out the configuration settings in the dab-config.json isn't much fun. The auto-entities features I talked about before can certainly help, but that is not always the right solution. With the integrated GUI in the MSSQL extension for Visual Studio Code, you can replace the manual JSON configuration with a visual interface that handles entity selection, CRUD permission mapping, API type targeting, and Docker-based local deployment — all without leaving the editor.

This post covers exactly what the UI does, what it generates, and where it falls short.

Entry points

The DAB configuration view is accessible from two places:

• Object Explorer — right-click a database node → Build Data API (Preview)...
• Schema Designer — Design API button (top-right toolbar) or the Backend icon in the left panel

Both open the same configuration surface.

Entity selection

Tables are listed grouped by schema, with collapsible schema rows and a n/total badge showing how many entities in that schema are currently enabled.

• Schema-level checkboxes support tri-state (all / none / mixed) and toggle all tables in the group
• Per-entity rows expose: enable toggle, entity name, source table, per-action CRUD checkboxes, and an advanced settings gear
• A filter input at the top searches across entity name, schema, and source table (case-insensitive); the enabled count badge updates live

Remark: the UI supports tables only at the moment. Views and stored procedures are not available in the designer.

Configuration

CRUD

CRUD permissions are set independently per entity via inline checkboxes (Create, Read, Update, Delete). Header-level checkboxes apply a given action across all enabled entities, also with tri-state support.

API Types

API type selection sits at the top of the view:

At least one type must be selected before deploying.

Advanced Entity Settings

The gear icon on each entity row opens an Advanced Entity Configuration dialog:

This maps directly to the entities block in the DAB JSON config — useful if you want clean API surface names that don't expose internal table naming conventions.

Configuration preview

The View Config button opens a Definition panel — a read-only render of the DAB JSON configuration that would be deployed. It:

• Reflects entity selection, API types, CRUD permissions, and advanced settings in real time
• Stays in sync bidirectionally with the UI and the Copilot chat interface
• Scopes output to enabled entities only

Open in Editor promotes it to a full VS Code editor tab; Copy puts it on the clipboard. The generated file is standard DAB config format, so it's portable if you want to take it outside the extension.

Local deployment

Deployment runs DAB as a Docker container. 

The wizard runs sequentially:

1. Prerequisites check — verifies Docker is installed, Docker Desktop is running, and the Docker engine is ready
2. Container Settings — optional container name (autogenerated default provided) and port (default 5000); the connection string is pulled automatically from the active MSSQL connection
3. Deployment — pulls the DAB image, starts the container, checks readiness

On success, the wizard surfaces endpoint URLs per API type:

Authentication constraint: the Docker container only supports SQL authentication. Connections using Microsoft Entra interactive methods (ActiveDirectoryInteractive, etc.) are blocked — the container environment can't open a browser for the sign-in flow. The extension surfaces a notification if your active connection uses an unsupported auth type. SQL database in Microsoft Fabric is similarly unsupported, since Fabric requires Entra authentication exclusively.

GitHub Copilot integration

A Chat button in the toolbar opens a Copilot chat session scoped to the DAB configuration context.

 Natural language prompts update entity selection and permissions directly:

"Enable all SalesLT entities for read operations"
"Expose only the Customer and Product tables with full CRUD permissions"
"Set all entities in the dbo schema to read-only"
"Can you also enable MCP for the Data API builder API?"

State is fully bidirectional: Copilot changes propagate to the UI and Definition panel immediately, and UI changes are visible to Copilot in the same session. Requires the GitHub Copilot and GitHub Copilot Chat extensions to be installed and authenticated.

As with any AI-generated configuration, review the Definition panel output before deploying — the generated JSON is inspectable and portable.

What gets generated

The output is a standard DAB JSON configuration file. If you're already familiar with DAB config structure, the UI maps cleanly onto it: entity names, source tables, CRUD permissions, REST/GraphQL/MCP runtime sections, authorization roles, and custom path overrides all correspond directly to known config fields. Nothing proprietary is introduced — the file is fully portable and can be checked into source control or handed off to a deployment pipeline.

More information

DAB in VS Code with MSSQL — Microsoft Learn

DAB 2.0 Preview: Autoconfiguration with autoentities