AI solutions and deployments

AI Solutions is the governed catalogue for copilots, agents, automations, workflows, platforms, and service assets used in an operating model. It separates the reusable asset from the client- and scenario-specific deployment.

Use it to answer four questions clearly:

• What does this solution do, and who builds or provides it?
• Which exact version is being proposed?
• What work does that version support, and what controls does it require?
• Where is it deployed in this scenario, at what effort, cost, risk, and confidence?

Availability depends on your organisation's plan, permissions, and current rollout access.

Understand the Live and scenario context

AI Solutions separates reusable specification from contextual deployment:

Editing a draft version affects the shared tenant record. Publishing locks it for every context. By contrast, changing a scenario deployment does not change Live or another scenario. A clone is a starting copy rather than a continuing sync; later source changes do not flow into it automatically.

Snapshots retain deployments as read-only. Promoting a scenario carries its contextual deployments, control decisions, and forecasts into the new Live baseline while the stable solution and versions remain shared.

Create a solution

1. Open Solutions from the main navigation.
2. Select New solution.
3. Name the reusable asset and choose its type.
4. Record the provider and build owner where known.
5. Describe the asset without pasting credentials, tokens, passwords, private keys, or client secrets.

The solution is shared across Live and scenarios. Client-specific scope belongs to a deployment, not the shared description.

Use the information icon beside any field when its meaning is unclear. The guidance distinguishes the shared solution, its immutable version specification, and each contextual deployment so information is recorded at the correct level. Ordered choices such as autonomy and risk use compact selectors where practical.

Required, optional, and Advanced fields

Orgonaut marks each field as Required, Optional, or conditionally required. Required fields also have a red asterisk. Less frequently needed detail is grouped under Advanced, which opens automatically if one of its fields has an error.

• Solution identity: name, type, and lifecycle are required. Provider, build owner, and description are optional under Advanced.
• Version: version label, purpose, deployment model, default autonomy, and default risk tier are required. Release date, superseded version, review summary, and description or release notes are optional under Advanced.
• Work claim row: claim and scope are required. The Work category hint is optional under Advanced; evidence or limits is optional.
• Control row: key, type, title, description, and mandatory choice are required. Verification method is optional under Advanced.
• Pricing default row: key, type, label, rate, currency, and rate unit are required. Source and basis and the conditionally required zero-cost rationale are under Advanced. A zero-cost rationale becomes required when the rate is zero.
• Deployment: exact version, deployment name, scope and intended use, autonomy, risk, evidence confidence, and cost completeness are required. Organisation scope and accountable human are optional. Agent actor, implementation effort, lead time, effective dates, and rationale are optional under Advanced.
• Deployment controls and costs: control status, forecast rate, currency, and period are required for their existing rows. Owner, due date, quantity, and rationale are optional unless the selected status or an override makes the rationale mandatory.

Define and publish a version

Open the solution and select Versions → New. A version records:

• its purpose and deployment model
• default autonomy and risk tier
• review and assurance expectations
• supported and unsupported Work claims
• mandatory controls and verification methods
• pricing defaults, when you have cost permission

Draft versions can be edited. Review every tab before selecting Publish and lock. Publication makes the specification and its child records immutable so a proposal continues to refer to the exact content that was reviewed.

Create a successor version when the purpose, claims, controls, or pricing changes. Retired versions remain in history but cannot be selected for new deployments. A superseded version remains selectable only as an acknowledged exception.

Record Work claims

Work claims describe what one exact version supports, does not support, or still requires validation for. A Work category hint lets Orgonaut surface relevant deployed solutions on Capability detail.

A category match is a candidate relationship, not proof of an outcome. Use a Capability measure and governed evidence to substantiate the result.

Define controls

Controls cover requirements such as human review, data access, security, privacy, monitoring, recovery, audit, and evaluation. Mark a control mandatory when the deployment cannot safely operate without it.

Every new deployment receives its own copy of the selected version's controls. Resolve mandatory controls before moving the deployment to Active. Blocked and not-applicable decisions require a rationale so the governance trail remains explicit.

Add pricing defaults

Users with cost permission can record one-off, recurring, or usage-based rate defaults. Include the currency, rate unit, confidence, and source basis. A zero rate requires a reason.

These values seed a deployment forecast; they are not an invoice, budget, or actual usage record. Client-specific overrides require an approved rationale, and a variable rate without expected quantity remains visibly incomplete.

Deploy a solution in Live or a scenario

Open Deployments while viewing the intended context, then select New. Choose an exact published version and record:

• the organisation scope
• an optional agent or robot actor already configured in the same context
• the accountable human position
• autonomy and risk
• implementation effort and lead time
• effective dates
• cost completeness, evidence confidence, and rationale

Deployments belong only to the active Live or scenario context. Editing one scenario does not change the deployment in another. The reusable solution and published versions remain shared inside the tenant.

Status changes follow the controlled lifecycle from proposed through approval, implementation, pilot, active, pause, or retirement. A deployment cannot become active with prohibited risk or unresolved mandatory controls. Accountability must remain with a human or vacant human position.

Confidentiality and access

Solution records reject common credential and private-key patterns. Store credentials in the approved secret-management system, never in Orgonaut description or rationale fields.

Pricing and forecasts are omitted when the viewer lacks the separate cost permission. Read-only roles can review the catalogue but do not see mutation controls. Snapshots and archived scenarios preserve deployments as read-only records.

Deploy solutions across agency clients

Keep each client's solutions and deployments in that client's tenant. Consultants may have access to several client tenants, but an agency tenant does not automatically publish a solution into them, and scenario cloning never crosses a tenant boundary.

There is currently no agency-wide package library, cross-tenant deployment, or live update channel. To reuse an agency-developed solution today, create the solution and governed version separately in each authorised client tenant, then add a client-specific deployment, controls, pricing basis, and accountable owner there. Reuse only generic, approved material; do not carry confidential scopes, costs, evidence, credentials, or client data between tenants.

This deliberate separation means one client can approve version 1.0 while another uses a differently governed specification without either record changing behind the other client's proposal.

Archive a solution

Archiving blocks new versions and deployments while retaining version and deployment history. Restore the solution before changing its shared record or creating another deployment.

Read solutions through API, Astro, MCP, or CLI

Use GET /api/v1/ai-solutions and GET /api/v1/ai-solutions/{slug} for governed read access. Add scenario=<slug> to select contextual deployments; omit it for Live. List responses support page, per_page, include, and fields[solutions].

Pricing defaults and deployment forecasts are omitted unless the caller has transformation-cases.costs.read; the response explicitly reports whether costs were redacted. Astro and MCP use the stable read capability ID read.ai-solution.deployments. The CLI commands are orgonaut solution list and orgonaut solution show <slug>, and they preserve the active Live or scenario context.

Troubleshooting

• Solutions is not in the navigation: confirm the plan entitlement, rollout access, and ai-solutions.read permission.
• A deployment cannot be created: publish a non-prohibited version first.
• An agent is missing: the agent or robot and its profile must already exist in the same Live/scenario context.
• A status change is rejected: assign an accountable human position and resolve every mandatory control required by the target status.
• A cost override is rejected: record the client-approved basis, and add a rationale for any explicit zero rate.
• Fields are disabled: the version may already be published, the solution may be archived, or the current scenario/snapshot may be read-only.

Related guides: Transformation Cases, Business capabilities, Work catalog, and Create a scenario.