Transition Plan
Current State Snapshot
The current NeuralOps accelerator landscape already proves demand and technical direction, but it is still shaped more like a solution accelerator than a stable platform product.
- The backend remains structurally close to a Flask-era monolith even where async patterns are already emerging.
- Administrative and user-facing experiences are split by tool surface rather than by durable platform contract.
- Azure Functions, orchestration helpers, data abstractions, and infrastructure assets already hint at separable runtime concerns.
- Domain use cases such as complaint analysis and triage are bundled too close to shared platform capability.
Target Gaps To Close
| Current Pattern | Future-State Boundary | Why It Matters |
|---|---|---|
| Flask-centric backend and batch jobs | Control plane, runtime plane, and knowledge plane services | Makes scaling, release cadence, and ownership clearer |
| Repo-local configuration and workflow logic | Tenant-aware governance and registry service | Enables repeatable multi-tenant in-tenant delivery |
| Use-case-specific implementations in the core repo | Domain solution packs | Reduces coupling between shared platform and vertical solutions |
| Operational metrics as implementation detail | Evaluation and observability services | Makes quality, adoption, and ROI visible and governable |
Recommended Transition Phases
Phase 1. Stabilise Contracts Inside The Current Codebase
- Define explicit interfaces for tenant configuration, orchestration, retrieval, tool invocation, and evaluation.
- Push new backend work toward FastAPI-style service boundaries rather than extending Flask-shaped entrypoints.
- Keep the repo together while contracts, CI, and deployment workflows are still moving.
Phase 2. Extract Platform Boundaries
- Split control-plane concerns from runtime execution and asynchronous workers.
- Isolate knowledge ingestion and retrieval so search and document pipelines can evolve independently.
- Create a dedicated evaluation and observability surface rather than embedding those concerns in each solution flow.
Phase 3. Productise Domain Solution Packs
- Move complaint analysis, triage, research, and future vertical accelerators into packaged solution definitions.
- Keep policy, prompts, tools, evaluations, and approvals versioned as platform-managed assets.
- Treat domain packs as onboardable products rather than one-off branches of the core platform.
Phase 4. Split Repositories When Boundaries Are Real
- Split only after service contracts, ownership, and release pipelines are proven inside the current repo.
- Use repository splits to reflect stable delivery teams and deployment boundaries, not to create them artificially.
Suggested Repository Topology
| Target Repository | Responsibility | Initial Sources |
|---|---|---|
neuralops-platform-control-plane | tenants, agents, prompts, policies, solution packs, approvals | configuration, admin, and management flows in the current accelerators |
neuralops-platform-runtime | orchestration, tool gateway, async workers, realtime execution | orchestrators, Azure Functions patterns, runtime helpers |
neuralops-platform-knowledge | ingestion, curation, retrieval, indexing | search, storage, document processing, retrieval logic |
neuralops-platform-ops | evaluation, telemetry, adoption, cost, and value reporting | test harnesses, observability hooks, operational dashboards |
neuralops-solution-packs | domain-specific packaged solutions | complaint analysis, triage, and future domain accelerators |
Practical Guidance
- Do not split the repos before the platform API, runtime, and knowledge contracts are explicit.
- Prefer internal modularisation first, then repository separation.
- Keep Bicep, deployment baselines, and tenant onboarding assets aligned to the target platform planes.
- Use the future-state C4 model as the decision frame for what belongs in the shared platform versus what belongs in a domain pack.