DataBlocks: Day 3

We did some progress and changes to our solution that might help us improve our business case :). In the meantime we want to claim some badges!

Badges

We have created a Realtime dashboard with the help of an MVC webapp with SignalR to show Realtime data coming from the database and telemetry in data lake. The Dashboard combines many different components and view referencing different data sources. We think that this is a good candidate for #DashItOut, #Feature bombing, #ClientSideSalsa and #Nasty Hacker (Since we could not achieve some Realtime functionality in PowerBi for some telemetry data, we had to find a quick workaround). Come and take a look to how it works if you wish.

We have also created an Azure AI Search knowledge source and knowledge base which collects all telemetry data from azure data lake. The cool thing about this is that we can use it to translate events from Minecraft into real world scenario events, converting our solution into an incident simulation platform. We can translate events like this:


Minecraft
Industrial Reality
PlayerOperator
ZombieMechanical hazard
CreeperExplosion or gas incident
Player deathSafety incident
Block changeMaintenance
Time of dayShift

The knowledge source is then made available to be used by any external agent that supports RAG indexes. We want to claim the badges: #Hipster. Check the code in our github repo: https://github.com/bricenocar/acdc2026.

Dooh Badge

We created an agent that was supposed to improve prompts coming from Minecraft chat. It took long time and we got really bad results after implementing it. So there was no point on using it, waste of time! #Dooh!

Power of the shell

We have now exported our arm templates and saved into our repo. We can now recover our solution if needed 🙂

https://github.com/bricenocar/acdc2026.

Embedded Numbnuts

Here is a video demonstrating the use of a QR code to open our solution dashboard

FINAL DELIVERY: From Game to Industrial Incident Simulation Platform

We have been focusing on building a platform on top of minecraft to have a “Minigame” experience where users can get rewards, points and even money.

But what if Minecraft wasn’t just a game but a safe, controllable way to simulate industrial incidents?

Instead of treating Minecraft as a playful telemetry source, we now use it as a digital twin and incident simulation platform for complex environments like Oil & Gas rigs.

Minecraft as a Digital Twin

In our solution, Minecraft represents a simplified but powerful model of an industrial facility:

  • Infrastructure is built from blocks
  • Control systems are modeled using redstone
  • Hazards emerge as mobs
  • Workers operate inside the environment as players

Every action generates telemetry, and every event has meaning.

We use Minecraft as a digital twin to safely simulate industrial incidents and analyze telemetry, human factors, and environmental signals to identify root causes and reduce real-world risk.


From Game Events to Real Incidents

The key is semantic translation.

MinecraftIndustrial Reality
PlayerOperator
ZombieMechanical hazard
Creepergas leak
Player deathSafety incident
Block changeMaintenance
Time of dayShift

This mapping allows us to treat Minecraft events as real operational signals.


Simulating Real Incident Scenarios

We simulate scenarios such as equipment failure cascades:

  • A zombie spawns → a hazard is detected
  • A player kills a mob → risk is reduced
  • A player dies → a safety incident has occurred

Incident Analysis & Root Cause Assistant

On top of the telemetry, we built an Incident Analysis & Root Cause Assistant that can answer questions like:

  • What events led up to an incident?
  • Which zones are most dangerous?
  • Do incidents correlate with night shifts?
  • Did recent maintenance increase risk?
  • Has this happened before?

This turns raw signals into insight.


Why This Matters?

In the real world, you can’t freely experiment with failures. But with a digital twin:

  • You can simulate incidents
  • You can study patterns
  • You can improve safety proactively

Minecraft becomes a controlled incident generator, not a game, but a learning environment.


Data flow and game dynamics

While players are in the game, they can interact with the world, which means building blocks, killing MOBS, etc. A game master can change the game conditions of the match, so he/she can simulate unexpected scenarios or events.

All the events are shown in a real time dashboard that an “auditor” can see, allowing to easily track game analytics.

All the game telemetry is logged in azure data lake via an eventhub resource, we index all the data by using Azure AI Search, which then makes it available for AI agents to interact with. The output is then translated from Minecraft terminology to real case scenarios, as described in the table at the beginning of this post.

Our Fabric agent is then mixing data from the game database to get some important data like player points (translated to operator experience), player money (Translated to player access) and player time in game (translated to fatigue) and also data from telemetry like player death (Incident), block built (maintenance),Mob appeared (Risk detected) , Mob killed (risk mitigated) and so on.

Fabric goes on and do its magic to generate really insightful data based on user prompts.

Governance

All the information about how we govern the solution is found in the following blogpost:

https://acdc.blog/wp-admin/post.php?post=10564&action=edit

System architecture

For the system architecture you can take a look at our post:
https://acdc.blog/wp-admin/post.php?post=10906&action=edit

DataBlocks – Crawler

Experimenting here with Azure AI Search to index our telemetry data. We set up the data source, index, and indexer, defined the schema, and configured the indexer to process JSON Lines files stored in Azure Data Lake.

After testing, the initial indexing completed in about one second, which is quite good.

The real advantage becomes clear when this data is vectorized and exposed to agentic solutions, queries return results significantly faster, enabling more responsive and scalable AI-driven experiences. Here are some screen shots of the configuration:

#Crawler

From Minecraft to Dataverse: Automating Rewards with MSCRM Document Generation

One of the fun (and surprisingly powerful) things about working on our DataBlocks solution at ACDC is discovering how far you can push enterprise platforms when you stop treating them as “back-office only”.

In this post, I want to share a small but meaningful integration we built:
automatically generating diplomas for Minecraft match winners using Dataverse, Power Automate, and MSCRM document generation.

The Context: A Minecraft Minigame with Real Logic

As part of our solution, we built a custom minigame on top of the Minecraft world.

Players compete in a match where:

  • Rewards matter
  • Monster killing is a core mechanic
  • Points and outcomes are tracked throughout the session

The goal isn’t just to play, but to win the match based on clearly defined rules.

Representing the Match in Dataverse

Every game session is represented in Dataverse as a Match record.

This entity stores:

  • Current match status
  • Match metadata
  • Participating players
  • Results and winners

When a match is still running, its status reflects that. When the game finishes, the integration updates the record: Status = Completed.

Event-Driven Automation with Power Automate

We created a Power Automate flow that listens for changes on the Match table.

Specifically:

  • Trigger: When a Match record is updated
  • Condition: Status = Completed

This keeps the logic clean and declarative. Once the flow is triggered, it calls the MSCRM document generation capability.

The process looks like this:

  • The generated diploma is produced as a file (PDF / document)
  • The flow identifies the winners of the completed match
  • A predefined document template is used to generate a diploma
  • Player and match data are merged into the document

After the diploma is generated, the flow attaches it directly to the Match record in Dataverse as a file.

This integration is a small piece of the overall DataBlocks solution, but it captures something we really like about this project:

Serious platforms don’t have to be used seriously all the time.

By combining Minecraft, Dataverse, Power Automate, and MSCRM document generation, we created an experience where game outcomes produce real, traceable artifacts

https://www.linkedin.com/feed/update/urn:li:activity:7420558637867114496

DataBlocks journal day 2 – Data and AI!

Data sources (#ThievingBastards #Dataminer)

During the day we have been finetuning the retrieving and processing of data, some of the integrated systems are:

  • Power Platform
  • Microsoft Purview
  • Defender for cloud apps
  • MSCRM addons (#StairwaysToHeaven)
  • Minecraft API
  • Dataverse

We created a platform on top of the minecraft world to be able to have a “minigame” on top of the existing game. We used some known technologies/apps like:

Minecraft Game (#Gloxy pixels #Chameleon)

The game itself works as a UI for our solution. The players can interact with the world while also having our framework available.

Power Apps (Canvas Ap) (#Gloxy pixels #Chameleon)

User interface used by the team lead player that can provide players with items and weapons during a match.

Azure Function / Skill (#StairwaysToHeaven)

Our azure function (which is planned to be transformed into a bot skill) is interacting with Dataverse via APIs and Agent via HTTP.

Minecraft Master Agent (#StairwaysToHeaven)

An agent that can respond to prompts from players to generate artifacts during a match depending on the availability of resources. Game Masters have unlimited access to generate anything in a match.

Real-Time dashboard

All events seen in realtime :). MVC application with SignalR

Match Insights agent

This agent is available for users to provide answers to questions about insights of a specific match, it uses a Fabric agent with an Azure AI Search source to get insights from the data. It can answer questions like:

  • “What caused most player deaths in this session?”
  • “Which areas had the highest monster activity?”
  • “How did player behavior change over time?”

Power automate flows (#GoWithTheFlow)

A couple of flows created for handling some events in a simple way.

Minecraft Plugin (#PlugNplay #StairwaysToHeaven)

Minecraft is a Microsoft game that consist of players in a sandbox world where they have freedom to do certain actions like building, attacking even create flows. We created a Minecraft Plugin that handle all events recorded in the game and send the data to a endpoint published by us in an Azure webapp where we process the data.

The plugin is also in charge of sending telemetry of events happening in a match to a event hub resource, which starts our data journey described in the next section :).

This is a critical component of our solution, since it is the main communication bridge between both systems.

Fabric integration (#Dataminer #StairwaysToHeaven)

Once the data is obtained from the event hub, it is saved in Azure data lake. We then imported this data into our Fabric workspace. We finally configured a Fabric agent that access this data, and it is our source of knowledge for the Match Insights agent.

MSCRM integration (#MSCRM-Addons)

Diploma generation for players in a match is generated based on a template from a MSCRM connector. Looks very nice 🙂

#The Existential Risk

We had to have a section for The Existential Risk badge :). Here we show how a prompt to our agent from Minecraft chat can make things EXPLOSIVE :)!!!

DataBlocks journal day 2 – Governance!

From the start, we treated governance as a must have. Since our solution combines AI agents, Power Platform, and a Minecraft integration, we needed clear boundaries around risk, permissions, and visibility. Here’s what we’ve implemented so far:

1. Environment Strategy: Risk-Based Zoning

We defined five environment groups, based on risk and usage patterns:

  • Green Zone
    Intended for low-risk experimentation and learning.
    Very limited permissions, no sharing of agents, and a minimal connector set.
  • Yellow Zone
    Used for POCs and internal, departmental agents.
    Agents can be shared and published, but usage is limited to smaller audiences and a controlled set of connectors.
  • Red Zone – DEV / TEST / PROD
    These environments are considered high risk by design. They allow broader permissions, richer connector access, and agents or apps that may be used by a large number of users.

2. DLP Policies Aligned to Risk

Each zone has its own Data Loss Prevention (DLP) policy, aligned with the intended risk level.

  • Green Zone DLP
    • Very limited connectors
    • Designed to prevent accidental data exposure
  • Yellow Zone DLP
    • Supports publishing to teams and M365 Copilot
    • Expanded connector set
    • Intended for controlled internal use and experimentation
  • Red Zone DLP
    • Broad sharing allowed across the organization
    • Expanded connector availability, enabled on demand
    • Intended for production-grade solutions

3. Red Zone Configuration for the Minecraft Integration

Our Minecraft integration is hosted in the Red Zone, as expected for a solution with real time interaction, agents, and external APIs. Through the Red Zone DLP policy, we explicitly enabled the following connectors:

  • DocumentCorePack (Dataverse / mscrm)
    Used for storing game sessions, players, and state.
  • Direct Line channel in Copilot Studio
    Required to develop our Bot Framework skill and connect it to agents using Direct Line.
  • Public website knowledge sources in Copilot Studio
    Used to retrieve Minecraft commands and related data from public sources.

Nothing is enabled by default, connectors are enabled on demand and implemented after risk assessment.

4. Visibility and Risk Detection with DSPM for AI

We use DSPM for AI to maintain an overview of all agents in the environment.

This allows us to:

  • Identify risky agents
  • Detect risky behaviors
  • Understand where agents are shared and how they’re being used

This gives us governance at the agent level, not just at the environment level.

5. Access Controls and AI Specific Policies

Using Global Secure Access, we collect traffic logs related to agent activity and outbound requests. This allows us to:

  • Configure alerts
  • Enforce allowed or blocked web destinations
  • Detect unusual or unexpected traffic patterns

6. Auditing and Bot Activity Tracking

Audit logging is enabled, and bot activity logs are available. We’ve already identified and extracted key governance events, like:

  • Bot created or deleted
  • Bot published
  • Bot shared
  • Authentication mechanism updated (one of the most critical signals)

Many interesting tools here to see and test! looking forward to see new features and results from reports and insights.

Our GitHub repo you can find here: https://github.com/bricenocar/acdc2026

#Sharing is Caring

Stay tuned!

DataBlocks journal day 1 – Establishing!

1. Setting the Scene

We started the day by setting up a Minecraft themed workstation environment.
It turned out to be a bit more challenging than expected, especially since some of us traveled from Stavanger to Oslo, and there were practical limits on what we could bring with us.

That said, we’re genuinely happy with the final result. The setup fits the mood, keeps the energy up, and honestly makes long technical sessions more fun. #Happy Camper

2. Collaboration between teams

One of the best parts of events like ACDC is the collaboration across teams. During the day, the EVIDI team ran into some issues with failing HDMI cables. We had a few spare ones, so sharing was an easy decision. They’re back up and running, and we wish them the best of luck for the rest of the challenge!. #Community Champion

3. Spreading the Minecraft Virus

It turns out Minecraft is contagious, in a good way!

We’ve had a lot of fun sharing our setup and progress with colleagues and friends on social media. The reactions have been great, and if this inspires more people to join next year’s event, even better. #Remarkable Teamspirit

4. Power Platform Meets Minecraft

From a technical standpoint, today’s biggest win was integration. We successfully established a bi directional communication between our Power Platform environment and Minecraft, via its APIs.

We can now send commands from Power Platform into the game as well as emit events from Minecraft back into the platform.

The communication is near real-time, which gives us a solid foundation to move forward with game logic, storytelling, and dynamics. This integration is enabled through a custom Minecraft Java plugin, and it’s already proving to be a key building block.

#Embedding numbnut #Plug N’ Play

5. Technologies in Play

Some of the technologies we have used include:

a- Minecraft Java Plugin for in-game integration.

b- Azure Bot Framework Skill handling agent activities and external API calls

c- Fabric Agent, used to generate data insights from telemetry coming out of Minecraft.

A nice mix of classic engineering and modern AI agent based architecture. #Hipster

6. Players, Agents, and the Game Master

Most of the interaction between players and our platform is driven by AI agents. That said, there is one very important human in the loop: the Game Administrator. This role has the power to:

a. Switch between day and night

b. Assign weapons or items to players.

c. Release more monsters to increase difficulty

Think less “admin user” and more Game Master, shaping the experience in real time.

#Power User Love

7. Final thoughts

Overall, today was about laying the foundation:
integration, collaboration, and setting the tone for what’s coming next.

Tomorrow we build the story and the wow effects 🙂

Stay tuned!

Early Delivery: DataBlocks

We building an intelligent, cloud backed in-game experience, the idea is simple: bring logic, AI, and data directly into the game, where players and admins interact with it in real time.

We’re implementing a custom minigame experience inside the game, with its own logic layer. This includes:

– Points and in-game currency

– Rewards and progression

– Player state and session tracking

Instead of hardcoding everything, the game logic is designed to be data driven, allowing us to evolve rules and mechanics without redeploying the game itself.

One of the key features is a game admin role. An admin can make live changes to an ongoing game session, such as:

  • Switching between day and night
  • Assigning weapons, items, or points to specific players
  • Influencing the session dynamically without restarting it

Communication between players, the game, and AI agents is handled using a Bot Framework skill.

We’re using Dataverse as our primary database for:

  • Game sessions
  • Player profiles
  • Points, currency, and rewards
  • Admin actions and game state

All in-game telemetry is streamed to a data lake. This includes events such as:

  • Player deaths and kills
  • Building actions
  • Monster spawns and movement
  • Environmental changes

The goal is to capture everything that happens in the game, at scale, without impacting gameplay performance.

We’re using it in three main scenario where AI is going to play a role:

Game Helper Bot:

Players can interact with a game helper bot through chat. Examples:

  • “Build a fortress”
  • “Build a wall around me”
  • “Create a safe zone”

The agent translates these requests into Minecraft commands that can be executed directly in the game, taking into account:

  • The player’s available points or currency
  • Game rules and constraints
  • Current game state

Player Prompt Improver

Players don’t always write perfect prompts that is why we use an LLM as a prompt improver, which:

  • Takes short or vague player input
  • Expands and adapts it to the game context
  • Produces a richer, more precise prompt for the helper bot

Data Insights Agent

Finally, we’re building a data insights agent on top of the telemetry stored in the data lake.

This agent can answer questions like:

  • “What caused most player deaths in this session?”
  • “Which areas had the highest monster activity?”
  • “How did player behavior change over time?”

What We’re Not Showing (Yet)

We also have plans around:

  • Governance
  • ALM
  • Data indexing and optimization