FAQ
Is the accelerator platform-agnostic?​
The core pipeline logic is designed to be platform-agnostic where possible, but the execution and operational layers still need platform-specific adapters.
Where should our team make changes first?​
Most client teams work in their own Git Repository based on our examples (optionally) called fabric_example/, together with the relevant data contracts. Shared framework changes are usually the exception rather than the starting point.
Do we need to edit the shared framework packages?​
Usually not. Start with contracts, notebooks, jobs, parameter files, and environment configuration in the example implementation. Move into the shared framework only when the requirement cannot be handled through configuration or example-level customization.
Why have a platform switch in the docs?​
Because hiding platform divergence inside generic text creates ambiguity. The switch makes the shared story stable while letting the implementation notes change by platform.
Does the Capabilities browser replace these docs?​
No. The Capabilities browser is the source-surface explorer. These docs explain architecture, workflows, tradeoffs, and operational practices.
What should we treat as the main sources of truth?​
Use the data contract hub for model intent, the example implementation for configuration and execution, and these docs for platform workflows and operating guidance.
What are the most common infrastructure gotchas?​
- Key Vault soft-delete and purge-protection behavior during redeployments.
- Storage naming rules and container placement.
- Missing RBAC for managed identities or access connectors.
What are the most common data-plane gotchas?​
- Treating cast failures and constraint failures as the same issue.
- Debugging a platform wrapper before checking shared Silver logic.
- Forgetting to document contract changes and validation expectations together.