azmon-mirroredcatalogs-operations-cli

Business entities named anywhere in this Skill or its references — bookings, orders, customers, flights, revenue, tenants, payments, and similar — are EXAMPLES ONLY. The Skill MUST NOT infer the user's business domain from these examples. The user's actual business entities MUST be discovered from real Fabric data (Eventhouse / KQL database / Warehouse / Lakehouse / shortcuts) and confirmed with the user before use.

To be explicit:

• Examples are illustrative only. Every business-entity name in this Skill and its references (e.g. bookings, orders, customers, revenue, flights, tenants, payments) is a non-normative illustration, not a required or expected entity.
• The Skill is domain-agnostic. It applies to any business domain and assumes none.
• The Skill MUST NOT infer or assume the user's business domain from the illustrative examples, from table or column names that happen to resemble an example, or from any prior context.
• Business entities MUST be discovered from the user's actual data and, until discovered and confirmed, MUST be referred to generically — as business entities, business datasets, business KPIs, or business outcomes — rather than by any assumed domain-specific name.

1. Intent and scope
2. Log Analytics workspace selection
3. Fabric workspace selection
4. Identity selection and validation
5. Connection resolution
6. AzMon / Mirrored Catalog item creation or reuse
7. Business Insight Capture (optional here; may be deferred — intent MUST be captured/confirmed before schema verification, Stage 12)
8. Azure Monitor table discovery
9. Eventhouse / KQL database target selection (default auto endpoint vs a specific/new Eventhouse)
10. External Delta table registration planning
11. External Delta table registration
12. Schema and data verification
13. Business data discovery and scoring
14. Correlation planning
15. Optional dashboard suggestion and creation
16. Operations Agent instruction generation (optional — gated: only if the user wants an agent)
17. Optional Operations Agent creation / validation

• The Skill MUST track and enforce the current stage.
• The Skill MUST NOT skip stages.
• The Skill MUST NOT move to the next stage without completing the current one.

Begin every response with this structure, written as normal chat text (not a code block):

• Current stage: <stage name>
• What I found: <short summary>
• Next step: <one clear action>

Then close with a line inviting the user to confirm before continuing (e.g. “Waiting for your confirmation to continue.”).

If the current stage is unclear → STOP and ask the user where to resume.

After presenting any step that requires confirmation:

• STOP.
• WAIT for explicit user confirmation.
• Do not continue automatically.

• Selecting the identity for the flow (Stage 4) — recommend Service Principal, but WAIT for the user's choice before validating.
• Creating or reusing any resource that modifies Fabric.
• Provisioning the Fabric workspace identity and assigning its Log Analytics role (Stage 5, Mode B workspace-identity option) — WAIT before each write.
• Selecting the Eventhouse target (a specific existing Eventhouse, or a new one).
• Creating shortcuts in the chosen / new Eventhouse — explicitly show the target Eventhouse and exactly what will be created.
• Proceeding from schema verification (Stage 12) to correlation planning (Stage 14).
• Creating or modifying a dashboard (present suggestions and WAIT for approval first).
• Building an Operations Agent at all (Stage 16) — explicitly ask whether the user wants an agent before generating any instructions. If they do not, skip Stages 16–17; the flow may end after the dashboard.
• Generating final Operations Agent instructions if the correlation model has not been confirmed.
• Creating or modifying an Operations Agent.

• External Delta table registration planning (Stage 10) MUST occur before schema verification or join logic. If schema/join is attempted early → STOP and return to Stage 10.
• External Delta table registration (Stage 11) MUST complete before schema verification.
• Schema verification (Stage 12) MUST complete before correlation planning (Stage 14).
• If data is not queryable in Eventhouse via the registered external delta tables → STOP → return to Stage 10/11.
• Correlation planning MUST NOT begin until external-table queryability is confirmed.
• Business Insight Capture (Stage 7) MAY be answered early or deferred so the user can explore their data first, but intent MUST be captured/confirmed (intent provided OR a suggested direction explicitly selected) before schema verification (Stage 12) and correlation planning. Never assume intent.

The Skill MUST NOT run arbitrary shell/CLI/az/PowerShell commands, perform network debugging, investigate server connectivity, or execute infrastructure troubleshooting. These are out of scope unless explicitly part of the current stage.

Narrow exception — Fabric REST read-only discovery. The Skill MAY use an authenticated az rest --method get call ONLY for Fabric REST read-only discovery, and ONLY when ALL of the following hold:

• The endpoint is https://api.fabric.microsoft.com/....
• The HTTP method is GET only.
• The operation is discovery / read-only only.
• Nothing is created, updated, deleted, or modified (no Fabric items, shortcuts, mirrored catalog items, or connectors via CLI).
• No tokens, secrets, raw auth headers, or sensitive payloads are exposed.
• The Skill clearly states the capability path used.

This exception does NOT permit arbitrary shell/CLI execution, non-GET az rest calls, or use of the Kusto / KQL data-plane when disabled.

Narrow exception — Fabric workspace-identity provisioning + LA role assignment (Mode B only). In the Mode B workspace-identity option, the Skill MAY use authenticated az calls to detect/provision the workspace identity and, when the caller is permitted, assign its Log Analytics role, limited to:

• GET https://api.fabric.microsoft.com/v1/workspaces/{id} (detect), and
• POST https://api.fabric.microsoft.com/v1/workspaces/{id}/provisionIdentity (provision) plus GET polling of its long-running operation, and
• az role assignment list (check) and az role assignment create at the Log Analytics workspace scope to grant the identity Owner, but ONLY when the caller holds Microsoft.Authorization/roleAssignments/write there.

Each write is confirmation-gated (Stage 5), touches only the workspace identity and its LA role (nothing else), exposes no tokens/secrets/auth headers, and the Skill states the capability path used. If the caller lacks role-assignment permission, the Skill MUST NOT force it — it instructs the user / an admin to run the assignment instead. This does NOT permit any other non-GET az rest calls or any broader az usage.

Behave like a guided product experience, not a backend debugger.

• Use concise, business-friendly language.
• Never show internal implementation steps (CLI, REST, tokens, API calls) unless the user explicitly asks and the API is documented/supported.
• Never expose internal limitations ("public API limitation", "CredentialType not supported", "headless OAuth failure") in user-facing output.
• Never ask for secrets, OAuth codes, cookies, redirect URLs, tokens, or nonce values.
• Summarize findings. Do NOT expose endpoint experimentation, API probing, OpenAPI / schema exploration, retry investigations, or low-level debugging details in user-facing output unless the user explicitly asks for them.
• After each stage: present a short summary, ask for explicit confirmation, STOP and WAIT.

When the user names a workspace and no exact match exists, the Skill MUST NOT fail. Instead:

1. Ask for the subscription if not provided (do not guess).
2. Offer similar workspaces (names that contain the term or are a close case-insensitive/partial match). Broaden the search if a narrow filter returns nothing.
3. Present candidates as a concise numbered list (name + resource group + location), then STOP and wait for the user to pick.
4. If exactly one similar workspace is found, still confirm before proceeding.
5. If none is found, say so plainly and ask for a different subscription or term.

Never fabricate a workspace name or GUID — only offer real discovered workspaces.

Fabric workspaces are not Azure Resource Manager resources, so absence of an automatic enumeration path does NOT mean no Fabric workspace exists. Never terminate the workflow early: if automatic discovery fails, ask the user for a Fabric Workspace Name, ID, or URL, validate it as far as the available capabilities allow, and continue. Never auto-select a workspace, never fabricate a workspace or a validation result, and mark Stage 3 BLOCKED only after every discovery mechanism AND every user-supplied resolution path has been exhausted.

Follow the full discovery order, the interpretation rules, and the UI-guided last-resort boundary in references/workspace-discovery-policy-reference.md.

Validation MUST run against the identity that will actually perform the flow, so the identity is chosen before any validation check — not deferred to Stage 5. Do NOT silently reuse whatever az happens to be signed in as.

Present the choice and STOP — ask this as normal chat text (a plain numbered list, not a code block):

Which identity should I use for this onboarding?

1. Service Principal (recommended) — automated, non-interactive; best for repeatable runs and CI. Requires tenant id, app/client id, and a securely provided secret/certificate.
2. Your user account (interactive sign-in) — if you prefer to run as yourself, or a Service Principal is not available.

Invite the user to reply 1 or 2; note that Service Principal is recommended.

• Recommend Service Principal, but let the user choose. If the user asks to sign in as themselves, allow interactive user login and continue as the user.
• After the choice, confirm the effective identity (e.g. az account show) so validation runs against the right principal. If it does not match the chosen identity, stop and resolve the sign-in before validating.
• Carry the chosen identity forward: Stage 5 connection resolution and all later Fabric-modifying actions use this same identity.

Before any creation, verify for that identity:

• The workspace exists.
• The chosen identity has the required Log Analytics access.
• The chosen identity has sufficient Fabric workspace permission to operate (and, for a Service Principal, that the tenant setting "Service principals can use Fabric APIs" is enabled).
• Surface early that connection detection/reuse will later need the chosen identity to hold a role on the Azure Monitor connection (a User role is enough; Owner is not required), so a permission gap is caught here rather than at Stage 5.
• For the Mode B workspace-identity connection option (Stage 5), the chosen identity must be a workspace Admin (required to provision the workspace identity). The Skill can assign the identity's Log Analytics role itself when the caller holds role-assignment permission (Owner / User Access Administrator) on the LA scope; otherwise it instructs the user. Surface both early.

If validation fails, summarize which checks passed/failed in user terms, explain the missing capability, and offer to try another workspace, grant the missing permission, or switch identity. See references/azmon-fabric-api-reference.md for supported-scope rules.

Before declaring validation capability unavailable, the Skill MUST determine whether the environment provides one of the following:

• Fabric REST APIs
• Azure REST APIs
• Fabric Actions
• Azure CLI
• Azure Resource Graph

MCP availability is only one possible execution path.

The Skill MUST report validation capability unavailable only after evaluating all supported execution paths and finding none.

Before declaring validation capability unavailable, the Skill MUST:

1. Determine whether another supported execution path exists.
2. Attempt capability discovery using all supported mechanisms available in the current environment.
3. Only after all supported mechanisms have been evaluated and none are available may the Skill declare the capability unavailable.

The identity was already chosen and validated in Stage 4 (Identity selection). Use that identity here — do not re-prompt unless the user changes it. Map the chosen identity to its connection mode:

1. Service Principal → Mode A. If a matching Service Principal connector already exists for the same Log Analytics workspace, reuse it. Otherwise, when the required Service Principal inputs are available (tenant id, app/client id, and a securely-provided secret/certificate reference), create-or-reuse the Service Principal connector automatically — no UI step.
2. User / interactive → Mode B. Use when the user chose to sign in as themselves, the Service Principal is unavailable, or the tenant disallows it. In Mode B, first prompt the user to choose the connection authentication method — interactive OAuth or workspace identity (see "Mode B — choose connection authentication" below) — then route to that sub-branch.

To be discoverable, a connection must have at least one role assigned to the calling identity — whether the Service Principal (Mode A) or the user (Mode B). Any assigned role makes it appear in the listing and reusable; a User role is enough for detection and reuse, and Owner is only needed to manage / modify / delete it. If the caller holds no role on a connection, the API will not return it — that is by design, not a failure.

Therefore, if the search finds no matching connection, the Skill MUST NOT immediately conclude the connection does not exist. It MUST first consider that the connection may exist but simply be invisible to the current identity because it holds no role on it, and:

• State that a matching connection was not found for the current identity, and that this can mean either (a) no such connection exists, or (b) one exists but the calling Service Principal / user holds no role on it.
• Advise assigning the Service Principal or user a role on the existing Azure Monitor connection (for the same Log Analytics workspace) — a User role is enough for detection and reuse — then re-run detection. (If a Service Principal still can't see it after a lower role is granted, see the Service Principal note in references/azmon-fabric-api-reference.md.)
• Only after this permission possibility has been surfaced may the Skill proceed to create a new connector (Mode A) or the OAuth create-once guidance (Mode B).

Never fabricate a connection or claim one exists without a real listing match.

Portal-guided instructions are permitted ONLY for OAuth Azure Monitor connector creation.

Portal guidance is NOT an allowed fallback for:

• LAW validation
• Fabric workspace validation
• Connection detection
• Connection reuse
• Service Principal connector creation
• Mirrored Catalog item creation
• Discovery
• Monitoring
• Refresh
• Eventhouse shortcut creation
• Schema verification
• Operations Agent creation

If execution capability for these actions is unavailable, the Skill MUST stop and identify the missing capability.

Present this as "connect using Service Principal" — the automated, non-interactive path (no user login, no UI step). This is the preferred default; attempt it before OAuth.

• Idempotent create-or-reuse: if a matching Azure Monitor Service Principal connector already exists for the same Log Analytics workspace (same data source path + Service Principal credential type), reuse it — never create a duplicate.
• Only one connector is created per run.
• Never reuse a non-Service-Principal (e.g. OAuth) connector in this mode.
• Never ask the user to paste a client secret into chat. Secrets come from environment variables or Key Vault references only, are never echoed, logged, exposed, or included in generated instructions.
• If required Service Principal inputs are missing, describe what is missing (tenant id, app/client id, and a securely-provided secret reference) using presence checks only — never request the secret value in chat. Only when Service Principal inputs cannot be provided, fall back to OAuth (Mode B).

Automation boundary: infrastructure (connector create-or-reuse, mirrored item creation) is automated; business decisions (Eventhouse/KQL DB selection, shortcut creation) always require explicit user confirmation.

When the chosen identity is User / interactive (Mode B), the connection can be created two ways. Before detecting or creating anything, present this choice as normal chat text (a plain numbered list, not a code block) and STOP for the user's answer:

How should I authenticate the Azure Monitor connection?

1. Interactive sign-in (OAuth) — you sign in once in Fabric → Manage Connections; the connection uses your organizational account.
2. Workspace identity (no secrets) — Fabric's automatically-managed workspace identity is used as the credential; you grant it access on your Log Analytics workspace. No secret to handle.

Route to the matching sub-branch below — 1 → Mode B (OAuth), 2 → Mode B (Workspace identity). Keep the two strictly separate. If the user has no preference, note that workspace identity avoids interactive sign-in and secret handling, but WAIT for their choice — never auto-select.

Use this sub-branch when the user picked option 1 above, i.e. only when Service Principal (Mode A) is unavailable or the user explicitly requests OAuth. OAuth connector creation is UI-guided only (Fabric → Manage Connections) — the Skill never creates one through an API; it only detects and reuses an existing connection, read-only, and only when the Log Analytics workspace matches exactly.

Follow the full detection order, reuse rules, and user-facing wording in references/oauth-connection-reference.md. Keep this strictly separate from Mode A.

Use this sub-branch when the user picked option 2 above. Fabric's automatically-managed workspace identity is used as the connection credential (no secret). This flow provisions the identity if needed, ensures it has a sufficient Log Analytics role — assigning it automatically when the caller is permitted, otherwise instructing the user — then creates the connection.

Follow the full sequence, endpoints, gates, and payloads in references/workspace-identity-connection-reference.md. Key gates: provisioning the identity is confirmation-gated (caller must be workspace Admin); the LA role is assigned by the Skill when the caller holds role-assignment permission (else the Skill instructs and WAITs for confirmation) — both writes are confirmation-gated; then create the connection using the WorkspaceIdentity credential type. Keep this strictly separate from Mode A.

Per Microsoft Learn, the Create Mirrored Catalog API lists service principals and managed identities as supported identities for create, so a Service Principal create is documented as supported and is not an absolute platform limitation.

Observed fallback. Some Service Principal runs have nonetheless seen the item create rejected under an application-only token (the underlying item-creation path can run on-behalf-of a signed-in user). Treat this as observed tenant behavior, not a documented rule, and keep the docs-accurate default: attempt create under the SP, and only fall back to a user (delegated) / UI context if the create call is actually denied or unavailable.

Get, list, update, discovery, monitoring, refresh, and shortcut operations all work under an application-only SP token once the item exists.

Consequently, when running under a Service Principal, the Skill MUST:

• Prefer reuse — reuse an existing Azure Monitor Mirrored Catalog item (and its existing connection) that the SP can see and operate on. This is the preferred path: build on an already-created item + connection rather than creating a new one. The SP can then update and operate that item normally.
• If no reusable item exists, attempt to create the item under the SP (the create API documents SP/managed-identity support). Only if that create is denied or unavailable (the observed fallback above), create the item in a user context — either from the Fabric UI, or via a user (delegated) sign-in — preferably seeded from an existing item and connection. After the item exists, the Service Principal can resume the automated flow (update, discovery, monitoring, refresh, shortcuts) on that item.
• Never claim the item was created by the SP when the create actually occurred in a user/UI context.

Downstream Mirrored Catalog operations (update, discovery, monitoring, refresh) remain available to the Service Principal once the item exists.

The item does not take a free-form list of table names — it mirrors by scope (a namespace hierarchy path in the definition), and that scope MUST be a Selectable value returned by the List Scopes discovery API. To target only the tables the user wants:

• Call List Scopes and choose a Selectable scope for the item. If the user already knows the target tables, pick the narrowest Selectable scope that covers them. If there is no intent yet (the user wants to explore first), create with a broader scope and optionally re-scope narrower later — updating the item definition — once intent is captured. Use only real returned scope values — never fabricate a scope or table name.
• If the narrowest available Selectable scope is broader than the requested set, the item will also mirror the extra sibling tables under that scope — mirroring cannot exclude individual siblings. State this plainly and get explicit confirmation before creating.
• For an existing/reused item, read its current definition scope before assuming it matches the request; do not fabricate definition fields.

Unless the user specifies otherwise, the default set of tables to mirror is every table that (a) appears in real List Scopes / Discovery output and (b) matches one of these name prefixes (case-insensitive; tolerate the _CL custom-table suffix):

• App* — Application Insights tables
• OTel* — OpenTelemetry-native tables (e.g. OTelLogs)
• XD* — custom, security-related log tables

Then ask the user whether they want any additional tables before creating (confirmation gate — present the resolved set and WAIT).

• Match prefixes against real discovered tables only — never invent a table. If a prefix matches nothing, omit it silently.
• Resolve the default set to the narrowest single Selectable scope that covers all matched tables. If that scope also pulls in extra sibling tables beyond the default set, list the extras explicitly, explain that siblings cannot be individually excluded, and get confirmation before creating. Once confirmed, the extras are expected — they are not failures at the Stage 8 equality check.
• Adding user-requested tables may widen the chosen scope — re-resolve and re-disclose.
• If none of App* / OTel* / XD* match any discovered table, fall back to presenting all/representative discovered tables (explore-first) and let the user choose.
• XD* security tables are only considered after the workspace has passed Stage 4's validation (a supported, validated workspace); an unsupported-workspace block takes precedence and table selection MUST NOT be used to bypass it.
• On reuse: read the existing item's current scope and compare its mirrored set to the default set. If not fully covered, offer to re-scope (update the item definition) to add the missing App*/OTel*/XD* tables, disclosing any extra siblings — never re-scope silently; confirm first.

The confirmed set (default + confirmed siblings + any tables the user adds) becomes the expected set for the Stage 8 requested-vs-mirrored equality check.

For a first-time mirrored workspace, tell the user upfront that mirrored tables and data typically take around 5 minutes to materialize and become queryable after the item is created. Until then, discovery/queries may return empty or partial results — this is expected, not an error. Do not declare tables missing during this window: verify mirror/refresh status, wait, and re-check before concluding anything.

After the item is created or reused, optionally capture business intent now (Stage 7) if the user already has a goal; otherwise proceed to table discovery and exploration and capture intent before schema verification (Stage 12).

The Skill MUST NOT proceed to schema verification (Stage 12) or business correlation (Stage 14) without either:

• (a) user-provided business intent, OR
• (b) explicit user selection from suggested directions.

Intent may be provided here or after exploration, but it MUST exist before Stage 12. Never assume intent.

Suggest 3–5 directions, each framed as observability signal → business impact, and ask the user to choose one:

1. Availability failures → booking completion impact.
2. Request latency → conversion or checkout drop.
3. Exceptions → failed orders or revenue at risk.
4. Dependency failures → customer / tenant / region impact.
5. Traffic drops → usage KPI degradation.

Capturing intent early is allowed but optional — it MUST exist before schema verification (Stage 12). Either way, the Skill MUST NOT generate correlation logic yet. Correlation logic only comes after shortcuts exist, schema is verified, data is queryable, dynamic fields are inspected, join candidates are validated, and data freshness is checked (Stages 10–14).

The primary discovery mechanism is the Mirrored Catalog Discovery APIs. If discovery appears incomplete, do NOT immediately conclude tables are missing or switch to alternative metadata paths. First:

1. Verify mirror status.
2. Verify refresh / sync status.
3. Verify discovery scope.
4. Retry discovery.

Only after these checks may the Skill evaluate alternative metadata paths. See references/mirrored-catalog-reference.md.

This check applies once a requested table set exists — whether specified up front or after intent is captured later. When the default mirror set (Stage 6) or a user-adjusted set is in effect, that set is the requested set for this check, and any sibling tables disclosed and confirmed under the narrowest-common- scope rule are expected (compare against the chosen scope's expected contents, not a bare table list — do not report confirmed siblings as failures). When the user asked for a specific set of tables, verify the item mirrors exactly that set — use equality, not subset ("my tables are present" is not enough). Compare the actually-mirrored table set (from Discovery / Monitoring) against the requested set and report the result:

• Extra tables present → the chosen scope is broader than requested. Report the extras and, if a narrower Selectable scope exists, offer to re-scope; otherwise state that the source only exposes a broader scope and the extras are unavoidable.
• Requested tables missing → the mirror may not have materialized yet. Verify mirror/refresh status, run a Refresh/sync, wait, then re-check — do not declare them absent prematurely.
• Exact match → confirm and proceed.

Never fabricate the mirrored table set; enumerate it from real Discovery / Monitoring results only.

Query acceleration is a policy on external delta tables (set via .alter external table … policy query_acceleration), not a shortcut-object property. Every registered external delta table gets acceleration enabled (true) — not optional. Include an Acceleration Enabled (always Yes) plan-table column; if the environment can't support it, surface that rather than registering without the policy. Full policy in references/eventhouse-shortcuts-reference.md.

1. Operational telemetry tables are available in the Eventhouse / KQL database.
2. Business tables are available in the same database or queryable via shortcuts.
3. Tables are queryable, not just visible in OneLake.
4. Schema retrieved via getschema.
5. Dynamic fields inspected and sampled.
6. Candidate join keys extracted from top-level and dynamic columns.
7. Join keys validated with non-zero match results (when a direct join is proposed).
8. Data freshness verified.
9. Time window aligned to the real data range.
10. Relevant categorical values confirmed from real data where rules depend on them.

Query convention. Mirrored telemetry tables are external tables — query them via external_table('<name>') (they do not appear in .show tables); business tables that are managed in an Eventhouse use their bare name.

1. Retrieve real schema. For each table: external_table('<TableName>') | getschema | project ColumnName, ColumnType. Use authoritative column names/types — not names guessed from screenshots or table names.

2. Inspect and sample dynamic fields. Business join keys are often nested in dynamic columns (Properties, CustomDimensions, Details, Measurements, Payload, Context). Sample rows and inspect keys. See references/app-insights-dynamic-fields-reference.md.

3. Extract candidate business identifiers with explicit KQL (tostring(Properties.BookingId), with casing fallbacks via coalesce).

4. Validate join keys against real data. Prove a candidate joins — run the join and confirm non-zero matches:

   Copy

   external_table('AppEvents')
   | extend BookingId = tostring(Properties.BookingId)
   | where isnotempty(BookingId)
   | join kind=inner (Bookings | project BookingId = tostring(BookingId)) on BookingId
   | summarize MatchedRows=count(), DistinctBookings=dcount(BookingId)

   Non-zero → direct join, high confidence. Zero → the key is wrong or data doesn't overlap; find the real one.

5. Check freshness and align the window. external_table('<TableName>') | summarize Rows=count(), MinTime=min(TimeGenerated), MaxTime=max(TimeGenerated). Do not assume ago(1h); use a window covering the actual data range and explain it in user terms.

6. Confirm categorical values used by rules (external_table('<Table>') | summarize count() by <field>) so impact rules use real categories.

Telemetry source selection MUST be data-driven. Before selecting a correlation model, the Skill MUST inspect ALL candidate telemetry sources discovered (e.g. AppEvents, AppExceptions, AppRequests, AppDependencies, AppTraces, AppPageViews, AppBrowserTimings, AvailabilityResults, and any other telemetry source present) — not just one.

Score each candidate telemetry source by:

1. Business identifiers discovered.
2. Dynamic-field richness.
3. Direct-join confidence.
4. Validated match count.
5. Business-process context.
6. Relevance to the selected business goal.

Select the highest-scoring telemetry source. The Skill MUST NOT automatically prioritize AppExceptions, and MUST NOT automatically prioritize AppEvents — the winner is whichever source scores highest against real data.

Before Stage 14, ALL must hold: schema retrieved via getschema; join keys validated with non-zero matches (when a direct join is used); freshness verified and window aligned; relevant categorical values confirmed. If any fails → STOP, do not proceed.

Present a concise summary (verified join keys, match results, business impact if any, data time window). Then ask: "Do you want to continue to business analysis (impact modeling, a dashboard, and optionally an Operations Agent) based on this verified model?" HARD STOP and wait. On confirmation, continue with Stages 13–17 as defined in references/business-analysis-workflow.md.

• Enforce stages, hard stops, and confirmation gates.
• Keep OAuth (UI-guided) and Service Principal (automated create-or-reuse) strictly separate.
• Validate permissions before creation.
• Verify schema, dynamic fields, join matches, and freshness before correlation.
• Provide explicit KQL in Operations Agent instructions.

• Service Principal (automated) over OAuth (UI-guided) for connection resolution; fall back to OAuth only when Service Principal is unavailable.
• Direct joins over time-window correlation.
• Real discovered values over anything guessed.
• Business-language confirmation over technical questions.

• Do not depend on or mention MCP in the user-facing flow.
• Do not present internal/undocumented APIs as supported.
• Do not claim OAuth connector creation via public API.
• Do not fabricate workspaces, tables, schema, IDs, or query results.
• Do not ask for secrets, OAuth codes, tokens, cookies, or nonces.
• Do not claim causality when only time-window correlation exists.

User: "In my Observability workspace, onboard our Azure Monitor / Log Analytics observability data (it holds our Application Insights tables) into Fabric, then tell me whether last week's latency spike hurt checkout conversions."

Skill behavior: Runs the staged workflow — confirms the target workspace and checks onboarding prerequisites (a reachable Azure Monitor / Log Analytics source or connection), stopping with an explicit list of what is missing if any prerequisite is absent. Once the observability data (including the Application Insights telemetry tables) is onboarded and queryable, it discovers the real business dataset in the workspace, correlates the latency signal against the conversion KPI using discovered keys, and reports a specific business-impact conclusion (or an error if the required data is unavailable). It never fabricates workspace names, tables, or query results, and never exposes tokens or connection internals.

User: "Create a new Spark notebook and build a Delta table pipeline to load my business dataset."

Skill behavior: Declines the out-of-scope authoring request, creates nothing in Fabric, and directs the user to the appropriate authoring mode in spark-cli rather than taking over the task.