Solve Caldova launch-readiness challenges with grounded agents

1. Download L400-unify-data.zip{:target="_blank"} from https://raw.githubusercontent.com/MicrosoftLearning/mslearn-unify-data/main/Allfiles/L400-unify-data/L400-unify-data.zip. Extract it to Downloads\L400-unify-data. Confirm that code, data, notebooks, and event-simulator appear directly inside that folder.

2. Open Fabric, select Workspaces > + New workspace, and create caldova-challenge-<initials>. Under Advanced, select Fabric and your assigned capacity.

3. Select Import > Notebook > From this computer, and import notebooks\curate_caldova_tables.ipynb. In the notebook, select Add data items > New lakehouse, create caldova_lakehouse with schemas enabled, and attach it as default.

4. Select Run all. The notebook downloads the six supplied Caldova files and writes managed dbo tables. Confirm Validation passed: 318 rows across six tables; all tested relationships are valid.

5. In the same workspace, create a SQL database named caldova_customer_db. In New query, paste the SQL in code\01-create-customer-database.txt, starting at SET NOCOUNT ON, and run it. Confirm 25 products and 16 feedback records: six for P101, five for P104, and five for P113. Leave Sentiment empty.

6. In caldova_lakehouse Explorer, open the menu for Tables > dbo, select New table shortcut, and choose Microsoft OneLake under Internal sources. Select caldova_customer_db in this workspace, retain Pass-through authentication, and select its dbo.customer_feedback table. Name the shortcut customer_feedback and select Create. Wait for automatic mirroring and endpoint synchronization, then confirm 16 rows in dbo.customer_feedback.

7. In the writable SQL database query editor, run the following source update. It changes a submission channel, not the feedback population:

   UPDATE dbo.customer_feedback
   SET Channel = 'Email'
   WHERE FeedbackID = 4;
   
   SELECT FeedbackID, ProductID, Channel
   FROM dbo.customer_feedback
   WHERE FeedbackID = 4;
   

8. Open the Lakehouse SQL analytics endpoint and run the following query until the shortcut reflects Email:

   SELECT FeedbackID, ProductID, Channel
   FROM dbo.customer_feedback
   WHERE FeedbackID = 4;
   

   Refresh and wait if it still shows Portal. Don't rerun the planning notebook or copy the table to make the value appear.

9. Restore the original channel in the writable SQL database, then repeat the endpoint query and confirm that Portal returns:

   UPDATE dbo.customer_feedback
   SET Channel = 'Portal'
   WHERE FeedbackID = 4;
   

Expected result: Planning tables are populated, and a source update propagates to the shortcut without a learner-maintained ETL pipeline. The SQL database remains writable; the OneLake analytical copy and shortcut are read-only.

Note: A shortcut is like a reference to the operational record, not another independently maintained customer list. It avoids an extra export pipeline, but you must still account for synchronization delay before checking a recent change.

1. Create a Data agent named caldova_business_data_agent. Add caldova_lakehouse, selecting launch_program, product, plant, capacity_plan, batch, supplier, and the customer_feedback shortcut.

2. Add these agent instructions:

   You support Caldova business users. Use only the selected Lakehouse sources.
   Give source-backed launch, plant, supplier, and submitted-feedback facts.
   customer_feedback joins to product on ProductID and has one row per FeedbackID.
   If Sentiment is null, don't infer a stored score or treat it as neutral.
   Don't make clinical conclusions. Separate source facts from recommendations and never
   present supplier ranking as procurement approval.
   

3. Open code\06-fabric-data-agent-snippets.txt. Add its Lakehouse source instructions and the two SQL examples to the Lakehouse source. Don't add its Eventhouse configuration; this solution has no streaming source.

4. Append this source instruction:

   Use customer_feedback for submitted comments and counts, joining to product on
   ProductID. The shortcut reads mirrored transactional records. A null Sentiment
   means unscored, not neutral. Don't count feedback again by joining it to every
   supplier, batch, or capacity row.
   

5. Run the supplied launch and supplier example queries in the Lakehouse SQL analytics endpoint. Confirm the 18,900-unit, 7% gap, binding plant PL003, and Meridian Biologics as the leading eligible supplier. Eligibility requires a currently valid GMP certificate, zero open critical findings, fast-track eligibility, and capacity of at least 18,900 units.

6. Add this feedback-count example and run it directly:

   SELECT ProductID, COUNT(*) AS FeedbackCount
   FROM dbo.customer_feedback
   WHERE ProductID = 'P101'
   GROUP BY ProductID;
   

   The result must be P101 with six records.

7. Ask the following question and inspect the completed SQL steps:

   For LP001, summarize the capacity gap, binding plant, leading eligible supplier,
   and number of submitted feedback records for its product. Use source facts
   and distinguish any recommendation from an approved action.
   

8. Correct source instructions or example queries if an answer differs from the direct SQL results.

Expected result: The data agent returns the launch facts, supplier result, and six-record P101 feedback count. It doesn't invent sentiment, operational exceptions, or an ontology.

1. After you verify that the Fabric data agent responses are accurate, select Publish, select Publish to Agent Store to make the data agent available in Microsoft 365 Copilot, and complete publication.

Note: Copilot Studio can also be used to make an agent available in Microsoft 365 Copilot. This workshop does not implement that path because it requires additional Copilot Studio licensing/credits and administrative configuration.

2. Open a new browser tab and go to Microsoft 365 Copilot. Open the Agents pane and select the Fabric agent you published.

3. Enter one of the prompts that you used to test the Fabric data agent before and review the response.

4. Verify that Microsoft 365 Copilot invokes the Fabric data agent and returns information based on the data sources configured for the agent.

5. Ask an additional question to further explore the organization's data.

Expected result: The agent works in Microsoft 365 Copilot through the published Fabric data agent. If installation or sign-in is blocked, contact your environment provider. Keep this workspace, database, shortcut, and agent for Task 03.

1. Use the supplied simulator and code files at Downloads\L400-unify-data.

2. Open caldova-challenge-<initials> and confirm that caldova_lakehouse contains launch_program, product, plant, capacity_plan, batch, and supplier. Reuse these tables; don't rerun the planning notebook or create another workspace or Lakehouse.

3. Create an Eventhouse named caldova_events. In its default KQL database, create a KQL Queryset named caldova_exception_queries.

4. Open code\05-operational-events.txt. Run its table-creation command and JSON-mapping command separately, without the descriptive file heading.

5. Create an Eventstream named caldova_operational_stream. Add a Custom endpoint named caldova-simulator.

6. Add an Eventhouse destination with Direct ingestion, selecting this workspace's Eventhouse and KQL database. Connect the default stream to it.

7. Add a Lakehouse destination, select this workspace's caldova_lakehouse and its dbo schema, and create the table operational_event_history. Select JSON. Under Advanced, set Minimum rows = 1 and Maximum duration = 1 minute (60 seconds). Connect the default stream to it and select Publish.

8. Select the custom endpoint's Details > Event Hub > SAS Key Authentication. Obtain Connection string-primary key and Event hub name. In PowerShell, run these commands to set process-local credentials and send a priming event:

   Set-Location "$HOME\Downloads\L400-unify-data\event-simulator"
   $env:EVENTSTREAM_CONNECTION_STRING = (
       [System.Net.NetworkCredential]::new(
           '',
           (Read-Host 'Paste the complete Event Hub connection string-primary key' -AsSecureString)
       ).Password
   ).Trim()
   $env:EVENTSTREAM_ENTITY_NAME = (Read-Host 'Paste Event hub name').Trim()
   python .\replay_events.py --prime --delay-seconds 0
   

9. Confirm Replay complete: 1 event sent. In Eventstream Live view, configure the Eventhouse destination. Select the existing operational_events table, select JSON, enable Use existing mapping, select operational_events_json, and finish the wizard.

10. Run the full replay once, then remove the credential variables:

    python .\replay_events.py
    Remove-Item Env:\EVENTSTREAM_CONNECTION_STRING
    Remove-Item Env:\EVENTSTREAM_ENTITY_NAME
    

    Expect Replay complete: 10 events sent. Keep the simulator state files. They prevent accidental replay; don't use --force to compensate for delayed ingestion.

11. Run the final threshold query from 05-operational-events.txt. Confirm two PL003 utilization breaches, one PL003 quality-deviation breach, and one CMO006 projected lead-time breach.

12. Open this Lakehouse's SQL analytics endpoint and run the following history query after the batching and synchronization delays:

    SELECT COUNT(*) AS SimulatorRows,
           SUM(CASE WHEN LaunchProgramID = 'LP001' AND MetricValue > Threshold
                    THEN 1 ELSE 0 END) AS ThresholdBreaches
    FROM dbo.operational_event_history
    WHERE SourceSystem = 'CaldovaLabSimulator';
    

    Expect 11 rows and four breaches. Wait and refresh if necessary; don't resend events. If counts are larger, inspect duplicate EventID values before continuing.

Expected result: Eventhouse supplies queryable operational exceptions, and Lakehouse retains the same stream's history. Don't count the two destinations as independent populations of events.

1. In caldova-challenge-<initials>, create caldova_ops_data_agent. Select only the six Lakehouse planning tables and the Eventhouse operational_events table. Leave the business data agent unchanged; don't add its feedback shortcut or the duplicate Lakehouse event history to the operational agent.

2. Open code\06-fabric-data-agent-snippets.txt. Add its agent instructions, Lakehouse source instructions and SQL examples, and Eventhouse source instructions and KQL example to the corresponding configuration areas.

3. Ask the following question and inspect its completed SQL and KQL steps:

   For LP001, summarize the capacity gap, binding plant, leading eligible supplier,
   and simulated threshold breaches. Separate facts from recommended actions.
   

   Verify the 18,900-unit, 7% gap, PL003, Meridian Biologics, and four simulated breaches against direct queries. Correct the affected source instructions or examples if the agent differs, then select Publish.

4. Open the Foundry portal with New Foundry enabled. Create caldova-operations-<initials> in a new resource group named caldova-operations-<initials>-rg, using your assigned subscription and region.

5. Open Build > Models, select Deploy > Deploy a base model, and deploy gpt-5-mini or an environment-provider-approved comparable small reasoning model that supports Foundry Agent Service and Fabric IQ tool calling. Open Build > Agents, open the arrow next to New agent, and select Build an agent. Create caldova_foundry_ops and select your deployment in Model on its Playground tab.

6. Add these instructions:

   You support Caldova operations. Use caldova_ops_data_agent for every
   Caldova data question. State source-backed capacity, plant, supplier, and event
   evidence. Label events as simulated. Distinguish facts from recommendations.
   Supplier ranking is not procurement approval. Don't invent clinical claims.
   

7. Select Tools > Add > Browse all tools > Fabric IQ (OneLake Catalog) > Add tool. Sign in with your assigned account, filter to Data agent, select published caldova_ops_data_agent from caldova-challenge-<initials>, and select Add.

8. Select Save, then ask the operational question in a new Foundry conversation. Confirm that the Fabric IQ call targets the operational data agent and returns the source-backed results.

9. Open workspace Lineage view and inspect the Eventstream's two destinations. In OneLake catalog, confirm that your planning, event, and data-agent items are discoverable with the expected access.

Expected result: The Foundry assistant answers operational questions using SQL and KQL evidence. Direct grounding is like giving the assistant indexed source binders: explicit keys and rules are sufficient for this focused request, while each added source creates instructions to maintain.

This solution is complete without the transactional feedback database or the business agent. If a data agent isn't listed in Foundry, confirm its published state, selected workspace, and signed-in account; contact your environment provider if it remains unavailable.

If a Fabric tool call times out, deploy your environment provider's approved background-mode-capable model in the operational Foundry project, using the model-deployment steps above. In Playground, select that deployment under Model, open the parameters icon, turn on Background mode, and save before retesting. The linked documentation lists supported models, including gpt-5.4 and gpt-5.5. Don't replay the events to resolve an agent timeout.

1. Open caldova-challenge-<initials>. Confirm that caldova_customer_db and the Lakehouse feedback shortcut each contain 16 records. Don't rerun the database-creation script.

2. In Foundry, create caldova-enrichment-<initials> in a new resource group named caldova-enrichment-<initials>-rg, using your assigned subscription and region. Deploy gpt-5-mini or an environment-provider-approved comparable small reasoning model that supports the OpenAI Responses API and the supplied client's minimal reasoning effort. This project and deployment are separate from Task 02's operational agent.

3. Record the deployment name and resource OpenAI v1 endpoint, such as https://<resource>.openai.azure.com/openai/v1/. Don't use a project /api/projects/... endpoint.

4. Open caldova_customer_db Settings > Connection strings. Record its writable SQL database server and database values, not the read-only SQL analytics endpoint.

5. Open PowerShell and prepare the supplied sentiment client:

   Set-Location "$HOME\Downloads\L400-unify-data\code"
   python -m venv .venv
   .\.venv\Scripts\Activate.ps1
   python -m pip install -r .\requirements.txt
   az login
   

   Sign in with your assigned account. The script uses DefaultAzureCredential for Microsoft Entra tokens. If environment activation is blocked, contact your environment provider.

6. Enter the non-secret resource values at the prompts, then run the client:

   $env:FABRIC_SQL_SERVER = (Read-Host 'Business SQL database server').Trim()
   $env:FABRIC_SQL_DATABASE = (Read-Host 'Business SQL database name').Trim()
   $env:FOUNDRY_OPENAI_BASE_URL = (Read-Host 'Foundry resource OpenAI v1 endpoint').Trim()
   $env:SENTIMENT_MODEL_DEPLOYMENT = (Read-Host 'Enrichment project sentiment deployment name').Trim()
   python .\score_feedback_foundry.py
   

   The client reads feedback, invokes the Foundry model with minimal reasoning effort, checks that the response completed, validates each returned label, and commits it to SQL. It retains successful scores when rerun and stops with an exception on failure.

7. Confirm Validation passed: 16 feedback records scored through Foundry deployment .... Run this query in the writable SQL database to obtain the authoritative sentiment distribution:

   SELECT ProductID, Sentiment, COUNT(*) AS FeedbackCount
   FROM dbo.customer_feedback
   WHERE AIError IS NULL
   GROUP BY ProductID, Sentiment
   ORDER BY ProductID, Sentiment;
   

   Supported labels are positive, negative, neutral, and mixed. Counts total 16, including six for P101. Model-generated distributions can vary; use actual results, not predetermined positive or negative counts. Wait until the shortcut reflects all stored labels with null AIError.

8. Remove the process-local configuration and deactivate the environment:

   Remove-Item Env:\FABRIC_SQL_SERVER, Env:\FABRIC_SQL_DATABASE,
       Env:\FOUNDRY_OPENAI_BASE_URL, Env:\SENTIMENT_MODEL_DEPLOYMENT
   deactivate
   

9. Import notebooks\05-enrich-caldova-feedback.ipynb into caldova-challenge-<initials>, attach caldova_lakehouse as default, and select Run all. This notebook includes the documented PySpark AI-function model settings for Runtime 2.0 compatibility, classifies issues through Fabric's built-in AI endpoint, and derives review priority from sentiment. It doesn't call your separate Foundry sentiment deployment.

10. Confirm Validation passed: 16 feedback records enriched and written to customer_feedback_enriched. Valid categories are delivery, packaging, instructions, support, scheduling, and other. Negative sentiment receives high priority, mixed receives medium, and positive or neutral receives standard.

11. Run this query in the Lakehouse SQL analytics endpoint to verify the issue counts:

    SELECT ProductID, IssueCategory, ReviewPriority, COUNT(*) AS FeedbackCount
    FROM dbo.customer_feedback_enriched
    WHERE ProductID = 'P101' AND CategoryAIError IS NULL
    GROUP BY ProductID, IssueCategory, ReviewPriority
    ORDER BY IssueCategory, ReviewPriority;
    

    The groups total six. If you also filter to high priority, no rows is a valid result when this run has no negative P101 sentiment.

Expected result: Foundry sentiment is persisted in the existing SQL source, mirrored into OneLake, and enriched into 16 issue records. AI-generated interpretations don't change the source launch gap.

If rate-limited, wait and rerun the client; it retains completed rows. An invalid label is stored with null sentiment and an error. Resolve the model configuration and rerun rather than resetting the database. If you later change feedback or scores, rerun enrichment so its derived table isn't stale.

1. In the Lakehouse Files, create litware and upload the four CSV files from data\litware directly into that folder.

2. Import notebooks\07-integrate-litware.ipynb into caldova-challenge-<initials>, attach caldova_lakehouse as default, and select Run all.

3. Confirm that input validation completes before table writes. The notebook checks keys, references, mappings, dates, nonoverlapping windows, arithmetic, and expected synthetic outcomes. It creates a stable QualificationID from site and local product, separated by |.

4. Confirm five outputs: litware_plant (3), litware_product_mapping (4), litware_capacity_plan (18), litware_product_qualification (6), and litware_capacity_assessment (18). The assessment is a derived table over the same allocations, not an additional capacity population.

5. Run this query in the Lakehouse SQL analytics endpoint:

   SELECT CaldovaProductID, LitwarePlantID, PlantType, ExclusionReason,
          SUM(AvailableCapacityUnits) AS AvailableUnits,
          SUM(EligibleCapacityUnits) AS EligibleUnits
   FROM dbo.litware_capacity_assessment
   GROUP BY CaldovaProductID, LitwarePlantID, PlantType, ExclusionReason
   ORDER BY CaldovaProductID, LitwarePlantID;
   

6. Verify all six groups:

   Site and local product	Nominal units	Interpretation
   LPL001 / LPR001 -> P101	12,000	Eligible planned Packaging capacity.
   LPL002 / LPR001 -> P101	24,000	Qualification Pending; also Fill Finish, not Packaging.
   LPL003 / LPR001 -> P101	18,000	Earliest readiness November 28, after its windows and launch.
   LPL001 / LPR002 -> P104	9,000	One open critical finding.
   LPL002 / LPR003 -> P113	6,000	Qualification expired October 31.
   LPL003 / LPR004 -> null	3,000	No approved Caldova mapping.

Expected result: Of 54,000 nominal P101 units across different manufacturing stages, 12,000 pass the supplied qualification and timing rules, all at Packaging. Those units are a potential mitigation, not verified end-to-end output. Materials, transfer timing, upstream throughput, and execution approval aren't provided.

1. In caldova-challenge-<initials>, create an Ontology named caldova_launch_ontology.

2. Create and bind the following entity types. For each, select Bind data, choose the specified Lakehouse dbo table, set its entity key, retain properties required by relationships and answers, and review the source data preview.

   Entity	Lakehouse table	Entity key
   LaunchProgram	launch_program	LaunchProgramID
   Product	product	ProductID
   Plant	plant	PlantID
   CapacityPlan	capacity_plan	CapacityPlanID
   Batch	batch	BatchID
   Supplier	supplier	CMOID
   CustomerFeedback	customer_feedback_enriched	FeedbackID
   LitwarePlant	litware_plant	LitwarePlantID
   LitwareProduct	litware_product_mapping	LitwareProductID
   LitwareQualification	litware_product_qualification	QualificationID
   LitwareCapacityPlan	litware_capacity_assessment	LitwareCapacityPlanID

   Retain the Caldova gap, plant, supplier-eligibility, and product properties. Retain customer sentiment, issue category, priority, and classification error. For Litware, retain the supplied columns, QualificationID, EligibleCapacityUnits, and ExclusionReason. Bind assessed capacity, not a second entity over the raw allocations.

3. Describe sentiment and issue categories as AI-generated, submitted comments as synthetic feedback, and Litware eligibility as a derived planning result. Define EligibleCapacityUnits with this task's fixed snapshot, full-window rules, and manufacturing-stage limitation.

4. Create and bind each relationship below. Select the origin and target entities and choose each entity's key property from the preceding table. Enable Use mapping table?, select the specified binding table, and map its origin and target columns to those properties. For mapsToCaldovaProduct, the binding column CaldovaProductID maps to the Product entity's ProductID property. Select Save for each relationship.

   Relationship	Origin -> target	Binding table: origin key -> target key
   launches	LaunchProgram -> Product	launch_program: LaunchProgramID -> ProductID
   hasCapacityPlan	LaunchProgram -> CapacityPlan	capacity_plan: LaunchProgramID -> CapacityPlanID
   plannedAt	CapacityPlan -> Plant	capacity_plan: CapacityPlanID -> PlantID
   hasBatch	LaunchProgram -> Batch	batch: LaunchProgramID -> BatchID
   runsAt	Batch -> Plant	batch: BatchID -> PlantID
   evaluatesSupplier	LaunchProgram -> Supplier	supplier: LaunchProgramID -> CMOID
   receivesFeedback	Product -> CustomerFeedback	customer_feedback_enriched: ProductID -> FeedbackID
   mapsToCaldovaProduct	LitwareProduct -> Product	litware_product_mapping: LitwareProductID -> CaldovaProductID
   allocatedAtLitwarePlant	LitwareCapacityPlan -> LitwarePlant	litware_capacity_assessment: LitwareCapacityPlanID -> LitwarePlantID
   allocatesLitwareProduct	LitwareCapacityPlan -> LitwareProduct	litware_capacity_assessment: LitwareCapacityPlanID -> LitwareProductID
   governedByQualification	LitwareCapacityPlan -> LitwareQualification	litware_capacity_assessment: LitwareCapacityPlanID -> QualificationID
   qualifiesAtLitwarePlant	LitwareQualification -> LitwarePlant	litware_product_qualification: QualificationID -> LitwarePlantID
   qualifiesLitwareProduct	LitwareQualification -> LitwareProduct	litware_product_qualification: QualificationID -> LitwareProductID

5. Review the bound records and relationship columns: LP001 resolves to P101 and related Caldova evidence; LPR001 maps to P101; allocations resolve to their own sites and qualifications. LPR004 remains without a Caldova product relationship.

6. Confirm 11 entity types and 13 bound relationship types, with each binding saved. The next key task validates this context in a data agent; a materialized ontology graph isn't required.

Expected result: The ontology supplies shared vocabulary and relationships without a streaming dependency. It is like a manufacturing route map: connecting stations explains how they relate, but doesn't certify every route or make different stages' capacities interchangeable.

The ontology adds modeling and maintenance work. Its value here is reusable meaning across acquired identifiers and product-site qualifications; it doesn't replace the source calculation or permissions.

1. In caldova-challenge-<initials>, create caldova_ontology_data_agent. In Sources > Add sources > Add an ontology, select caldova_launch_ontology. Review its 11 entities and underlying Lakehouse source. Use the preview runtime when available, as recommended by the ontology-context documentation.

2. Confirm that the bound Lakehouse tables are available for queries. Mount the underlying Lakehouse source to add source instructions and SQL examples. Select only the 11 ontology-bound tables, not streaming history or the raw feedback shortcut. Reuse the planning source instructions and two SQL examples from code\06-fabric-data-agent-snippets.txt, then add the customer and Litware guidance below.

3. Add these agent instructions:

   Use the ontology context and its underlying Lakehouse for Caldova
   launch-readiness questions. The launch record is authoritative for the original
   gap and binding plant. Use litware_capacity_assessment for derived eligibility
   and join qualifications by QualificationID. Different manufacturing stages
   aren't interchangeable, and nominal capacity isn't eligible output. Don't
   invent a mapping for LPR004. Customer sentiment and issue categories are
   AI-generated, not verified intent. State supporting records and relationships.
   

4. Add the source guidance for customer counts:

   customer_feedback_enriched has one row per FeedbackID and joins to product on
   ProductID. Its Sentiment comes from the scored SQL records through the shortcut;
   IssueCategory is AI-generated and ReviewPriority is derived. Use this table
   for customer summaries without joining to every supplier or capacity row.
   Exclude CategoryAIError failures from issue summaries and state excluded counts.
   Don't change launch facts based on customer tone.
   

5. Add this sentiment example over the ontology-bound feedback table. Its counts must match the persisted SQL distribution from the first key task:

   SELECT ProductID, Sentiment, COUNT(*) AS FeedbackCount
   FROM dbo.customer_feedback_enriched
   WHERE ProductID = 'P101'
   GROUP BY ProductID, Sentiment
   ORDER BY Sentiment;
   

6. Add the issue-count query from this task and the following capacity example:

   SELECT CaldovaProductID, LitwarePlantID, PlantType,
          SUM(AvailableCapacityUnits) AS NominalUnits,
          SUM(EligibleCapacityUnits) AS EligiblePlannedUnits
   FROM dbo.litware_capacity_assessment
   WHERE CaldovaProductID = 'P101'
   GROUP BY CaldovaProductID, LitwarePlantID, PlantType;
   

   Confirm nominal values of 12,000, 24,000, and 18,000 for the three sites. Only LPL001 has eligible planned units: 12,000 at Packaging.

7. Ask the following question, inspect the queries and relationship context, and publish the data agent after it returns the source-backed result:

   For LP001, explain whether Litware can eliminate the launch gap and which
   customer concerns need attention. Include product mapping, qualification,
   readiness, manufacturing stage, and feedback counts. Preserve original
   launch facts and distinguish evidence from recommendations.
   

   Expect the original 18,900-unit, 7% gap and PL003, the limited 12,000-unit planned Packaging contribution, and customer groups totaling six for P101. A 6,900-unit arithmetic remainder is conditional, not a verified revised launch gap.

8. Publish caldova_ontology_data_agent to Microsoft Copilot. In the Fabric data agent, select the option to make the agent available in Microsoft Copilot, and select Publish to Agent Store. Wait for publishing to complete.

   The Fabric data agent must be published before it can be used from Microsoft Copilot. Publishing to the Agent Store registers the Fabric data agent so that users can interact with it through Microsoft Copilot.

9. Open Microsoft 365 Copilot using the same account that you used with Microsoft Fabric. The Fabric data agent and Microsoft Copilot must be in the same tenant, and you must sign in to both with the same account.

10. Expand the navigation pane and open Agents. Locate and select caldova_ontology_data_agent. If the agent doesn't immediately appear, expand or refresh the navigation pane and check again. It can take a few seconds after publishing for a Fabric data agent to appear in the Agent Store.

11. Start a new conversation with caldova_ontology_data_agent and ask:

    For LP001, explain whether Litware can eliminate the launch gap and which
    customer concerns need attention. Include product mapping, qualification,
    readiness, manufacturing stage, and feedback counts. Preserve original
    launch facts and distinguish evidence from recommendations.
    

12. Review the response. Confirm that it:

    • Preserves the original 18,900-unit, 7% launch gap and PL003 binding plant.
    • Distinguishes the 54,000 nominal P101 units from the 12,000 eligible planned Packaging units.
    • Doesn't treat Fill Finish capacity as Packaging capacity.
    • Reports customer-feedback groups totaling six records for P101.
    • Distinguishes source facts, AI-generated customer interpretations, and recommendations.

13. Start a new conversation with caldova_ontology_data_agent and ask:

    Which Caldova product does LPR004 represent?
    

14. Confirm that the agent identifies that LPR004 doesn't have an approved Caldova product mapping rather than inventing a relationship to an existing Caldova product.

Expected result

Expected result: The ontology-grounded Fabric data agent is published to Microsoft Copilot and uses the shared business context to explain Litware's potential contribution and customer concerns. It preserves the original launch facts, distinguishes 54,000 nominal P101 units from 12,000 eligible planned Packaging units, reports the source-backed customer counts, and doesn't invent a Caldova mapping for the unmapped Litware product.

If context appears stale or a bound table is missing, refresh the ontology context in the data agent. Inspect Download ontology context to confirm the expected bindings, then check the mounted Lakehouse and selected tables. Inspect the generated query and run it against the source before republishing the data agent and starting a fresh Microsoft 365 Copilot conversation.

1. In Microsoft 365 Copilot, remove both caldova_business_data_agent and caldova_ontology_data_agent from your agent list.
2. In Foundry, delete the model deployments you created in your operational and enrichment projects, including any approved substitute or timeout-recovery deployment. Delete caldova_foundry_ops if it isn't removed with its project.
3. In the Azure portal, delete your dedicated caldova-operations-<initials>-rg and caldova-enrichment-<initials>-rg resource groups. Don't delete any shared resource group.
4. In Fabric, remove caldova-challenge-<initials> through Workspace settings > General > Remove this workspace. Confirm its name before deletion.
5. Confirm the challenge workspace no longer appears in Workspaces and both dedicated resource groups are deleted or completing deletion. Verify that no challenge-owned model deployments remain outside them. Retain the shared Fabric capacity.
6. Close the PowerShell windows used for simulator credentials and scoring configuration. Remove the extracted package and virtual environment when you no longer need them.

Expected result: Your solution resources are removed, and shared services remain available.