Transformation Cases

A Transformation Case connects a client decision to Orgonaut's system-of-record data. It compares one pinned baseline with one exact-lineage target scenario, then explains the capability change, delivery design, organisation movement, assumptions, value, investment, evidence, and limitations.

Use a case when a scenario needs to become a reviewable proposition rather than another planning view. The workflow is especially suited to controlled AI-efficiency trials and consultancy proposals.

Availability depends on your organisation's plan and Transformation Case permissions.

The sidebar groups Capabilities and Solutions beneath one violet Transform badge, while Cases uses the same badge in the tenant-level header. The badge marks the connected change-design workflow; it does not change access, permissions, or the active Live or scenario context.

Before you start

Prepare these records first:

a complete Live baseline or immutable baseline snapshot
one planning scenario cloned from that exact baseline
the business capabilities in scope, with target assessments
supporting Work mappings and relevant AI Solution deployments
evidence, measures, and explicit limitations for material claims

Transformation Cases are tenant-level records. They select their own baseline and target and therefore do not change when you browse into a different scenario.

How the four workspaces fit together

A practical sequence is:

Build or import the client's Live baseline.
Describe today's Work and map it to roles and teams.
Define Capabilities once, then assess their current Live state and connect the Work that produces each outcome.
Define governed AI Solutions and, where relevant, record current Live deployments.
Clone a target scenario. Orgonaut copies contextual Work, capability assessments, measures, eligible evidence links, and solution deployments from the selected source.
Redesign the target scenario: change Work, organisation, capability strength, and solution deployments without changing Live.
Create a Transformation Case to pin the comparison and turn it into an evidence-backed decision proposition.

The split is intentional: Work is copied as independent scenario records; Capability and Solution definitions stay shared inside the tenant while their assessments and deployments are copied; a Transformation Case sits above those contexts and reads the selected records.

What cloning does to a case

A Transformation Case is not copied when a scenario is cloned. It remains a tenant-level decision record that points to its explicitly selected source and target.

If you clone the target scenario again, the existing case continues to point to the original target. Create a new case, or deliberately select the new target where the workflow permits, when the new scenario represents a different proposition. This prevents a reviewed case from silently changing because another planning branch was created.

Cases are also independent of the scenario currently selected in the browser. Opening the Cases section from Live or from a scenario shows the same tenant-level case portfolio.

Build the case

Open Cases from the top header, then select New case. Cases live outside the Live and scenario tabs because each one selects its own baseline and target. The decision frame opens in a modal so you can create it without losing your place in the case portfolio. Decision requested and Business objective sit side by side on wider screens (and stack on small screens) to keep this first step compact. After you create the case, the guided builder continues with eight durable steps:

Decision & scope — describe the decision, objective, boundary, owner, reporting currency, and horizon.
Baseline — pin Live as of an explicit date or choose an immutable baseline snapshot.
Target scenario — select the one planning or applied scenario whose lineage matches the pinned baseline.
Capability outcomes — select the promised business capabilities and the whole organisation or exact mapped organisation units.
Delivery changes — review target organisation movement and record explicit workforce or procurement decisions.
Investment & value — add transparent manual claims without netting unlike value types together.
Evidence & risks — record confirmed low/base/high assumptions and review limitations.
Review — refresh source fingerprints, authorize current economics, record the human recommendation, and submit for approval.

Every save writes governed case records. Refreshing the browser or returning later does not lose progress. Completion is derived from the underlying data; there are no manual “done” checkboxes.

Each builder field includes a short explanation beside its label. Use these prompts to distinguish similar concepts such as objective versus decision requested, capacity versus cash saving, and evidence versus assumption. Compact selectors are used for ordered choices such as confidence and assumption scope, while free-form numbers remain available where the case needs exact values.

Required, optional, and Advanced fields

Every builder field is labelled Required, Optional, or with the condition that makes it required. Required fields also have a red asterisk. Optional supporting detail appears under Advanced where it is not needed for the main flow; the section opens automatically if it contains an error.

New case and Decision & scope: title, owner, decision requested, business objective, scope, reporting currency, and horizon dates are required. The materiality threshold is optional under Advanced. The Case inherits its timezone and date/time presentation from Settings → Regional.
Baseline: source type and as-of date are required. A baseline snapshot is required only when Immutable snapshot is selected.
Target: target scenario and option label are required. The fuller target proposition is optional under Advanced.
Capability and organisation scope: select at least one capability, then choose the whole organisation or select at least one mapped organisation unit.
Workforce or procurement action: action, quantity, unit, confidence, audience, and decision basis are required. Effective dates are optional under Advanced.
Manual value line: lane, subtype, label, value kind, value, unit, period, confidence, inclusion, audience, description, and rationale are required. Currency is required for money values. Deduplication keys, confirmed assumption, and approved workforce action are optional under Advanced.
Assumption: label, value kind, scope, polarity, low/base/high values, confidence, audience, description, and rationale are required. Unit and currency are under Advanced; currency is required for money assumptions. An org unit or role type becomes required when that scope is selected.
Recommendation: the rationale is required before approval, even though a draft case can be saved while it is still being prepared.

Keep value claims separate

The builder preserves these lanes independently:

cashable savings
avoided cost
released capacity
service improvement
growth potential
risk reduction
implementation cost
recurring cost
consultancy fees

Released capacity is not a payroll saving. A cashable or avoided-cost claim requires a compatible, explicitly approved workforce or procurement action. Efficiency can remain a valuable capacity outcome without implying that filled positions disappear.

Manual claims have a native unit, period, origin, confidence, owner, source identity, rationale, audience, and inclusion status. Included claims must cite governed evidence or a confirmed assumption. Exact overlapping duplicates are blocked, and probable overlap stays visible until resolved.

Use blended rates and sensitivity

Assumptions always record low-value, base, and high-value cases. A rate can apply to:

the whole case
one in-scope team or organisational unit
one role type

Set the value polarity so Orgonaut can validate the range. AI-proposed assumptions cannot support an authoritative claim until a person reclassifies and confirms them.

Review readiness

The readiness panel distinguishes blockers from warnings. Typical blockers include missing source or target, incomplete capability assessments, stale source fingerprints, missing scope, and value lines whose current economics summary has not been authorized.

The progress bar is calculated from the case's actual readiness checks rather than from a fixed blocker penalty. It covers the pinned source, target lineage and freshness, capability and organisation scope, economics authorization when value lines exist, and five completeness checks for every in-scope target capability: target state, owner, supporting Work, evidence, and an outcome or recorded measurement limitation. Supplying one of those missing items advances the completed-check count; adding scope can introduce additional checks, and changing pinned facts can require Refresh source facts before the case reaches 100%.

Warnings remain visible in the report. Use Refresh source facts when the baseline, scenario, capabilities, Work, evidence, or deployments have changed. Re-authorize economics after any material case input changes.

Submitting moves a draft into review. An authorized approver can lock it only when all blockers have been resolved. Approval locks the case; later changes should be made through an intentional successor case rather than rewriting the reviewed decision record.

Preview and print the report

Select Preview report to open the twelve-section report. It covers:

decision requested
executive summary
current capabilities
target capabilities
work and operating-model redesign
AI solutions and accountability
separated value lanes
investment and ongoing cost
assumptions and sensitivity
implementation horizon
risks, controls, and limitations
evidence and methodology

Choose Client safe, Client restricted, or Consultancy internal before printing. Restricted and consultancy-internal projections require case-editing authority. Audience, cost, and workforce permissions are applied before report content is rendered. Use the browser's Print / Save PDF action for the report.

The value section keeps monetary totals separate from non-cash native values such as FTE, basis points, counts, and duration. On a narrow screen, wide evidence tables scroll inside the report rather than widening the page; the print layout fits those tables to A4.

The report is a current deterministic preview, not yet an immutable published report version. It displays the case revision, source date, audience, generated time, and authorized economics hash so reviewers can identify exactly what they saw.

Use cases in an agency engagement

Use a separate client tenant for each engagement. Invite the relevant consultants to that tenant, build the client's baseline and scenarios there, and create the Transformation Case there. The report can then carry consultancy fees and client-approved evidence without exposing the material to another client.

An agency-plan tenant does not currently act as a parent library that deploys capabilities, Work, solutions, or cases into other tenants. There is no cross-tenant clone or automatic update path. Reusable agency methods must therefore be recreated as generic records inside each authorised client tenant and adapted there. Keep client-specific people, costs, evidence, measures, deployment scopes, and assumptions inside the originating client's tenant.

This is the recommended operating model until an explicit, permissioned agency package feature is available: shared consultants, separate client data, and a separate case for each client decision.

Read cases through API, Astro, MCP, or CLI

Transformation Cases remain tenant-level even when the current browser or CLI profile is inside a scenario. Use:

GET /api/v1/transformation-cases for paginated summaries and readiness
GET /api/v1/transformation-cases/{case-key} for source, target, scope, deterministic findings, organisation delta, separated lanes, and client-safe value lines

The API applies cost and workforce permissions independently before building the response. include and fields[transformation-cases] can narrow top-level sections without changing the underlying case. Astro and MCP expose only the read capability read.transformation-case.readiness; they cannot confirm assumptions, authorize economics, approve, publish, or otherwise change a case. The equivalent CLI commands are orgonaut case list and orgonaut case show <case-key>.

Troubleshooting

A target does not appear: verify it was cloned from the pinned Live baseline or selected snapshot and is no longer initializing, cloning, or rejected.
Organisation units do not appear: the scenario clone must contain durable source-to-target org-unit mappings. Use the whole-organisation boundary if that is the truthful current scope.
A cash claim is rejected: approve a compatible workforce or procurement action and link a confirmed assumption or governed evidence.
Economics cannot be authorized: resolve duplicate or probable overlap, foreign-currency exclusions, and incomplete sources first.
Costs or workforce rows are absent: your role needs the separate cost or workforce projection permission.
The report shows warnings: return to the named builder section; warnings are intentionally retained rather than hidden by the report.

Search Results