--- title: "Ownership and approvals for routing decisions" description: "Routing decision ownership assigns responsibility across seven actions and ten lifecycle events from proposal through stop." lang: en status: public-preview lastUpdated: 2026-09-04 url: https://duale.ai/en/docs/model-routing/ownership-and-approvals --- ## AI-generated summary Assign responsibility for each routing decision across seven actions and ten lifecycle decisions, from proposal through retirement. - Seven actions cover a routing decision from proposal through stop, each with a named owner. - Ten decisions assign four responsibilities each, from approving a business use to retiring a route. - Duale AI permissions authorize configuration and audit actions but do not implement customer approval workflows. - Default roles do not enforce the requester, approver, executor, and verifier split across actions. - A configuration hash is not a signature, approval, applied-state proof, or complete history. Summaries were generated by AI. Generative AI is experimental. --- Assign responsibility to each routing decision. Do not create separate operating processes for developers, platform operators, security, and audit. They act at different points in one shared change and service lifecycle. [Control model changes](https://duale.ai/en/docs/model-routing/control-model-changes.md) defines the lifecycle that these responsibilities govern. Duale AI permissions authorize configuration, analytics, and audit actions. They do not implement the customer's change approval workflow. Record proposals, approvals, review dates, and exceptions in the customer's change system. ## Define the actions Seven actions cover a routing decision from proposal through stop. Name the person or group responsible for each action: Use explicit action names instead of a general statement that teams must collaborate: - **Propose:** describe the change, scope, reason, expected value, and risks. - **Own the business outcome:** define acceptance, human review, failure behavior, and customer impact. - **Approve a control boundary:** accept the provider, data, security, legal, financial, or operational conditions. - **Apply:** make the authorized application or platform change. - **Verify:** check the current resolved configuration, available runtime evidence, and customer-visible outcome independently of the change action where required. Do not claim proof that a change reached every task when no such signal exists. - **Be informed:** receive enough notice to operate, support, audit, or communicate the change. - **Stop:** use the correct control for the affected scope. The application can stop new work. An authorized operator can disable a route for later selections. The provider or network owner can revoke access. The submitting agent can ask an active task to stop. One person can perform several actions for a low-risk environment. Separate the requester, approver, and executor for a material change. Duale AI permissions do not enforce that separation. ## Assign each decision Ten decisions carry a routing change from proposal to retirement. The table assigns four responsibilities to each one; one person can hold several in a low-risk environment. The job titles are customer-defined recommendations. Product authorization uses actions, not these titles. | Decision or event | Proposes and owns the outcome | Approves the boundary | Applies | Verifies and stops | | ---------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Approve a business use | Business-process owner | Required security, privacy, legal, compliance, and risk owners | Application owner | Outcome owner verifies acceptance; application admission stops new work | | Contract with a provider or account | Architecture, account, or procurement owner | Data, security, privacy, legal, commercial, and quota owners | Customer account owner and model provider | Operations verifies service; provider or network owner can revoke access | | Store a credential and configure a route | Configuration change owner and workload owners | Business, application, data, security, and operations owners | User with the required configuration action | Independent verifier checks resolved state and outcome; incident authority can disable or revoke | | Change an application routing policy | Application owner | Business-process owner and affected control owners | Developer or release owner | Application tests and outcome monitoring; release owner rolls back | | Change tools or their permissions | Application and business-process owners | Access, security, data, and business owners | Tool developer, tool host owner, or release owner | Side-effect and replay tests; application admission or tool fencing stops the cohort | | Enable or disable a tenant route | Business-process, application, and configuration owners | Owners of each affected functional and control boundary | User with `config:update_config` | Customer outcome evidence; stable-tenant switch, route disable, or provider cutoff | | Change a managed preset | Preset owner proposes; affected customer workload owners own the customer result | Owners of each affected functional and control boundary | Preset owner publishes the change; an authorized config user can detach fields or disable | Customer re-evaluates the resolved route and can disable it or switch new roots | | Move a rolling provider alias | Provider makes the change; affected workload owners own the customer result | Owners of each affected functional and control boundary | Provider moves the alias; an authorized config user can replace or disable the tenant route | Customer re-evaluates provider behavior and can disable the route or revoke provider access | | Change a tenant or deployment boundary | Architecture and data owners | Security, privacy, legal, recovery, and commitment owners | Supported deployment operator provisions it; authorized users configure it | Independent boundary evidence; application admission or deployment incident controls stop work | | Retire a route or credential | Platform-service and dependency owners | Workload, evidence-retention, and replacement owners | Configuration, provider-account, and secret owners | Dependency check, resolved-state check, notice, and approved emergency recovery | Independent audit or assurance can raise a finding, test evidence, and request a management action plan. For an independent review, it does not accept business risk, approve the change scope, apply or roll back configuration, or operate the service. Security, privacy, legal, and compliance owners decide within their mandates. The business-process owner remains accountable for functional acceptance. ## Map product access to the actions Configuration read, create, update, and delete use separate actions: `config:read_config`, `config:create_config`, `config:update_config`, and `config:delete_config`. Read access can expose the complete provider configuration, including credentials. Grant it as secret-bearing access. Audit query, export, and proof use separate tenant-scoped actions. Default roles do not enforce the requester, approver, executor, and verifier split, and no default role grants audit export. A custom policy can separate existing configuration and audit actions, but it cannot add workflow states. Keep approvals in the customer change system. ## Use lifecycle gates A meeting is not the control. The recorded decision, restricted action, effective-state check, and retained evidence form the control. Require a recorded decision when you: - onboard a provider, region, tenant, or deployment; - approve a workload against the documented intended purpose and excluded uses; - enable a model, change tools, or change their permissions; - change a provider, data, contract, cost, or availability boundary; - accept a failed test or time-bounded exception; - respond to an outage, compromise, output regression, unexpected cost, or suspected data transfer; or - retire a route, credential, tenant, or deployment. Record the following information in the customer-held record: - secret-redacted old and new effective configuration, approved scope, and business purpose; - evidence, thresholds, requester, outcome owner, approvers, executor, verifier, and stop authority; - effective time, review or expiry date, and affected workloads; - enablement, rollback, cutoff, and verification actions; and - exceptions, residual risk, and required notice. Product configuration metadata and audit events can support verification, but a configuration hash is not a signature, immutable revision, approval, applied-state proof, or complete history. Audit event delivery does not replace the customer record. ## Keep communication proportional Do not require a meeting for each route choice. Communicate when a change affects an approved boundary, eligible pool, material business behavior, operating procedure, or customer commitment. Application teams need notice of pool changes that can affect acceptance, latency, cost, or errors. Platform teams need application deadlines, critical workflows, traffic expectations, and safe failure behavior. Security, privacy, legal, and audit functions need the approved scope, data flows, evidence, exceptions, and change history without broad access to customer prompts by default. For each material change or incident, name the sender, trigger, recipient, channel, time requirement, and retained proof. Do not depend on a meeting or an informal message as the only approval or incident record. [Operate model routing and manage risk](https://duale.ai/en/docs/model-routing/operations-and-risk.md) applies these responsibilities to health reviews, resilience tests, and incidents. ## Related content - [Understand model routing and the stable application contract](https://duale.ai/en/docs/model-routing.md) - [Know what the platform records](https://duale.ai/en/docs/security/evidence-and-audit.md) - [Integrate model routing in an application](https://duale.ai/en/docs/model-routing/application-integration.md) - [Secure your use of the platform](https://duale.ai/en/docs/security.md) - [Provider capability and compatibility](https://duale.ai/en/docs/model-routing/provider-capabilities.md) - [Runtime security and pricing for production agents](https://duale.ai/en/product.md) --- ## Sitemap See the full [Markdown sitemap](https://duale.ai/sitemap.md) for all pages.