Ownership and approvals for routing decisions

Routing decision ownership assigns responsibility across seven actions and ten lifecycle events from proposal through stop.

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 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 applies these responsibilities to health reviews, resilience tests, and incidents.