The delivery problem
Onboarding energy clients means interpreting hierarchy exports, tag spreadsheets, historian metadata, and business rules. Those inputs need to become platform sites, assets, fields, and mappings without silently discarding their meaning.
A canonical specification and typed operations
I built an MCP server and skill exposing operations to derive an onboarding package, check signal coverage, explain blockers, plan work, generate runtime bundles, simulate or apply supported phases, and verify results.
The canonical client specification connects environment access, saved analytics logic, and onboarding into one reusable delivery workflow.
Make ambiguity reviewable
Source names are retained while heterogeneous inputs are normalized. Ambiguous mappings become explicit review items, not assumptions hidden in generated configuration.
That distinction matters when a rule change affects a ranking criterion, event classification, site list, or playbook.
Simulate, apply supported phases, verify
The workflow separates planning and simulation from application. It persists onboarding runs and operations in the backend for auditability.
Execution coverage is expanding across connectors, data-quality checks, and rollout. This is not a claim that every connector or onboarding phase is already automated.
What changed for the data science team
A business-rule change can become a task/config iteration instead of an application release. The workflow reduces repeated discovery work and release dependencies while keeping blockers and execution records visible.
Explore the analytics packages this delivery work builds on →
Conceptual lifecycle based on the résumé. Internal specifications, connector credentials, and client mappings are not published.