By the third ML feature in production, informal ownership fails. The same company ends up with three ingestion patterns, two model registries, and no named incident owner for inference failures. The sequence is predictable, since one team ships recommendations, a second ships retrieval-augmented generation, and a third ships churn prediction on a separate Airflow deployment.
Across more than 35 software and ML engagements, we have seen the same fault line. Product-facing model teams rebuild shared infrastructure because no team owns the platform contract, and the cost shows up in delivery, reliability, and accountability. Releases take longer, incidents move across Slack channels, and no one knows who approved the model serving customers.
CTOs need a formal split before the fourth production AI system. Platform teams own shared data paths, tracking, deployment, monitoring, access control, and security patterns. Domain model teams own model behavior, feature quality, product metrics, and release decisions, and they own model failures after deployment. This division gives engineering leaders an operating model that defines who builds shared machinery, who approves behavior, and who responds when production fails. It is the same MLOps discipline that keeps deployment repeatable once several teams depend on the same path.
The ownership problem starts with the second repeat
A single ML feature survives with local decisions. One team builds a batch ingestion job in Airflow, stores artifacts in S3, tracks runs in MLflow, and deploys inference behind FastAPI. That design breaks down when two more teams repeat the pattern with different choices, so one uses Dagster, another uses Prefect, and a third stores labels in PostgreSQL. Experiment tracking then splits across MLflow, Weights & Biases, and local notebooks, metric names drift, artifact paths differ, and model approval depends on the lead engineer.
Click to expand The organization now carries duplicated infrastructure and duplicated judgment across data, deployment, monitoring, access control, and incident response. The first cost is pipeline rework, since teams rebuild ingestion from Salesforce, Segment, Stripe, Snowflake, Zendesk, and product event streams. The second cost is weak model comparison, because accuracy, recall, latency, calibration, drift, and business lift use different definitions across teams. The third cost is slow deployment, where each team writes its own CI/CD pipeline, model packaging path, container base image, rollback plan, and production approval process. The fourth cost is unclear incident routing, so a latency spike in real-time inference sits between product engineering, data engineering, MLOps, and the model team for hours.
This problem becomes expensive because senior ML infrastructure talent is scarce, and hiring more of it does not fix unclear boundaries. Senior MLOps time belongs on platform primitives used by three or more teams. The operating rule is direct, since shared machinery belongs to the platform team and user-facing model behavior belongs to the domain model team. A senior ML infrastructure engineer should design one deployment path for five teams instead of repairing five incompatible paths, and that work includes versioning, artifact signing, release states, traces, runbooks, and rollback mechanics. Product-specific model behavior stays with the team closest to the customer workflow.
The durable boundary separates machinery from behavior
The durable split runs between platform ownership and model ownership. Platform ownership covers the systems that make ML repeatable, and model ownership covers the behavior of AI features in production, including labels, features, evaluation, thresholds, product risk, release notes, and rollback criteria.
Click to expand A CTO should treat this split as an operating decision, because it affects budget, hiring, architecture review, incident routing, and release gates. The distinction also changes technical debate, so a team should not decide between BentoML, KServe, SageMaker, or a custom FastAPI service inside a product roadmap meeting. That decision belongs to the platform operating model, while the model team decides whether the fraud model improves approval quality within the agreed manual-review threshold.
The same principle applies to RAG systems. The platform team owns prompt versioning, vector index deployment, tracing, retrieval latency, and answer logging patterns. The model team owns grounding quality, answer refusal rules, evaluation sets, human review, and domain acceptance, and the product manager owns the customer workflow the system supports. This separation prevents two recurring failures, since infrastructure decisions stop hiding inside feature tickets and model behavior decisions stay with engineers and scientists who understand the domain.
The boundary must be visible in tickets, repositories, dashboards, and on-call routes, because an ownership rule written in a slide deck will not survive a production incident. A clear boundary also reduces architecture churn, so teams can debate product risk without reopening the serving architecture for every model release.
Platform teams own shared primitives
The AI platform team owns the tools and contracts every model team uses. This includes ingestion patterns, feature stores, experiment tracking, model registry, deployment templates, observability, access control, and cost reporting. A production stack can use Kafka or Kinesis for events and dbt for transformations, Snowflake or BigQuery for warehouse storage, and Feast for feature serving. The same stack can use MLflow for registry, Kubernetes for serving, Terraform for infrastructure as code, and Prometheus with Grafana for monitoring, while OpenTelemetry carries trace fields for inference calls, feature lookup latency, model version, and downstream service time.
The tools need a written contract. A model team should know how to register a dataset, start an experiment, deploy a model, roll back a version, and read production metrics, and the platform team owns that golden path. A real-time inference service should inherit a standard container base image, health check, autoscaling policy, logging format, resource limit, and rollback process. The platform team also owns exceptions, so if one team needs GPU serving on Triton and another needs CPU inference on KServe, platform decides how many paths the company will operate.
A strong platform contract includes named service levels, such as p95 platform overhead under 300 milliseconds, rollback under 10 minutes, and dashboard availability above 99.9%. Those targets force architectural discipline, since the rollback target fails under five deployment tools and custom release scripts in every repository. The platform team should publish reference repositories so a new team can clone a working service, connect a model artifact, and inherit logging, tracing, health checks, and release states. That reference path should include security defaults, so secrets come from Vault, AWS Secrets Manager, or Google Secret Manager, not environment variables copied into deployment files. Access control follows the same rule, where model teams request access through named groups and platform maintains IAM patterns for training data, artifacts, registries, and runtime services.
Cost reporting belongs in the platform layer as well. GPU hours, embedding calls, vector database storage, and inference requests need consistent tags by product, team, environment, and model version. Without those tags, finance receives a cloud bill that no engineering leader can explain, but with them a CTO can see which product uses the most inference spend and which release changed cost.
Domain model teams own product behavior
Domain model teams own the model, the feature, and the outcome. They define labels, choose features, train models, build evaluation sets, review outputs, and approve release readiness, and their accountability is measured in product terms. A fraud model owns false positives, false negatives, review load, approval latency, and customer loss. A search ranking system owns click-through rate, zero-result rate, latency, and revenue per session, while a support RAG system owns resolution rate, escalation rate, answer citation quality, and unsafe response rate.
This accountability stays with the model team after deployment. The platform team provides monitoring tools and alert routes, while the model team interprets drift, bias, quality degradation, and user impact, and decides whether to retrain, roll back, raise thresholds, or pause serving. The model team also owns the release narrative that explains why version 18 should replace version 17. That narrative must name improved segments, regressed segments, data changes, evaluation limits, and rollback thresholds, since a one-line “model improved by 4%” release note is inadequate.
The model team should also own human review design. In fraud, that means review queues, escalation thresholds, and acceptable false-positive rates by customer segment. In support automation, it means refusal rules, source citation requirements, and escalation paths for account-specific policy questions, and those choices shape the customer experience. Domain ownership also includes feature leakage review, where the team that understands the business process confirms that training features would exist at prediction time. A platform check can detect missing timestamps and offline-online mismatches, but it cannot decide whether a renewal downgrade label represents churn for a customer success workflow.
The AI ownership matrix
A written ownership matrix prevents ambiguity. It should be reviewed during technical planning, architecture decision records, and production readiness reviews, and it belongs in the engineering handbook where teams reach for it when assigning tickets, approving pull requests, and handling incidents. The same boundary logic applies to data platforms, which we cover in data platform ownership when revenue has three names.
| Area | Platform team owns | Domain model team owns | Shared review point |
|---|---|---|---|
| Data ingestion | Standard connectors, schema registry, retry patterns, lineage | Source selection, domain joins, label definitions | Data contract approval |
| Feature engineering | Feature store, offline-online consistency checks, access control | Feature definitions, leakage review, feature importance analysis | Feature readiness review |
| Experiment tracking | MLflow or Weights & Biases setup, naming rules, artifact storage | Experiment design, baselines, metric selection | Model review board |
| Model registry | Versioning, approval states, artifact signing | Candidate promotion request, model card, evaluation package | Release approval |
| Deployment | CI/CD templates, container base images, canary release, rollback | Serving logic, thresholds, response schema, model version choice | Production readiness checklist |
| Monitoring | Metrics pipeline, dashboards, alert routing, OpenTelemetry standards | Drift interpretation, quality thresholds, retraining decisions | Weekly production review |
| Security | Secrets management, IAM, encryption, audit logs | Data classification, access requests, privacy review | Security approval |
| Incident response | Platform runbooks for infrastructure failures | Model runbooks for prediction quality failures | Joint incident review |
The test for ownership is direct. If the work benefits three or more model teams, platform owns the primitive, and if the work changes user-facing model behavior, the domain team owns the decision. If both conditions apply, platform owns the mechanism and the domain team owns the release choice.
Click to expand The matrix also clarifies budget. A shared Feast deployment, registry workflow, or OpenTelemetry schema should be funded through the platform roadmap, while a new fraud threshold, ranking objective, or evaluation dataset should be funded through the product roadmap. This split prevents platform work from hiding inside product feature estimates, and it changes planning quality, since product teams stop padding every ML release with infrastructure unknowns and platform leaders receive a visible backlog for shared services.
The matrix should also define final decision rights. The CTO or VP Engineering should approve the first version, then delegate ownership to platform and domain leaders. Without named decision rights, architecture review becomes negotiation by meeting attendance, the loudest team wins the standard, and the company pays for the variation later.
Four failure modes caused by blurred ownership
Click to expand Duplicated pipelines create permanent maintenance cost
A fintech company with six ML features found 19 ingestion jobs reading customer, transaction, and device data from the same warehouse tables, and four jobs applied different filters for closed accounts. The immediate cost was delivery delay, and the long-term cost was trust loss because dashboards, training sets, and production features disagreed. The company also created audit exposure, since two teams produced different customer eligibility decisions from the same source system during a compliance review.
The fix required a focused data platform intervention. The platform team created Git-based data contracts, dbt naming rules, CI schema checks, and a lineage view for training sources, and domain teams then requested datasets through a defined interface. They documented label logic, exclusion rules, and feature leakage checks in the same repository as their model code. The before-and-after difference was visible in release planning, because a new credit risk model stopped carrying a three-week estimate for data ingestion. That work moved to a platform-owned connector and a reviewed data contract, so the domain team spent its time on label quality, segment performance, and approval thresholds.
The company also changed its review process. A pull request that changed a training source required approval from the data owner and the model owner, and that control caught a deleted account-status field before it reached production training. The same change previously would have produced a silent drift event.
Inconsistent metrics make model comparison unreliable
Model teams often report different metric sets, where one uses offline AUC, another uses precision at K, and a third reports prompt acceptance rate. This prevents executive review and weakens monitoring, because baseline behavior lacks a shared definition. A VP of Product cannot compare three AI investments when every team uses different evidence, so one release note reports lift, another reports latency, and another reports qualitative acceptance examples.
Platform teams should own the metric collection layer and dashboard templates, and domain teams should own which metrics matter for the product and which thresholds trigger action. A standard template should include offline evaluation, online product metrics, latency, cost per prediction, error rate, and segment-level failures, and the domain team then selects release and rollback thresholds. For a support RAG release, that means reporting containment rate, citation coverage, answer rejection rate, escalation rate, median answer latency, and unsafe response findings from the evaluation set. The same dashboard should carry platform measurements, so retrieval latency, embedding cost, vector index version, prompt version, and model endpoint errors sit beside product quality.
This makes review concrete, moving the executive conversation from general AI progress to release risk, customer impact, and operating cost. Metric standardization also improves post-release learning, since every release records the same baseline fields and teams can compare production behavior across quarters. The same pattern helps finance, because cost per prediction, cost per successful resolution, and cost per accepted recommendation give executives a common language for investment decisions.
Slow deployments come from repeated release engineering
ML release work includes packaging artifacts, validating dependencies, checking feature availability, running smoke tests, setting resource limits, and defining rollback rules, and asking each team to rebuild this path adds weeks to production delivery. The release path also changes by serving pattern, so batch scoring needs scheduling, idempotency, output validation, and backfill rules, real-time inference needs autoscaling, latency budgets, circuit breakers, and request tracing, and streaming inference needs replay strategy, late-event handling, and offset management. RAG systems add another release surface, where teams must version prompts, embedding models, chunking rules, retrieval indexes, rerankers, grounding checks, and answer evaluation sets.
The platform team should provide standard deployment paths for batch scoring, real-time inference, embeddings, rerankers, and RAG pipelines, and each path needs a template, approval flow, dashboard, and rollback mechanism. Domain teams should focus on release risk and decide whether a candidate model is safe for 5% traffic, 25% traffic, or full rollout. A practical canary policy has three layers, where the platform layer checks error rate, latency, resource use, and dependency health, the model layer checks product quality, segment regression, unsafe outputs, and threshold breaches, and the business layer checks revenue impact, customer complaints, manual review load, and support volume. This split makes rollback faster, since platform can roll back an unhealthy service and the model team can roll back a poor prediction policy.
Release engineering also affects compliance. A regulated lender needs proof that the model artifact, feature set, and approval record match the production decision, so a platform-owned release path can attach artifact hashes, model cards, approval states, and audit timestamps to each deployment. Product teams then supply the behavior evidence.
Unclear incident ownership extends production failures
A recommendation service fails through infrastructure latency, stale features, poor calibration, upstream data delay, or product inventory changes, and each failure mode needs a named owner. Incident response runbooks should separate platform failures from model quality failures, so Kubernetes pod restarts, registry outages, and feature store latency belong to platform, ranking degradation, retrieval failure, hallucination patterns, and label drift belong to the model team, and upstream product data gaps belong to the data owner named in the dependency register.
The first 15 minutes of an incident matter, since the on-call engineer should know whether to page platform reliability, the data platform owner, or the model owner. A dependency register should include the model endpoint, feature tables, prompt templates, vector indexes, upstream APIs, dashboards, and alert routes, with one named owner per dependency, and it should also include the rollback action, because “page ML team” is not a rollback plan. A usable entry says which model version to restore, which feature table to freeze, which index to revert, and which dashboard confirms recovery, and it names the person accountable for customer communication.
The incident review should preserve the ownership split, where platform documents infrastructure failures and the model team documents behavior failures. Both teams should agree on detection gaps, so a missed alert belongs in the platform backlog if the metric was unavailable and in the model backlog if the threshold was undefined. A mature runbook also names customer controls. For a support assistant, that means pausing automated answers, forcing human review, or disabling one document collection, and for fraud scoring, it means raising review thresholds, routing high-risk transactions to manual review, or reverting to the previous model version, each with a named approver.
How to staff the first MLOps engineering team
The first AI platform team should be small and senior. A common starting shape is five people, one platform lead, two ML infrastructure engineers, one data platform engineer, and one production reliability engineer, and it should serve three to eight domain model teams. Below three teams, shared platform investment often arrives before the organization has enough repeated work, and above eight teams the platform group needs product management support and service tiers, because it faces intake pressure from too many product groups.
The platform lead owns the roadmap, standards, and negotiation with domain engineering leaders, and this role requires production judgment across releases, incidents, vendor choices, and budget tradeoffs. The two ML infrastructure engineers build registry, deployment, evaluation, and serving patterns, and they should understand Python packaging, container images, model artifact formats, GPU constraints, and inference runtimes. The data platform engineer owns ingestion contracts, feature store integration, offline-online consistency, and lineage, working across dbt, Snowflake, BigQuery, Spark, Kafka, and Feast. The reliability engineer owns observability, SLOs, incident runbooks, capacity planning, and Kubernetes reliability, and this role prevents the platform from becoming a pile of scripts.
The first charter should include six services:
- Standard model registry and artifact storage
- Shared experiment tracking and model metadata
- Reusable deployment templates for batch and real-time inference
- Data quality monitoring and lineage for training and serving data
- Production observability for latency, cost, errors, drift, and quality
- Incident response runbooks and ownership maps
The charter should exclude broad AI research, because the platform team builds production paths for existing and planned model teams. The platform team should publish service-level targets that real-time inference templates must meet, and those targets expose fragmented engineering choices quickly. A team cannot meet the rollback target if every model service uses a different deployment path, and it cannot monitor quality if model versions and feature versions are missing from traces, so trace fields must include request ID, model version, feature version, prompt version, and tenant or segment.
Domain model teams should be staffed separately. A mature team includes one ML engineer, one backend engineer, one data scientist or applied scientist, one product manager, and shared analytics support. The ML engineer owns training and serving integration, the backend engineer connects the model to the product surface, the data scientist owns evaluation, experimentation, and model behavior, and the product manager owns the customer workflow and commercial threshold for release. This separation keeps platform engineers out of product approval debates and keeps model teams from inventing deployment patterns under delivery pressure. Staffing design should include on-call responsibility, where platform owns the service health rotation and the domain team owns model quality escalation for its feature. The model quality rotation does not need to mirror infrastructure on-call, since it needs named coverage during releases, material data changes, and high-risk business periods.
A 90-day plan to separate ownership without stopping delivery
Organizations with AI features already in production need a staged move, because a full reorganization before testing the operating model creates delay. The first 90 days should produce named owners, one standard path, and enforceable release gates, with the goal of operational control while product delivery continues. This work should run through engineering leadership, not a temporary working group, so the CTO or VP Engineering sponsors the plan and reviews progress weekly. The plan should also protect active releases, where teams migrate the highest-friction path while keeping current customer commitments visible.
Click to expand Days 1-30 inventory the production surface
List every model, prompt chain, embedding pipeline, vector index, batch scoring job, feature pipeline, dashboard, and deployment path, and include owner, data source, runtime, monitoring, rollback plan, and incident route. The output should be a single AI dependency register, where each row needs one platform owner and one model owner. Within 30 days, every production AI system should have named owners, and that standard applies even when architecture still contains duplicate components. The register should include pilots that influence customers or internal operations, since a prompt chain used by 200 support agents creates the same risk as a public model endpoint.
A good register uses plain fields such as system name, business owner, model owner, platform owner, data sources, serving path, model version, prompt version, index version, dashboard, alert route, and rollback action. Do not wait for perfect metadata, because missing fields are findings that belong in the platform backlog. The inventory should include cost fields, adding cloud account, GPU use, vector database spend, embedding provider, and average request volume, and it should include data sensitivity, marking regulated data, customer content, employee data, and third-party licensed content. Security teams need this view before approving new AI releases, since a model that stores customer transcripts in prompts has a different review path than a churn model trained on aggregated usage events.
Days 31-60 standardize the highest-friction path
Choose the path causing the most delay, which for many teams is deployment, for data-heavy teams is ingestion and feature reuse, and for RAG-heavy teams is prompt, index, and retrieval release management. Build one standard path and migrate two teams onto it, and avoid designing for every future scenario during this period. Create a single MLflow registry, one Kubernetes deployment template, one Grafana dashboard, and one rollback process, then require all new real-time model services to use that path. The migration should include production evidence, so track deployment lead time, failed release rate, rollback time, and on-call escalations before and after the move.
Two migrations are enough to test the contract, because one migration proves the path works and the second shows whether another team can use it without platform engineers rewriting the design. That second use is where the platform contract becomes real. A strong migration ends with deleted variation, so retire the old template, remove the duplicate dashboard, and archive the unsupported deployment script. The migration should also produce a reference runbook that names the deployment steps, approval states, dashboard links, alert routes, and rollback command, which reduces interpretation during incidents so engineers follow a known path instead of reconstructing release history from Slack messages.
Days 61-90 move from agreement to enforcement
Ownership gains value when it changes daily work, so pull request templates, architecture decision records, production readiness checklists, and incident runbooks must reflect the split. Create two gates, where the platform readiness gate checks repeatability, security, observability, dependency ownership, and deployment safety, and the model readiness gate checks evaluation data, failure modes, product metrics, fairness review where needed, rollback thresholds, and the release narrative. After 90 days, no new ML system should enter production without both gates completed, and this rule should apply to batch models, real-time models, RAG systems, and internal agent workflows.
The gates should live in the release process, because a checklist in Confluence fails if CI, repository templates, and approval workflows ignore it. Put the gate in GitHub pull requests, registry approval states, Terraform modules, and deployment workflows, since the operating model must appear where engineers ship. The first enforcement cycle will surface exceptions, and each exception should become a decision record with an owner, expiration date, and replacement plan. Exceptions should be rare and visible, so a team that cannot use the standard path documents the reason, cost, risk, and migration date. Leadership should review exceptions weekly during the first enforcement period, since aging exceptions show capacity gaps, missing platform features, or product teams bypassing standards.
Governance should be light and explicit
Governance fails when it becomes a committee without code ownership, so the stronger pattern is written standards, automated checks, and named decision rights. The platform team owns standards for data contracts, deployment templates, experiment metadata, model registry states, and observability fields, and these standards should be enforced through repositories, CI checks, and infrastructure modules. This mirrors the continuous delivery automation that separates model pipelines from the CI/CD machinery around them.
Click to expand Domain teams own model cards, evaluation reports, product metric definitions, and release notes, and these artifacts should be short enough to maintain during normal delivery. A model card for a production system should include training window, data sources, excluded segments, evaluation metrics, known failure modes, monitoring thresholds, and rollback criteria, and a two-page document is enough for most product models. Architecture decision records should capture hard-to-reverse choices such as choosing KServe over BentoML, using Feast for feature serving, adopting OpenTelemetry trace fields for inference, or storing embeddings in pgvector, Pinecone, Weaviate, or OpenSearch, and each record should name cost, latency, operational burden, backup plan, and exit path.
Decision rights need the same clarity, where platform owns the standard deployment path, the domain team owns the release decision within that path, and security owns exceptions for regulated data, audit retention, encryption, and access review. This model keeps governance close to code, so standards become pull request checks, Terraform modules, registry states, dashboards, and runbooks. The governance meeting should review exceptions, incidents, and platform adoption, not approve every model release.
A monthly review can track four metrics, platform path adoption, release lead time, incident count by owner, and exception age, and those metrics reveal whether ownership is working. If exception age grows, the platform team lacks capacity or the standard path misses a common use case, if model incidents repeat, domain teams need stronger evaluation sets or clearer rollback thresholds, and if release lead time stays flat, the gate is paperwork instead of engineering control. The meeting should have a fixed agenda and named owners, reviewing aged exceptions, recent incidents, upcoming high-risk releases, and platform adoption by team, and it should produce decisions, not commentary, with each decision naming the owner, due date, repository or system affected, and expected operational change.
Two before-and-after examples
A subscription software company had three churn models in production, where sales operations, customer success, and growth each trained separate models against the same account and product usage tables. The teams used different label windows, so one defined churn as contract cancellation, another used 60 days without login, and the third used renewal downgrade. Each model appeared correct inside its own dashboard, yet account teams received three conflicting risk scores for the same customer.
The platform intervention started with a shared data contract and a feature lineage view, while the domain decision started with a single label review led by product and revenue operations. After six weeks, the company retained two models because they served different workflows, and the shared platform path removed duplicate ingestion jobs and made the label difference explicit. The final design gave customer success a renewal-risk model and growth a reactivation model, while sales operations stopped publishing a separate score from a separate pipeline. That change reduced account-team confusion during weekly pipeline reviews and gave finance one definition for retention risk in board reporting.
A second example came from an internal support assistant. The first release used a vector index owned by the application team, prompts stored in the web repository, and no trace link between answer, prompt, retrieved document, and model version. When answer quality degraded after a policy update, the team could not identify the failing dependency, so support managers saw agent complaints while engineering saw normal endpoint latency. The platform team then moved prompt versions, index versions, retrieval traces, and model endpoint metrics into one release path, and the support model team owned answer evaluation and refusal rules.
The next policy update produced a different response, since the team traced failing answers to one document category, rolled back the index, and kept the model endpoint unchanged. That is the practical value of the ownership split, because infrastructure rollback and model quality review proceed on separate tracks with named owners. The assistant example also changed the release meeting, where the platform lead reviewed trace completeness and rollback readiness and the support owner reviewed answer quality, and the meeting ended with two approval records, one for the release mechanism and one for the behavior decision.
Click to expand What CTOs should do next
Create an AI ownership register this month. List every production and pilot AI system, then assign one platform owner and one model owner to each line, and use the ownership matrix above as the first version of the operating model. Select one shared path, often deployment or ingestion, and move two product-facing model teams onto it within 60 days.
Click to expand Stop asking every AI product team to rebuild ingestion, tracking, deployment, and monitoring, and fund a small senior platform team to own the repeatable machinery. Hold domain model teams accountable for production model outcomes, and require a release narrative, evaluation package, rollback threshold, and named owner for every model version. The operating model will expose gaps, since some systems will have no rollback path, some dashboards will measure technical health while missing product quality, and some teams will discover that no one owns the model after deployment. Those findings are the CTO’s backlog, and they should drive platform investment, team design, release governance, and incident review.
Make the separation now. Name owners, standardize the shared path, enforce the gates, and stop shipping AI systems with invisible accountability. Algorithmic builds AI systems and the platform paths behind them so shared machinery and model behavior have named owners from the first release. Start a conversation if your third AI feature is heading to production without a clear ownership split.
