Part V · The practice: How it is delivered

Part v

1. The practice How it is delivered#

Part V is the consulting practice: six phases and four gates from Discovery to Scaling, the templates at every level, and the workbook a team fills in with a client, from the maturity questionnaire to the decision map and the roadmap.

Whitepaper · Delivery and consulting framework

2. The delivery framework#

Value in days, low risk, scale without limits: from a firm's first engineered decision to one decision system#

How fast it goes and why the risk stays low, the framework of solutions, decision policies and analyses with a template for each, the archetype directory, and the six phases, four gates and four kinds of proof every use case passes.

Summary

3. In brief#

Decision optimization is not a software rollout. It changes how a firm decides, one decision at a time. This framework describes how vencortex delivers it: fast to first value, with low risk to the client at every step, and seamless to scale.

01

Getting started

4. Value quickly, scale seamlessly, low risk#

Most technology programmes fail between the pilot and the second use case. The getting-started process is designed so that the first decision pays for itself, the client carries little risk at any step, and every later decision starts from what the first one built.

VALUE QUICKLY

One real decision first

We start with a decision that matters now and has a measurable outcome. A DeOS instance and the first use case are set up and tested within days, and the first decision is run together with your team.

SCALE SEAMLESSLY

Every asset is reused

Solutions, policies, causal graphs, ontologies, expert questions and analyses are built as reusable decision assets. The second use case starts from the first; the tenth starts from the ninth.

LOW RISK

In parallel until proven

A use case can run alongside the day-to-day process without touching it. It only moves into the live process when it has passed the Prove gate on your own decisions.

How fast#

Speed comes from three things: a dedicated instance that connects to existing sources instead of replacing them, archetype templates that are adapted rather than built from scratch, and a first scope of one decision with one owner.

Low risk for the client#

Every step is built so that the client can stop without loss. Seven safeguards hold across all phases; chapter 04 shows the risk to the client phase by phase.

Gates with a stop

Small first scope

SAFEGUARD 04

People decide

SAFEGUARD 05

Your data, your instance

SAFEGUARD 06

Nothing is lost

Recommendations are explained and every override is possible and recorded. Judgement-only parts stay with people by design.

A dedicated instance on the cloud of the client's choice or on premises; encrypted in transit and at rest; proprietary models, nothing sent to third parties. Client data is never used to train shared models; the IP stays with the client.

If a use case stops, the client keeps the audit, the engineered policy and the decision records.

Nothing is lost

Works alongside

Taken together, the risk to the client is none in Discovery, Audit and Engineering, low during Implementation / PoV, and controlled once the use case is live, by which point it has passed the Prove gate.

Three ways to start#

What the client puts in#

Client effort is small and front-loaded on the people who own the decision. Discovery needs about 30 minutes per person for the maturity questionnaire and one sponsor workshop. The audit needs two to three hours with each decision owner and read-only access to past decisions. Engineering runs in working sessions with the decision owner and experts. From then on the work happens on the decision the team already has to make.

02

The framework

5. Strategy, Intelligence, Platform#

Every engagement uses the same framework. It names what a firm needs to optimize its decisions, and it fixes the three levels at which use cases are defined, scored, built and scaled.

Three levels: solution, decision policy, analysis#

Use cases are defined at three levels that nest. A solution holds the decisions of a decision lifecycle; a decision policy formalizes one of them; an analysis is one intelligence flow inside a policy, built from analysis archetypes of the catalogue. An analysis can serve several policies, and a policy can serve several solutions.

Four components of every analysis#

Every analysis has the same four components. They are the four steps of hybrid intelligence: Perceive, Diagnose, Predict, Recommend. Each runs on a platform capability; causal diagnosis runs on the Analysis capability, not on Context. The last column carries an L/S short entry example

Four decision policy types#

Every decision policy has one of four types: Selection, Policy optimization, Go / No-Go or Monitoring. The type sets the question its Recommend step answers and the shape of its output. The type sets what the policy's Recommend step delivers; every output comes with an explanation. Inside an analysis, contextual optimization uses Selection, Policy optimization or Go / No-Go; Monitoring sets the triggers that start the next decision.

OUTPUT OF THE RECOMMEND STEP

A ranked, scored shortlist

The best action or setting: price, lever, timing, structure, weights

A binary decision with its conviction threshold and the terms under which it holds

Triggers, thresholds and early warnings; attribution of variance to its causes

03

Maturity

6. Five levels, one path#

Maturity is not a ladder every client has to climb from the bottom. It describes the scope of what DeOS runs. A firm enters at the level that pays first, and each level reuses what the levels below have built.

Figure 5 Five maturity levels. The unit of value grows from governance, to an analysis, to a decision policy, to a solution covering a whole strategy or the total portfolio.

The levels map to the three framework levels and to what is scaled at the Scale gate (chapter 12): an analysis reused across decisions (L2), a decision policy rolled out across teams and funds (L3), or a solution for a decision lifecycle or the total portfolio (L4 and L5).

Improved maturity assessment#

The maturity assessment decides where a client enters. It has been extended in six ways, so that its result points directly to the audit scope and the capability that closes each gap. The full questionnaire, with every question and its scoring, lives in the DeOS Handbook and Workbook; this chapter shows how it works.

Six dimensions, mapped to the framework#

Decision heat map#

For each candidate decision, the heat map records how each component is done today. It shows where the human limits sit, and it becomes the baseline for the audit and for the human / AI modes set in engineering.

04

How we work

7. Six phases, four gates#

Every use case moves through the same six phases. They group into four stages, and each stage ends at a gate where the evidence decides whether the use case moves on.

Discovery

Which decisions are worth engineering?

Audit

What does each decision cost today, and what could it earn?

Engineering

How should this decision be made, beyond human limits?

Implementation / PoV

Does it work on a real decision?

Run

Is it part of how we work?

1. Identify the decisions and the analyses behind them, at three levels: solutions, decision policies, analyses 2. Run the maturity assessment and the decision heat map (chapter 03) 3. Score desirability, viability, feasibility and risk at each candidate's own level (chapter 10) 4. Roadmap: sequence of use cases and maturity levels

2. For each decision: analyse the status quo and the decision framework in use 2. Record how each component is done today, by people or by machines 3. Diagnose inefficiencies: behavioural, information, governance and analysis 4. Quantify the augmentation and automation potential 5. Underwrite what alpha would mean along each benefit dimension (chapter 11)

3. Rethink the decision beyond human limits of bandwidth, memory and bias 2. Start from the archetype directory (chapter 09) 3. Fill the solution, decision policy and analysis templates (chapters 05 to 07) 4. Map the causal decision graph; set the human / AI mode per component (chapter 08) 5. Develop the data ontology the decision runs on

4. Set up your dedicated DeOS instance and connect existing sources 2. Implement and test the use case, within days 3. Run a concrete decision together, guided or fully managed by us 4. Either an actual decision you need to make, delivered as a full service, or a run in parallel to your day-to-day 5. Evaluate and verify the underwritten alpha: the proof of value (PoV)

5. Train your team, typically within a few hours 2. Use it in day-to-day business 3. Concierge service whenever you need us

YOU GET

Maturity profile, scored long list at three levels, potential and complexity map, roadmap.

YOU GET

Decision audit per use case, inefficiency diagnosis, underwritten alpha. Ends at the Discover gate.

YOU GET

Solution, decision policy and analysis templates filled; causal decision graph; data ontology.

YOU GET

Evidence on the client's own decisions; verified alpha. Ends at the Prove gate.

YOU GET

Live use case, first value-realised review. Ends at the Realisation gate.

Scaling

What next, and who builds it?

1. Extend to new use cases, teams, funds and levels 2. Learn to build new solutions, decision policies and analyses yourself in the no-code DeOS Studio 3. Repeat the maturity assessment to show progress 4. Concierge service whenever you need us

YOU GET

A growing portfolio of decisions, increasingly built in house. Ends at the Scale gate.

Duration, effort and risk per phase#

Each phase is short, asks little of the client, and carries no or low risk to the running book. The risk to the client only rises to "controlled" once the use case is live, and by then it has passed the Prove gate.

05

Definition · Solution

8. Defining a solution#

A solution is the decision lifecycle of several decisions for one domain: use-case specific stages, each holding a set of decisions, run by named stakeholders under one mandate. It is where value lost at hand-offs is won back.

Stages and a set of decisions#

The stages are specific to the use case. A buy-and-build platform moves through thesis, platform, add-on pipeline, value creation and exit; a credit fund through origination, underwriting, structuring, monitoring and workout. There is no generic stage list. At each stage sits a set of decisions, each formalized as a decision policy. What one decision hands to the next is a logged human decision, and decisions that should be optimized together, such as a platform bid and its financing, are run as one decision lifecycle. In the product the solution is a board of stages with the policies at each stage (Figure 3).

How a solution is defined#

Six steps turn a decision lifecycle into a solution: which decision is made at which point, by whom, on what, and what it hands on. Steps 1 to 4 are one workshop per stage with its decision owner in Discovery; steps 5 and 6 use the decision heat map and the audit. The result is the decision map below, from which the solution template and one decision policy template per decision follow.

The decision map#

One row per decision point: the stage, the moment and its trigger, the decision made there with its type and owner, what it needs from earlier decisions and what it hands on, the human / AI mode today and the target, and its place on the roadmap. A stage can hold several points; a point with two questions holds two policies. Decision points hide in five moments: a commitment of money, people or time; a pass or stop; a term set; a signal checked against a trigger; an outcome reviewed.

Stakeholders#

A solution has three groups of stakeholders. Sponsor and owners: the sponsor, the solution owner and a decision owner per stage. Contributors: analysts, experts, data and technology. Control and recipients: risk, compliance, auditors, investors and lenders. The template names each of them, because a decision without a named owner cannot pass the Discover gate.

The solution template#

Six sections capture a solution end to end. The example is a PE buy-and-build platform; the same example runs through the policy and analysis templates in chapters 06 and 07.

Example: PE buy and build. Names, numbers and thresholds are illustrative, not client data or product output.

06

Definition · Decision policy

9. Defining a decision policy#

A decision policy is one decision, formalized well enough that it can be governed, analysed, recommended on and learned from. The template has five sections: identity, constraints, recommendation, analyses, and process and record.

Example: PE buy and build. Names, numbers and thresholds are illustrative, not client data or product output.

How the Recommend step combines the analyses#

Each analysis ends in its own contextual optimization. The policy then has its own Recommend step that combines the analyses into one recommendation, against the policy's optimization goal and within its constraints. In the example, it first runs a Go / No-Go on conviction and then optimizes price and financing. The recommendation carries its options, actions, goal, criteria and insights, and the named decision owner decides.

Behind the recommendation, the process of the policy sets out its stages and steps, each with an owner, from the strategic objectives and data contexts to scans and expert predictions. It is the "process and record" section of the template, as it runs in the product.

07

Definition · Analysis

10. Defining an analysis#

An analysis is one run of the intelligence flow. It is defined by its question and owner, its constraints and the inefficiencies it removes, its data, and its four components, each with analysis archetypes and a human / AI mode. Defined this way it can be reused across policies and its contribution can be proven.

Example: PE buy and build. Names, numbers and thresholds are illustrative, not client data or product output.

An analysis in the product#

In the product an analysis is a pipeline. Data rooms and scans give the perceive context; expert predictions and AI functions do the diagnosis, prediction and optimization; the result is handed to the policy's Recommend

step.

Data and source#

The template asks for the data of every analysis and where it comes from: client proprietary systems, DeOS ecosystem data and expert input. Sources connect to the client's instance; nothing has to be replaced to start, and client data is never used to train shared models.

08

Human and AI

11. Automated, augmented, judgement only#

Not every part of an analysis should be automated, and not every part should stay manual. The human / AI mode is set per component of every analysis, so that people spend their judgment where it carries information or accountability.

Default modes for the example analysis#

I l lu strative

The synergy analysis of chapter 07 sets a mode for each of its four components. The defaults come from the analysis families (chapter 09) and are adjusted in engineering.

ANALYSIS ARCHETYPES IN THE EXAMPLE

Causal driver decomposition of the target's margins; relative performance

Catalyst prediction (synergy capture) fused with operating partners; catalyst effect and impact on platform EBITDA

Treatment optimization of integration levers; contextual synergy explanation

WHY

The model decomposes margins; the operating partner checks the drivers that matter for the case.

Model and operating partners both carry information; they are fused by track record.

DeOS optimizes the integration levers; the final lever choice stays with the operating partner.

At policy level, the Go / No-Go itself stays with the investment committee: the judgement-only part of the Recommend step. Modes are calibrated from outcomes: a component moves towards automation only when its track record supports it, and back when it does not.

09

Archetype directory

12. Start from an archetype, not a blank page#

Engineering starts from the archetype directory: solution archetypes, policy archetypes and analysis families. Each one is a template already filled with typical stages, decisions, analysis chains and modes, adapted to the client instead of built from scratch.

Solution archetypes#

Stages are use-case specific; the stages listed are typical for the archetype and are set per client.

10

Qualification

13. Four dimensions at three levels#

In discovery, every candidate is scored on desirability, viability and feasibility, and risk is scored separately because it can veto a use case that looks attractive on everything else. Each candidate is scored at its own level: a solution, a decision policy or an analysis.

D · V · F · R at each level#

How the levels roll up#

Score each candidate at its own level: a solution, a decision policy or an analysis.

An analysis reused by several policies counts its value in each of them; reuse raises viability.

A red-line risk at any level stops everything above it: a blocked analysis blocks the policy that depends on it.

The level you land decides the maturity entry: an analysis lands at L2, a policy at L3, a solution at L4 or L5.

Potential = desirability + viability complexity = (10 − feasibility) + risk scores 0–10

Rule: no use case passes the Discover gate without a named owner, an underwritten alpha, a readiness check and a risk score. Moonshots are not rejected; they are staged through the maturity levels, so the fruit landed first funds and de-risks them. An analysis lands at L2, a policy at L3, a solution at L4 or L5.

11

Quantifying benefits

14. Underwriting the alpha#

Before a use case is engineered, we underwrite what it should deliver: six forms of benefit, along the four alphas. The same grid is used again at the Realisation gate to compare what was promised with what was delivered.

From benefit to number#

I l lu strative

Each benefit is written as an equation, never as a fixed promise, so it can be checked later with the client's own figures.

At solution level the same equations are summed over the decisions of the decision lifecycle, plus what is lost at hand-offs today. In the buy-and-build example, the solution template underwrites a 0.5 turn lower average add-on multiple across 10 add-ons. An analysis reused by several policies counts its value in each of them.

Effectiveness is the hardest to prove and the most valuable; efficiency and coverage are the fastest to show. A good roadmap shows the fast ones first and lets the slow one build its track record.

12

Gates

15. Four gates, from promise to scale#

A gate is a decision about a decision. Each one has a question, the evidence required and a fixed set of outcomes. No use case moves on because of momentum, and every gate can stop a use case at low cost.

Each gate asks for a different kind of certainty. The Discover gate weighs a promise: scores, underwritten alpha, an owner and readiness. The Prove gate weighs evidence from the client's own decisions: backtest, parallel run, trust and control. The Realisation gate compares the value realised in daily use with what was promised. The Scale gate decides what to scale: an analysis, a decision policy or a solution. The evidence and pass criteria of each gate follow.

GATE 1 · DISCOVER

Promise

AFTER DISCOVERY AND AUDIT

Is this decision worth engineering?

Evidence on the table D, V, F and R scores at the candidate's level, potential and complexity

Audit with underwritten alpha

Named owner and sponsor

Readiness check across people, process, technology and compliance

Pass when the potential is high enough, no red-line risk remains, and readiness is met or can be enabled.

Outcomes: Go to Prove

Stage

Park

GATE 2 · PROVE

Evidence

AFTER ENGINEERING AND IMPLEMENTATION / POV

Does it work on our own decisions?

Evidence on the table Analysis-level proof: calibration and accuracy

Outcome proof: point-in-time backtest and parallel run

Process proof: adherence, cycle time, audit

Trust: output quality, trust calibration, user control

Pass when the evidence supports the underwritten alpha and the users trust and control the output.

Outcomes: Go to production

Iterate

Stop

GATE 3 · REALISATION

Value realised

AFTER RUN

Is the underwritten alpha being delivered in daily use?

Evidence on the table Realised versus underwritten benefits on the six-by-four grid

Adoption and usage by the decision owners

Overrides and their outcomes

Learning: is the model improving with outcomes?

Pass when realised value tracks the underwriting, or the gap is explained and fixable.

Outcomes: Keep and grow

Re-engineer

Retire

GATE 4 · SCALE

Scale

ANALYSIS · DECISION POLICY · SOLUTION

What do we scale, and how far?

Evidence on the table Which assets are reusable: analyses, policies, ontologies

Demand from other teams, funds and strategies

Readiness of the next teams

Team capability to build in DeOS Studio

Pass when a reusable asset and a next owner exist.

Outcomes: Scale an analysis

Scale a policy

Scale a solution

The Scale gate distinguishes the three levels that can be scaled. An analysis is reused in other decisions, for example a catalyst prediction used by several funds. A decision policy is rolled out to other teams or asset classes. A solution connects decisions into a full decision lifecycle or the total portfolio, moving the firm up the maturity levels.

13

Readiness

16. People, process, technology, compliance#

A use case can be attractive and still not ready. Readiness is checked at every gate. When it is missing, the right move is to defer and enable, never to force.

The use case moves on with a named enabling action, for example data access or a compliance review,

enable

tracked to the next gate.

Defer and enable. A blocked use case stays on the roadmap; another use case takes its slot in the

blocked

portfolio.

The regulatory constraints named in the policy and analysis templates (chapters 06 and 07) are the input to the compliance check: each constraint says how it is checked, and the check is part of the evidence at the gate.

14

Proof

17. What is the proof?#

Proof comes in four kinds, from the single analysis to the innovation the firm can now do. Each kind has its own evidence, and the Prove and Realisation gates read them together.

Trust and control#

Result

Decisions the firm can stand behind, and a track record that proves skill.

15

Objections and answers

18. What clients ask, and what we answer#

The same questions come up in every engagement. They are grouped three ways: by phase of the process, by component of the technology, and by argument of decision optimization.

By phase of the process#

By component of the technology#

Takeaway

19. Start small, prove it, scale it#

The fastest way to a firm-wide decision system is one decision that pays, proven on the firm's own data at low risk, built from assets the next decision can reuse.

© vencortex®. This paper describes how vencortex delivers DeOS. It is not investment advice.