DeOS AlphaBook

Chapter 13 · Part VI · Reference: The language of the book

Glossary

pages 459–4914 figures2 tables

Part VI · Reference: The language of the book

Part VI

1. Reference The language of the book#

Part VI is the reference: every term with its definition, the older names it replaces, and the conventions this book settles where the papers once differed.

Chapter 13Glossary

The language of decision optimization, term by term, with the older terms and the conventions settled in this book.

Chapter 13 · Reference

Glossary · The terms of DeOS

2. The language of decision optimization#

The terms of DeOS and decision optimization, defined in one place#

258 terms from the decision optimization, platform, technology, delivery and use-case papers, aligned to one framework, with the older names each term has gone by.

01 · strategy 02 · intelligence 03 · platform
Policy and mandate Four steps Five capabilities
The end-to-end decision policy and the mandate it serves. Perceive, diagnose, predict and recommend, in every analysis. Governance at every level; context, analysis, recommendation, learning

Summary

3. In brief#

The vencortex papers were written over time, for different audiences, and the same idea has often carried different names. This glossary fixes one name and one definition for each term specific to DeOS and decision optimization. Where papers disagree, the definitions follow the current framework; the names used in earlier papers are listed so older material can still be read.

One equation at the top.

Decision optimization = Strategy + Intelligence + Platform. Strategy is the end-to-end decision policy plus the mandate. Intelligence is hybrid intelligence in four steps. The platform provides five capabilities, with Governance spanning every level.

Work is structured in four levels.

A solution is a decision lifecycle in stages; a decision policy is one decision of four types (Selection, Policy optimization, Go / No-Go, Monitoring); an analysis is one intelligence flow in four components; an analysis archetype is one reusable method.

Steps are verbs, capabilities are nouns.

Diagnose, Predict and Recommend are steps an analysis runs; Analysis and Recommendation are capabilities the platform provides to every decision. Each component runs Automated, Augmented or Judgement only.

How to read an entry.

Each entry gives the definition, then the names earlier papers used, then the papers the term comes from as short codes. Framework terms are highlighted in the first section.

Sections follow the flow of a decision.

The framework; solutions, decisions and analyses; scoping and diagnosing the context; predicting and judging; recommending an action; platform, roles and technology; value, alpha and how decisions are judged; delivery and adoption; use-case terms.

Older terms, and what to use now.

Governance + Intelligence + Platform became Strategy + Intelligence + Platform, Scope context became Perceive context, and the counterfactual world model stage became Predict. Older papers remain valid; read their terms as the current ones.

Conventions settled in this book.

Where the papers used one word for several things, the book settles on one convention: maturity levels L1 to L5, the four levels of the hierarchy, policy archetypes as a type plus a decision archetype, and human / AI modes in place of automation levels.

All terms, A to Z, with their sources.

An alphabetical index of all 258 terms, and the source codes for every paper an entry draws on, from the framework and the platform paper to the use cases and the Sovereign Infrastructure work.

258terms from the decision optimization, platform, technology, delivery and use-case papers, each with one name and one definition.
4levels the work is structured in: solution, decision policy, analysis and analysis archetype.
5capabilities the platform provides: governance, which spans every level, and context, analysis, recommendation and learning.

How to use this glossary

4. One vocabulary for decision optimization#

The vencortex papers were written over time, for different audiences, and the same idea has often carried different names. This glossary fixes one name and one definition for each term specific to DeOS and decision optimization. Where papers disagree, the definitions follow the current framework below; the names used in earlier papers are listed under each entry so older material can still be read.

Decision optimization = Strategy + Intelligence + Platform. Strategy is the end-to-end decision policy plus the mandate. Intelligence is hybrid intelligence in four steps: perceive, diagnose, predict, recommend. The platform provides five capabilities: governance, which spans every level, and context, analysis, recommendation and learning.

Work is structured in four levels. A solution is the decision lifecycle of several decisions in use-case specific stages; a decision policy is one decision, of one of four types (Selection, Policy optimization, Go / No-Go, Monitoring), whose Recommend step combines its analyses; an analysis is one intelligence flow with four components (perceive context, causal diagnosis, counterfactual prediction, contextual optimization), each run automated, augmented or judgement only; an analysis archetype is one reusable method inside a component.

Steps are verbs, capabilities are nouns. Diagnose, Predict and Recommend are steps an analysis runs; Analysis and Recommendation are capabilities the platform provides to every decision.

How to read an entry. Each entry gives the definition, then the names earlier papers used (earlier / also), then the papers the term comes from as short codes, listed at the end. Framework terms are highlighted in section 01.

DECISION OPTIMIZATION = STRATEGY + INTELLIGENCE + PLATFORM STRATEGY INTELLIGENCE PLATFORM The firm's edge, made explicit Hybrid intelligence, in four steps DeOS, five capabilities End-to-end decision policy 1 Perceive Governance across every level the chain of decision policies what should we look a DECISION OPTIMIZATION = STRATEGY + INTELLIGENCE + PLATFORM STRATEGY The firm's edge, made explicit End-to-end decision policy the chain of decision policies + Mandate goals and constraints INTELLIGENCE Hybrid intelligence, in four steps 1 Perceive what should we look at? 2 Diagnose what drives outcomes? 3 Predict what will, could, would happen? 4 Recommend what should we do, and why? PLATFORM DeOS, five capabilities Governance across every level Context Analysis Recommendation Learning HOW THE WORK IS STRUCTURED SOLUTION use-case specific stages, each with its decisions, run by named stakeholders Idea selection Go / No-Go Price Sizing Monitoring Exit arrows are hand-offs, each a human decision DECISION POLICY one decision; its Recommend step combines its analyses ANALYSIS Fair value ANALYSIS Downside risk ANALYSIS Catalyst odds ANALYSIS = FOUR COMPONENTS 1 Scope 2 Diagnose 3 Predict 4 Recommend result: a calibrated distribution, explained
Figure 1 The framework at a glance. Top: the three pillars and what each contains. Bottom: how a solution, a decision policy and an analysis nest. Decision and analysis names are examples.

01

The framework

5. The framework#

The terms that define decision optimization as a whole. Every other entry in this glossary sits inside one of them. Where earlier papers used other names, these definitions apply and the older names are listed under each entry.

Decision optimizationDEFINITIONThe end-to-end engineering of how an organisation makes its high-stakes decisions, so that each one is the best possible decision given its context, constraints and goals. Decision optimization = Strategy + Intelligence + Platform. It augments human judgment rather than automating it, and it works from action to action, not from data to report.
StrategyPILLAR 1The firm's edge, made explicit. Strategy = End-to-end decision policy + Mandate. It belongs to the client: decision optimization formalizes, tests and runs the strategy, it does not choose it.
End-to-end decision policySTRATEGYThe connected chain of decision policies a strategy runs through, from first selection to exit and review, with the hand-offs between them. It is the strategy's logic in codified form; a single decision policy is one link of it.
MandateSTRATEGYThe set of goals and constraints a strategy must serve: return and risk targets, liabilities and horizon, limits, exclusions and regulation. A recommendation is optimal only relative to the mandate (“the mandate decides”). Encoded in DeOS, the mandate becomes the guardrails.
GoalSTRATEGYAn outcome a decision should achieve, such as a target return, a Sharpe ratio or the probability of meeting a liability. The primary goal is the one optimized (the optimization goal of the decision policy template, with its expected value and 5% to 95% interval); secondary goals are traded off against it with explicit preferences. For each goal DeOS reports the probability that it is met.
ConstraintSTRATEGYA limit a decision must respect, such as a mandate limit, covenant, leverage cap or liquidity rule. A hard constraint is never traded off and is enforced by the system, not by instruction; a soft constraint (“stay close to”) is a preference expressed as a penalty.
Context, constraints and goalsThe triad that defines what an optimal decision is. There is no universal right answer, only the best trade- off for a specific situation, its limits and its objectives. Two firms with the same forecast should often act differently.
IntelligencePILLAR 2Hybrid intelligence applied to a decision: the analytical flow that turns data and expertise into a recommendation. It runs in four steps: 1 Perceive, 2 Diagnose, 3 Predict, 4 Recommend. In an analysis the four steps are its four components.
Hybrid intelligenceINTELLIGENCE“The ability to achieve complex goals by combining human and artificial intelligence, thereby reaching superior results to those each of them could have accomplished separately, and continuously improve by learning from each other” (Dellermann et al. 2019). Machines bring scale, simulation and consistency; people bring purpose, context, judgment and accountability.
PerceiveSTEP 1Context engineering for the decision: deciding what to look at. Perceive sets the ontology, the decision- centric data room, the peer set and comparable situations, and the signals that bear on the outcome. In an analysis it is the Perceive context component, run on the Context capability. Question: what should we look at?
DiagnoseSTEP 2Causal diagnosis of the context: what drives outcomes here and now. It diagnoses the state of the world (regime, position against peers) and the causal mechanisms, and splits value or return into its causes. In an analysis it is the Causal diagnosis component, run on the Analysis capability. Question: what drives outcomes?
PredictSTEP 3Counterfactual prediction: what will most likely happen, what could happen and what would happen under each possible action, as calibrated distributions from a counterfactual world model. In an analysis it is the Counterfactual prediction component, run on the Analysis capability. Question: what will, could and would happen?
RecommendSTEP 4Contextual optimization: what to do about it to achieve our goals, given our context and constraints, and why. The output is ranked, sized and explained actions with a conviction score, or an explicit wait. In an analysis it is the Contextual optimization component; in a decision policy its own Recommend step combines the policy's analyses into one recommendation. Question: what should we do, and why?
Intelligence flowSTRUCTUREThe four-step sequence Perceive, Diagnose, Predict, Recommend that every analysis runs. Each step conditions the next, and every outcome feeds the next cycle through Learning; skipping a step is the common failure. For building analyses it splits into six analysis steps.
PlatformPILLAR 3DeOS as the firm's own decision infrastructure: modular, dedicated, and learning only for its owner. It provides five capabilities: Governance, Context, Analysis, Recommendation, Learning. Governance spans every level and every step; the other four run the intelligence flow and close the loop.
GovernanceCAPABILITYSpans every level, the solution, each decision policy and each analysis, and every step. It codifies the solution, the decision policies and the mandate into guardrails, processes and roles; versions and approves analyses and their models; and logs every decision with its context, recommendation, explanation, human decision, override and reason, so that everything is auditable and replayable. “A prompt is not a policy.”
ContextCAPABILITYConnects internal and external data, of any kind, into one point-in-time model of the decision's world: ontology, entities, drivers, data rooms, context scans and generated context. It runs the Perceive step (analysis step 1, context engineering).
Analysis (capability)CAPABILITYRuns the causal diagnosis and the counterfactual predictions, fusing data with expert judgment, and produces calibrated outcome distributions, including the tails. It runs the Diagnose and Predict steps (analysis steps 2 causal diagnosis, 3 probabilistic prediction and fusion, 4 counterfactual simulation).
RecommendationCAPABILITYOptimizes actions against goals and constraints and turns predictions and human inputs into ranked, sized and explained actions with conviction, insights and drill-down to the why. It runs the Recommend step (analysis steps 5 contextual optimization and 6 explanation), inside each analysis and in each decision policy's own Recommend step.
LearningCAPABILITYKeeps the decision memory, compares realized outcomes with predictions, scores decision quality separately from outcome, and updates beliefs, weights, models and policies from every outcome, including decisions not taken and worlds that did not happen. It is where the four alphas compound.
SolutionSTRUCTUREThe decision lifecycle of several decisions for one domain, such as an investment strategy, a fund, an asset class or a buy-and-build programme: use-case specific stages, each holding a set of decisions, run by named stakeholders under one mandate. It holds the decision policies, the hand-offs and the decision assets, and every concrete decision that runs through them. The top of four levels: solution, decision policy, analysis, analysis archetype.
Decision policySTRUCTUREOne decision, formalized: the standardized, reusable and auditable way a decision is made at one decision point. It holds several analyses and combines them into one recommendation through its own Recommend step. Its template fields are type, objective, owner, regulatory constraints, recommendation (actions, options, optimization goal, decision criteria, insights) and analyses, plus process and record. It is the main artefact of decision engineering.
AnalysisSTRUCTUREOne run of the intelligence flow that answers one question a decision depends on, such as fair value, probability of default or catalyst likelihood. It has four components, Perceive context, Causal diagnosis, Counterfactual prediction, Contextual optimization, each built from analysis archetypes with its own human / AI mode. Its template fields include regulatory constraints, owner, main KPIs, main inefficiencies, data and source, and the components. Its result is a calibrated distribution. It is the smallest optimizable unit and is reusable across decisions.
Analysis archetypeSTRUCTUREA reusable, standardized method within one analysis step, such as contextual valuation, catalyst prediction or price optimization: the building block of an analysis component, and the bottom of the four levels. The analysis catalogue lists every archetype with its question, output, proof metric and default human / AI mode, grouped into analysis families by component. Because it is predefined, the same analysis runs the same way every time it is reused.
Analysis componentsSTRUCTUREThe four parts every analysis has, one per intelligence step: Perceive context (Perceive, on Context), Causal diagnosis (Diagnose, on Analysis), Counterfactual prediction (Predict, on Analysis) and Contextual optimization (Recommend, on Recommendation, including the explanation). Not every analysis runs every analysis archetype, but every analysis has all four components.
Six analysis stepsSTRUCTUREThe finer split of the four steps used to build analyses: 1 context engineering, 2 causal diagnosis, 3 probabilistic prediction and fusion (will), 4 counterfactual simulation (could, would), 5 contextual optimization (what) and 6 explanation (why). Every analysis archetype sits in one of them.

02

Structure

6. Solutions, decisions and analyses#

How work is organised inside DeOS, from the instance down to one analysis, and the standard decision types that recur across asset classes.

DeOS instanceThe top container: the firm's dedicated deployment. It holds one or more solutions, which draw on decision assets such as the ontology, criteria library and decision memory.
Decision lifecycleThe linked decisions a solution runs through, from sourcing to exit and learning, mapped as stages with their decision points and optimized together as one path, because outcomes are often decided by how choices interact. The stages are use-case specific: each solution defines its own decisions and their order, and the framework prescribes no generic list. “The selection shapes the price, the price shapes the financing, the financing shapes the exit.”
StageOne use-case specific step of a solution's decision lifecycle, such as thesis, platform, add-on pipeline, value creation and exit in a buy-and-build solution. Each stage holds the set of decision policies made at it and has a named decision owner.
Decision pointA moment in a stage of the decision lifecycle at which a decision is made: a commitment of money, people or time; a pass or stop; a term set; a signal checked against a trigger; an outcome reviewed. Each decision point has a trigger and a frequency and is served by one or more decision policies.
Decision mapThe first artefact of a solution: one row per decision point with its stage, 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. Drawn in six steps (decision lifecycle, decision points, name and type, inputs and hand-offs, today and target, roadmap); it feeds the solution template's stage register and one decision policy template per decision. Workbook Template T.
DecisionOne concrete case that runs through a decision policy: this name, deal or project at this point in time. It is stored with its context and outcome in the decision memory. In DeOS terms a decision is “the commitment to an action, followed through to the next action”, not a forecast, dashboard or summary.
Hand-offWhat one decision passes to the next in a decision lifecycle, such as conviction, target size or triggers. Each hand-off is a human decision, made by the named decision owner and logged. Value lost at hand- offs is what an end-to-end decision lifecycle removes.
Levels of optimizationDeOS can optimize at three levels: a single analysis (a better valuation), a single decision (better position sizing) and a decision lifecycle (a better path).
Decision levelThe unit a decision is made for: a single asset, multiple assets or a portfolio. Results aggregate across levels, for example from position to sector book to fund.
Four tiersThe nested granularities at which the intelligence flow runs in the use cases, typically universe, portfolio, company or issuer, and asset; called tiers, not levels, to keep them apart from maturity levels and the four levels of the hierarchy. Diagnosis and prediction run bottom-up; optimization runs top-down, from objective to target exposure to individual positions.
Decision assetsThe predefined, standardized and reusable components every decision policy of a solution draws on: decision policies and their templates, data ontologies, metrics, criteria libraries, causal decision graphs, expert prediction questions, data connectors, insights and prebuilt analyses. Because they are standardized, the same decision runs the same way every time, and every new use case starts from them rather than from scratch.
Aggregation layerViews across all decisions of a solution, by sector, book, fund or vintage.
Decision policy typeOne of four types every decision policy has, each answering a different shape of question and producing a different shape of recommendation: Selection (which options?), Policy optimization (which actions?), Go / No-Go (yes or no?) and Monitoring (what should trigger action?). Selection, policy optimization, Go / No-Go and monitoring are also the modes of contextual optimization inside an analysis.
SelectionTYPEThe decision policy type that answers which options? by probabilistic multi-criteria decision analysis (MCDA). Its output is a ranked, scored shortlist that trades off several goals and constraints at once. Decision archetype: selection. In DeOS it is probabilistic: each option gets the probability that it is best.
Policy optimizationTYPEThe decision policy type that answers which actions? Its output is the best action or setting: price, lever, timing, structure, weights or hedges. Decision archetypes: price, treatment, timing, financing, allocation, portfolio construction and hedging.
Go / No-GoTYPEThe decision policy type that answers yes or no? Its output is a binary decision with its conviction threshold and the terms under which it holds. Decision archetype: conviction test. It can run first as a gate (is this worth optimizing at all?) and again at the end on the optimized terms.
MonitoringTYPEThe decision policy type that answers what should trigger action, and why did it differ? Its output is signals, thresholds, triggers and early warnings that reopen a decision, and the attribution of variance to its causes. Decision archetypes: trigger design and root cause. Inside an analysis, monitoring is also a mode of contextual optimization: the one that sets triggers and thresholds.
Decision archetypeA decision with one clear objective that recurs across asset classes and from which concrete decision policies are built. There are eleven, grouped by decision policy type: selection (Selection type); conviction test (Go / No-Go); price, treatment, timing, financing, allocation, portfolio construction and hedging (policy optimization); trigger design and root cause (monitoring). A decision policy type plus a decision archetype is a policy archetype.
RoadmapThe ordered portfolio of use cases a client will engineer: which decision policies, analyses and solutions land in which wave, the maturity level each wave reaches, the alpha each use case is underwritten for, the proof it must show at its gate and the readiness work before it. Derived with the client in seven steps in Discovery (long list, score, underwrite, position, sequence, set the target, agree), fixed at G1 and revised at every gate. Workbook Template S; method in the Solutions Catalogue.
Decision archetype profileThe one-page argument for a decision archetype: what makes it superhuman, the main questions it answers, the AI capabilities it rests on, the KPIs that measure and benchmark it, how it delivers the four alphas, the inefficiencies found today and its value equation in monetary value. Eleven profiles, one per decision archetype, in the Solutions Catalogue.
Solutions catalogueOne page per customer segment: the solution archetype and its stages, the challenge (pains by source), the target segment (fit, size, goals), the value (benefits by form and the value equation), the decisions the solution holds with the question each answers, example analyses and the typical titles of the four decision roles. Twenty-two segments in five clusters, following the Customer Segments and Personas document.
Value equationA benefit written as an equation with the client's own numbers rather than as a promise: effectiveness = decisions per year × capital per decision × Δ decision quality; efficiency = hours freed × decisions × cost per hour; risk = Δ probability of a loss event × exposure × loss given event. Each decision archetype profile and each catalogue page carries its value equation in monetary value; Template V underwrites it.
Conviction testThe Go / No-Go decision archetype: do we have the conviction to proceed under these terms?
TreatmentThe policy optimization decision archetype that asks which operational levers management must pull: the engagement agenda or value creation plan.
Trigger designThe monitoring decision archetype that sets what should trigger action: thresholds, alerts and early warnings.
Root causeThe monitoring decision archetype that explains the variance between expected and actual outcomes, along the causal decision graph, and attributes it to levers, externals, broken links or luck. It feeds back into selection and price.
TemplatesOne form per level, so every solution, decision policy and analysis is specified the same way: the solution template, the decision policy template and the analysis template. Each lists its fields with guidance and a worked example; filled in, they are the specification DeOS runs.
Solution templateTEMPLATEThe specification of a solution: identity and solution owner; mandate (goals, constraints, regulatory frame); stakeholders; use-case specific stages with the decisions at each stage, hand-offs and decision lifecycles; decision assets and aggregation views; underwritten alpha, proof and roadmap.
Decision policy templateTEMPLATEThe specification of one decision: decision question, solution and stage, type, objective, owner, frequency and trigger; regulatory and mandate constraints; the recommendation (actions, options, optimization goal, decision criteria, insights); the analyses and how its Recommend step combines them; process, hand-offs, decision record and proof. Filled in completely, it is the decision use case. “A use case is a decision, not a tool.”
Analysis templateTEMPLATEThe specification of one analysis: question, analysis family, decisions served and owner; regulatory constraints, main KPIs, main inefficiencies today and data and source; the four components with their analysis archetypes and human / AI mode; output, proof and reuse.
ObjectiveTEMPLATEWhat a good decision achieves, in measurable terms, such as raising platform equity IRR by at least 2 pp per add-on within the leverage limit. The optimization goal is the measurable outcome on which the options are then ranked.
Regulatory constraintsTEMPLATEThe rules a decision or analysis must satisfy and how they are checked: AI regulation classification, model risk rules, data protection, inside information and confidentiality, mandate and investment restrictions, explainability and audit duties. Recorded in the policy and analysis templates and in the solution's regulatory frame.
Main KPIsTEMPLATEHow an analysis is judged: the outcome metrics it must improve for the decision and the quality metrics of the analysis itself, such as calibration or lead time.
Main inefficienciesTEMPLATEThe status quo an analysis replaces: how its input is produced today, by whom and how long it takes, the human limits it removes and the type of inefficiency (governance, information, analysis, behaviour).
Data and sourceTEMPLATEThe data an analysis uses and where it comes from: client proprietary data, DeOS ecosystem data and expert input, with concepts and metrics, ontology objects, point-in-time status and gaps.
Archetype directoryThe starting templates at each level: solution archetypes (such as long / short equity, multi-asset credit, PE buy and build, total portfolio), decision policy archetypes (one per decision archetype, by type, with a typical analysis chain) and analysis families (by component). Engineering adapts an archetype rather than building from scratch.
Analysis familyA group of analysis archetypes that serve the same component: context representation, scan, construction and generation (Perceive context); valuation and mispricing, drivers and regime, standing (Causal diagnosis); prediction and fusion, simulation (Counterfactual prediction); Selection, policy optimization, monitoring, Go / No-Go and explanation (Contextual optimization). Each family has a default human / AI mode.
Nesting ruleA solution lists its stages and the decision policies at each; a decision policy lists its analyses; an analysis lists every decision it serves. Defined this way, the second use case starts from the first.
StakeholdersThe people around a solution: the sponsor and owners (solution owner, a decision owner per stage), the contributors (analysts, experts, data and technology) and control and recipients (risk, compliance, auditors, investors, lenders).
Decision ownerThe person or body accountable for one decision, who recommends or decides and records conviction and overrides, such as a portfolio manager, deal partner, CFO or investment committee. Each level has a named owner: the solution owner, the decision owner of each policy and the analysis owner who keeps an analysis calibrated.
Core question and outputThe fixed header of every decision in the use-case papers: the one question it answers and the deliverable it hands to the next decision.

03

Intelligence · Perceive and diagnose

7. Scoping and diagnosing the context#

Terms used in the first two steps of the intelligence flow: deciding what to look at, and finding what drives outcomes.

Perceive contextPERCEIVEThe first component of every analysis: the Perceive step, built by context engineering (analysis step 1) on the Context capability. Its analysis archetypes fall into context representation, context scan, context construction and context generation. Question: what should we look at, and what is it comparable to?
Context engineeringPERCEIVESelecting and preparing the decision-relevant representation of the world: “as much data as necessary, as little as possible”. Its building blocks are the data room and ontology, data loader, context scan, context generation, feature engineering and representation. In DeOSAlpha, it decides what the learner sees and in what structure.
OntologyPERCEIVEThe structure that turns rows and columns into real-world objects (companies, units, product lines, assets, deals, people) and the relations and causal structure between them, at any granularity and frequency. Policies refer to the ontology, so data can change without breaking them.
Context graphPERCEIVEThe structure into which the ontology organises input data of any modality, so the learner reasons about a system rather than isolated columns.
Decision-centric data roomPERCEIVEAll the data one decision needs, collected per decision and point in time. It starts from the decision, not from the data: “which data the decision needs, not which data exists”.
Point in timePERCEIVEData, inputs and decisions stored exactly as they were known at the decision date, with no look-ahead. It makes backtests fair and audits possible.
Context scanPERCEIVEAutomated or analyst-led search for comparable entities (who is like this asset?) and comparable situations (when was it like this before?). Its output, the trajectory of the comparables, grounds base rates, benchmarks and AI predictions.
Fine-grained peersPERCEIVEA peer set built per asset from its drivers, characteristics and behaviour rather than from a sector code, and adjustable by the analyst.
Contextual base ratePERCEIVEWhat usually happened to comparable entities in comparable situations (regime, lifecycle stage, ownership), used in place of a sector average and shown to experts at the moment of judgment.
Context generationPERCEIVECreating context where data is missing, such as synthetic comparables or counterfactual situations simulated from the causal decision graph. Generated context is always labelled and carries wider uncertainty.
RepresentationPERCEIVEThe compact, decision-relevant description of an asset's characteristics, causal drivers and trajectory that the prediction step consumes, produced by feature engineering.
SpacePERCEIVEA cluster of companies that share causal drivers or themes, detected automatically and used in place of a sector as the unit of allocation.
Causal diagnosisDIAGNOSEThe second component of every analysis and analysis step 2, run on the Analysis capability: separating what really drives outcomes from what merely correlates with them. It covers the regime, the drivers behind a metric, valuation and mispricing, relative standing, holdings that share a driver, and the split of return into systemic beta, structural alpha and tactical alpha.
Causal decision graphDIAGNOSEA small, human-readable causal model of one decision, after Lorien Pratt: decision levers act through intermediates, alongside externals, on outcomes that are judged against goals and bounded by constraints. It guides the AI, structures the why and gives people and machine one shared picture.
Decision boundaryDIAGNOSEThe scope of a causal decision graph: only the levers, externals, loops and outcomes needed for one choice. “Anything that does not change the decision stays outside.”
Decision leverDIAGNOSEA variable the decision maker controls directly, such as price, size, leverage or a budget. Levers sit on the left of the causal decision graph.
ExternalDIAGNOSEA condition that influences the outcome but is outside the decision maker's control, often fed by an AI prediction or expert estimate.
IntermediateDIAGNOSEA measurable event or milestone on the causal chain between action and outcome; a leading indicator (“the reasons”).
OutcomeDIAGNOSEA measurable end result on the right of the causal decision graph, against which goals are set (“the accountability”).
Feedback loopDIAGNOSEA reinforcing or balancing cycle in the causal decision graph, made explicit because “loops are where intuition fails most”.
Small world modelDIAGNOSEA scoped causal model of only what changes one decision. DeOSAlpha also uses small causal world models internally as simulators for a firm, sector or portfolio.
RegimeDIAGNOSEA continuous state of the world mapped onto a few explainable states, each with a probability, so that every later analysis is conditioned on these probabilities instead of one base case. Regimes are estimated at four scopes at once: global (the world: growth, rates, liquidity, risk appetite across markets), local (one market, region or sector), macro (the economic cycle: expansion, late cycle, contraction, recovery) and micro (the investable universe and the corporate lifecycle of each company: growth, maturity, stress, turnaround). Regime awareness is what lets the same causal model give different answers in different states.
Causal decompositionDIAGNOSESplitting every return, value or discount, per entity and point in time, into systemic beta, structural alpha and tactical alpha, contextually and non-linearly, with no fixed sensitivities and no fixed factor list.
Systemic betaDIAGNOSEThe part of return any owner of the exposure earns from broad forces such as rates, spreads, demand, liquidity and regime, with a sensitivity that depends on the asset's context. It can be bought cheaply or hedged; it should not be paid for as alpha.
Structural alphaDIAGNOSEReturn from persistent, idiosyncratic causal drivers such as pricing power, moat, management and capital allocation, gated by regime and earned over the medium to long term. It is what a manager is paid for.
Tactical alphaDIAGNOSEShort-lived effects from catalysts, momentum, flows and mispricings that decide the path, over days to quarters. It is worth chasing only if it survives costs, and a long-term holder may switch it off.
Context sets the sensitivityDIAGNOSEThe principle that the same shock, lever or synergy is worth different amounts depending on context (leverage, contracts, customers, regime), so sensitivities are learned per asset and context, never fixed.
Shared-driver exposureDIAGNOSEHoldings in different buckets that depend on the same underlying driver. The bucket view sees diversification; the driver view sees one bet.
Micro-factorsDIAGNOSEHundreds of fine-grained, contextual causal drivers on which exposure is measured, in place of a few flat style factors.
Causal driver treeDIAGNOSEThe explanation of a prediction or recommendation as a traceable tree of drivers, down to data points and expert inputs, so that debate moves from stories to assumptions.

04

Intelligence · Predict

8. Predicting and judging#

Terms used in the third step: how DeOS forecasts, simulates and combines human judgment with AI prediction, and how it treats uncertainty.

Counterfactual predictionPREDICTThe third component of every analysis, run on the Analysis capability. It splits into analysis step 3, probabilistic prediction and fusion (what will happen, and how sure are we?), and analysis step 4, counterfactual simulation (what could happen, and what would happen if we acted or a catalyst occurred?).
Probabilistic prediction and fusionPREDICTAnalysis step 3: the expected path as a calibrated distribution, from AI models and structured expert judgment fused by track record. Types include knowledge fusion, contextual returns, default prediction, fundamental and macro forecasting and catalyst prediction (likelihood and timing).
Counterfactual simulationPREDICTAnalysis step 4: the alternative paths that are possible (scenarios, tails, regimes) and the counterfactual of each action or catalyst. Types include stress testing, scenario simulation, ripple-through across levels and catalyst effect and impact.
CounterfactualPREDICTWhat would happen, or would have happened, had something been different. Used in two senses: alternative histories that did not happen, and the outcome of action A against action B. Counterfactuals separate luck from skill and test a decision before capital is committed.
Counterfactual world modelPREDICTA model that represents the full distribution of possible states and simulates joint paths at the level of each asset, keeping dependencies, fat tails, regime shifts and cash flows, under each action and scenario.
World modelPREDICTAn internal representation of how a system works: which causes drive which outcomes, how they interact, and how the system would respond to a decision. A good one is causal, counterfactual, separates uncertainty by type, takes human knowledge as input and knows when not to decide.
Calibrated distributionPREDICTThe form of every prediction in DeOS: a probability distribution with intervals whose stated probabilities hold over many cases, never a single point.
Path simulationPREDICTSimulating millions of joint paths in which drivers, exposures, regimes and exit conditions move together, in place of a bull, base and bear case.
Ripple propagationPREDICTCarrying an event at one entity (a rating change, a lost customer, an add-on) through shared drivers to peers, the universe and the portfolio, including second-order effects.
Zero-history evaluationPREDICTForecasting and valuing an entity with little or no history of its own (a new issue, a spin-off, a private company) from its characteristics, mechanics and peers.
Catalyst modelPREDICTA model that estimates, as separate questions, how likely an event or lever is, what its impact would be and how much of it is already priced in.
Priced-in checkPREDICTTesting whether a catalyst's or lever's impact is already reflected in the price, the seller's case or a bid before it counts toward a recommendation.
What-ifPREDICTA drill-down showing what would happen under other action values or external conditions, simulated on the causal decision graph.
Expert predictionPREDICTStructured expert judgments, given as ranges with confidence on precisely worded questions, and fused by calibration, track record and decisiveness. The aim is maximum knowledge aggregation with minimum error and bias.
Expert question cardPREDICTOne precisely worded question with horizon, answer format, panel, the base rate shown, and the rule by which it will be resolved.
Answer scalesPREDICTThe five scales an expert question is answered on, each point with a value, a label and a colour: probability (0% impossible to 100% almost certain); positive judgment (0 very poor to 10 exceptional, high is green); negative judgment (0 very low to 10 extremely high, high is red); confidence (5% almost no confidence to 100% certain); uncertainty (1% certain to 100% almost no confidence). Green supports the decision, amber is neither for nor against, red speaks against it.
Human knowledge as structured inputPREDICTJudgments, assumptions and preferences enter the model as data with their own uncertainty, rather than as comments on its output. Judgment can enter as evidence, as a view that reshapes the scenario distribution, or as a rule enforced exactly.
FusionPREDICTCombining human estimates and AI predictions, kept separate until the end, by weights earned on each source's track record in this context (for example 40% judgment, 60% prediction). The fused range is narrower than either, and all three are scored later.
Trust calibrationPREDICTTrusting an output, human or machine, as much as its track record in this context warrants: no blind reliance and no blanket rejection. The system learns when to rely on whom, and how much.
Human / AI splitHUMAN / AIWho does the work in each analysis: a human / AI mode set per component (in detail per analysis archetype) before the analysis runs, and then calibrated from outcomes. The decision itself, at policy level, always stays with the named decision owner.
Human / AI modesHUMAN / AIThe three ways a component can run: Automated, Augmented and Judgement only. Rule of thumb: automate what is high in volume and low in ambiguity; augment where expert knowledge is scarce in the data; keep judgement only where accountability, values or regulation require a person.
AutomatedHUMAN / AIDeOS runs the component end to end; people set it up, watch its quality and drift and handle exceptions. Typical for context scans, imputation, anomaly detection, forecasting at scale, simulation and explanation.
AugmentedHUMAN / AIDeOS proposes and quantifies; experts add structured judgments, challenge and adjust, and their input is fused with the model by calibration. Typical for ontology and modelling, peers, contextual valuation, causal rating, catalyst prediction and stress design.
Judgement onlyHUMAN / AIA person decides the component; DeOS supplies context and base rates and records the judgment with its probability and rationale, so it can be calibrated. Typical for mandate trade-offs and Selection criteria weights, scenario selection, the final Go / No-Go and overrides.
MetacognitionPREDICTKnowing what one knows. For the system: recognising when a situation is outside its experience, when confidence is not earned, and when to defer or wait. For experts: feedback on their own calibration, bias and decisiveness per context.
Three forms of uncertaintyPREDICTAleatoric uncertainty (chance) cannot be reduced, only sized. Epistemic uncertainty (ignorance) can be reduced by evidence, so the response is to learn before committing. Unknowable uncertainty (novelty) has no reliable probabilities, so the response is robustness, options and waiting. “The most expensive mistake is a category error.”
One historyPREDICTEvery dataset is one realized path among many that were possible. A model that learns only that path mistakes luck for structure, so decisions are judged across the histories that could have happened.
Pearl's ladder of causationPREDICTSeeing (association), doing (intervention) and imagining (counterfactuals). Every decision is an intervention on rung two; every honest review of a decision is a counterfactual on rung three. Most statistics, machine learning and language models stay on rung one.
ImaginationPREDICTUsing the world model to generate futures and alternative histories, and keeping those that are novel, learnable and useful or surprising as new decision-relevant data. Only real outcomes become evidence (“imagination with a firewall”).

05

Intelligence · Recommend

9. Recommending an action#

Terms used in the fourth step: how a recommendation is built, scored, explained and timed.

Contextual optimizationRECOMMENDThe fourth component of every analysis and analysis step 5, run on the Recommendation capability: searching the space of possible actions for the one that best serves the goals across the simulated futures, within the hard constraints, with trade-offs made explicit. It brings in the mandate and comes in the decision policy types Selection, policy optimization, Go / No-Go and monitoring; the component includes the explanation (step 6).
Recommend cascadeRECOMMENDThe order in which the decision policy types run in a policy's own Recommend step, each narrowing the action: Selection picks the options, policy optimization sets the terms, Go / No-Go decides whether to proceed on those terms against the threshold and stress limits, and monitoring sets what reopens the decision.
Decision recommendationRECOMMENDThe output of a decision policy. It answers what to do, how sure we are, why, and what would change the answer. Its nine components are decision level, conviction score, perspectives, options and ranking, goals, actions, causal decision graph, criteria and insights; the decision policy template specifies it by actions, options, optimization goal, decision criteria and insights.
Decision conviction scoreRECOMMENDThe probability, from 0 to 100%, that this is the right decision, given the mandate: the expected outcome on the optimization goal weighted by what matters to the mandate and adjusted for co-movement between the drivers. It fuses the decision criteria from every perspective. It is an overlay on the yes / no question and is not an expected return.
ConvictionRECOMMENDHow much the evidence supports acting: confidence that is earned, explained and updated. Labels on the probability scale: impossible (0%), exceptionally unlikely (5%), very unlikely (15%) and unlikely (30%) in red; somewhat unlikely (40%) and about even chance (59%) in amber; somewhat likely (70%), likely (85%), very likely (95%) and almost certain (100%) in green. Size should follow conviction, and conviction is calibrated against outcomes.
Decision perspectiveRECOMMENDA defined angle on the decision objective, each asking: from this angle, how likely is the objective met? The six standard perspectives are attractiveness, risk, fit, timing, execution and expert view. A perspective score is conviction, not a level (“Risk 64%” does not mean 64% risk).
Decision criterionRECOMMENDA standardized measure of conviction from one perspective: a criterion measure, a non-linear conversion to 0–100% conviction, an optional threshold and a plain-language label. Criteria can be historic, current or predicted, and fixed or dynamic business rules.
ThresholdRECOMMENDA limit that turns a criterion into a gate: below it, a decision cannot be recommended whatever the other criteria say. The policy threshold is the minimum probability of meeting the goals at which a policy recommends acting, for example 60%.
Decision optionRECOMMENDOne alternative course of action, analysed in full and given its own conviction. Waiting and passing are included where they are real options.
Decision rankingRECOMMENDOrdering options by probabilistic multi-criteria decision analysis (MCDA, the method of the Selection type), showing the probability that each option is best. The top-ranked option can still have low conviction.
Decision actionRECOMMENDA concrete setting to execute, such as price, size, leverage, hedge ratio or budget, each with its why, its effect on goals and its what-ifs. “Choosing a value for a lever is a choice; executing it is an action.”
Goal-based optimizationRECOMMENDFinding the action values that maximize the probability of meeting the goals within the constraints.
Decision lifecycle optimizationRECOMMENDOptimizing linked decisions such as entry, sizing, add, trim and exit together as one path.
Expected-value triggerRECOMMENDActing only when the expected benefit of an action clears its costs, slippage and forecast uncertainty; otherwise the recommendation is to wait. It replaces calendar rebalancing.
HurdleRECOMMENDTwo thresholds, kept apart by name. The return hurdle is the return a deal, sleeve or company must beat. The action hurdle is the threshold an action's expected benefit must clear, net of costs, slippage and forecast uncertainty: the expected-value trigger.
WaitRECOMMENDA valid, logged recommendation when the case for acting is not strong enough or the situation is outside the model's experience. Doing nothing is a legitimate output.
Target exposureRECOMMENDThe exposure a portfolio should have, stated as drivers, characteristics and behaviour rather than labels such as “more value” or a sector tilt, and derived from the mandate.
Replacement specificationRECOMMENDThe driver profile a substitute holding must have, used to find it in the universe map, so that “the exposure arrives with an address”.
Keep, substitute, exitRECOMMENDThe per-holding recommendation against the target exposure, with the replacement specification for each substitute.
Pareto frontierRECOMMENDThe set of efficient trade-offs between competing goals, such as return against drawdown, on which the decision maker chooses where to stand.
ExplanationRECOMMENDAnalysis step 6, part of the Contextual optimization component and logged by Governance: an account of a single prediction or recommendation. Attribution explains what drove it, response explains how it would change, and archetype explanations show what it looks like through reference cases. DeOS explains every prediction, not only the final recommendation.
InsightRECOMMENDA standardized observation about a metric, defined along five dimensions: temporal horizon, structural focus, measurement frame, dynamic trajectory and causal or systemic mechanism. Insights explain criteria and recommendations.
Concept and metricRECOMMENDA concept is a domain idea, such as profitability; a metric is one concrete measure of it, such as EBITDA margin. Policies refer to concepts so a metric can be swapped without breaking them.
Expectations to trackRECOMMENDThe signals and dates, recorded with each recommendation, that would confirm or break the thesis.
AI voteRECOMMENDAn independent, quantitative vote cast and recorded by the system alongside the committee's votes. Agreement raises confidence; disagreement yields a specific, traceable question before a loss. Who was right is tracked over time.

06

Platform

10. Platform, roles and technology#

Terms for the product, the people who use it and the technology underneath.

DeOSPRODUCTDecision Optimization System: vencortex's platform for decision optimization. It runs every decision end to end on a dedicated instance owned by the firm, across the five capabilities, and organises work as solutions, decision policies and analyses.
vencortexCOMPANYThe company behind DeOS and GEMs 3.0, written vencortex®. In delivery it supplies decision architects and the concierge service.
Decision infrastructurePRODUCTDeOS as the firm's own infrastructure on a dedicated instance: policies, context, models and decision memory belong to the firm, and its data never trains shared models. It learns “for you, not for the market”.
DeOS StudioPRODUCTThe visual, no-code canvas where decision architects and teams create and change solutions, decision policies and analyses from the decision assets, and publish them as reusable templates.
GuardrailsPRODUCTThe mandate, investment policy and rules encoded in DeOS so that every decision stays within them. They can block a submission while required inputs are open.
Decision memoryPRODUCTThe firm's point-in-time store of every decision with its context, inputs, recommendation, alternatives, approvals and outcome, including decisions not taken. It is owned by the firm, outlasts individuals and compounds with every cycle.
Decision recordPRODUCTThe frozen record of one decision: policy and version, recommendation, probabilities and threshold at the time, the final decision, overrides with reasons, expectations to track and, later, the outcome.
Audit trailPRODUCTThe logged lineage of every decision: drivers, data, analyses, model version, time, trigger, votes and overrides, so that anyone can replay why a decision was made.
OverridePRODUCTA human decision against a recommendation, rule or model, always recorded with its reason, scored against the outcome like any other call, and learned from.
The human decidesPRINCIPLEDeOS advises; people keep authority over every decision and every hand-off. Human control is a feature, not a concession: it keeps accountability where it belongs.
Decision architectROLEThe role that designs how the firm decides and builds policies, graphs and analyses in DeOS Studio, typically the CIO, with a firm-wide view of adherence and decision quality.
Decision makerROLEThe body that takes the decision on an explained recommendation: the investment committee, the board or the owner of the decision.
RecommenderROLEThe role that owns, adjusts or overrides the recommendation and records why, typically the portfolio manager.
AnalystROLEThe role that builds and challenges the context and adds judgment to predictions.
SponsorROLEThe executive who owns the decision optimization programme and its use-case portfolio and signs the first and last gates, such as the CIO, CEO or managing partner.
ObservabilityPRODUCTThe firm-wide view of every decision across funds: volumes, adherence, overrides, conviction against outcomes and policy quality.
Bayesian learningPRODUCTUpdating beliefs as evidence arrives, so every thesis is a hypothesis and every outcome a learning event.
Counterfactual learningPRODUCTLearning from options not taken and scenarios that did not occur, as well as from the path taken.
Interface layerTECHNOLOGYThe role DeOS gives language models: reading, retrieving, summarising and explaining, on top of the decision engine where the decision is computed. “A prompt is not a policy, a plausible answer is not an optimal one.”
Decision engineTECHNOLOGYThe layer where the decision is computed: causal, probabilistic, reproducible, auditable and built around the mandate and the firm's own data and judgment.
DeOSAlphaTECHNOLOGYThe decision engine at the core of DeOS. An optimizer built on a pretrained in-context learner, with dual memory, a generative world model, neurosymbolic controllers and an engine for the expected value of information. It chooses actions under uncertainty without retraining.
In-context learnerTECHNOLOGYOne pretrained, multimodal, multi-task model that solves new tasks from the context given at inference, zero-shot or from a few examples, without retraining. “Fitting is conditioning.”
Neurosymbolic coreTECHNOLOGYThe combination of learned models with explicit rules and causal structure, so hard constraints are enforced, not learned or prompted.
Generative world modelTECHNOLOGYDeOSAlpha's internal simulator, which rolls out synthetic trajectories, plans through them and stress- tests actions.
EVI engineTECHNOLOGYThe expected-value-of-information engine: it decides whether another evaluation is worth its cost and whether to act, try or wait.
Trust gateTECHNOLOGYThe rule that a new model, simulator or learned prior must agree with unseen outcomes before it is allowed to decide, and loses control when that record breaks.
StackingTECHNOLOGYBuilding analyses from tasks: the output of one task becomes the context of the next (extraction, representation, forecasting, optimization), and analyses stack into insights, recommendations and decisions.
Seventeen task typesTECHNOLOGYThe machine learning tasks the in-context learner solves, from classification and extraction to forecasting, survival, ranking and fusion. “No single task makes a decision.”
Fifteen capabilitiesTECHNOLOGYThe requirements for AI that decides under uncertainty, in three groups: seeing the world as it is, knowing itself, and deciding, learning and imagining.
Pseudo-reasoningTECHNOLOGYText that has the form of reasoning, produced by association with no causal model, calibrated distribution or search over actions. It is contrasted with computed reasoning.

07

Value and evaluation

11. Value, alpha and how decisions are judged#

Why decision optimization creates value, and how to tell a good decision from a lucky one.

The decision is the atomic unit of alphaTHESISEvery return is the end product of decisions, and data, research and models create value only when they change a decision. The decision, not the data point or signal, is where alpha is created and where it lasts.
Four families of inefficiencyThe structural inefficiencies that limit decision performance in every firm: governance (decisions judged by outcomes, logic in people's heads), information (noise, disconnected data, unseen alternatives), analysis (static, linear, correlational models) and behaviour (overload, bias, noise). Their common root is complexity, speed and uncertainty beyond human limits.
Four alphasThe value of decision optimization: each inefficiency, once solved, becomes a source of return. Governance alpha: the edge applied consistently, without drift. Information alpha: context beyond manual bandwidth and consensus. Analysis alpha: causal, forward-looking and simulated, not extrapolated. Behavioural alpha: calibrated, explained decisions that learn from every outcome. Together they compound.
Allocation, decision lifecycle and hand-off alphaAlpha underwritten at solution level rather than per decision: from allocating across all strategies (total portfolio), from connecting the decisions of a decision lifecycle, and from what passes between decisions.
Decision alphaAlpha from a better way of deciding. Unlike signal alpha it is causal, repeatable and specific to the firm, so it is not arbitraged away and compounds with every cycle.
Signal alphaAn information edge that decays once others find it, in contrast to decision alpha.
Fake alphaReturn paid for as alpha that a causal split shows to be systemic beta, such as sector momentum, the market multiple or leverage.
CompoundingEach decision improves the context, models and policies for the next, so all four alphas grow with every cycle.
Augmentation, not automationPRINCIPLEAI handles complexity and scale; people set strategy, add judgment and decide. Automation makes today's process faster; augmentation improves decision quality and answers questions that could not be asked before.
Outcome biasJudging the quality of a decision by the quality of its result. In investing, outcomes mix decision quality with luck, so firms that judge by results reward the lucky and punish the unlucky.
Decision qualityThe quality of the process that produced an outcome, judged against the probabilities the decision was made under rather than by the outcome alone. It is measured by calibration, policy adherence and conviction against outcome, and it separates skill from luck.
Decision quality matrixDecision quality set against outcome, giving four verdicts: earned success (good decision, good outcome), bad break (good decision, bad outcome), dumb luck (bad decision, good outcome) and just deserts (bad decision, bad outcome).
CalibrationWhether stated probabilities hold across many decisions: of the decisions labelled about 70%, did about seven in ten succeed? Calibration, not the single outcome, is what updates a policy. It applies to the system and to every human contributor.
Policy adherenceThe share of decisions made according to the policy; a process and decision-quality measure.
Levels of evaluationEvidence is planned at three levels: the analysis (checkable in weeks, by calibration and accuracy), the decision policy (months, by adherence, overrides, parallel run and backtest) and the solution, the decision lifecycle that makes a fund or strategy (years, by outcome separated from luck).
BenefitsThe six forms value takes, each with a metric and its own speed: efficiency, scale, coverage, effectiveness, experience and innovation. The buyer's guide's ten benefits and the workbook's twelve rows are measures under these six forms: speed under efficiency; risk reduction and decision quality under effectiveness; transparency and learning under experience; fundraising success under effectiveness and experience.
Subjective factorsValue felt by decision makers that a return series does not show: conviction, uncertainty awareness, explainability and auditability, customizability and trust in the output.
Proof of skillShowing skill in the recorded, explained decisions themselves, separated from luck, rather than only in a track record.
Human limitsWhat an analysis is built to overcome: bandwidth, memory, noise, bias and slow updating. The human limits paper groups them as bias, noise and bounded capacity.

08

Delivery

12. Delivery and adoption#

The vocabulary of the delivery framework: how a firm moves from its first engineered decision to a decision system.

Delivery frameworkvencortex's method for taking a firm “from its first engineered decision to a decision system”: maturity levels, phases, gates, use-case definition, alpha underwriting and proof. Its promise: value in days, scale without limits, zero risk.
Decision engineeringDesigning explicitly and reusably how a decision is made, beyond human limits. The decision policy is its main artefact; the delivery phase in which it is done is Engineering (phase 3).
Maturity levelsThe scope of what DeOS runs, entered at whichever level pays first: L1 decision governance; L2 analysis augmented; L3 single decision policy; L4 end-to-end decision lifecycle; L5 total portfolio approach. Each level has value of its own and reuses what was built before.
Total portfolio approachDeciding every position and strategy by its contribution to the whole portfolio against the mandate, across strategies, funds and asset classes, rather than within silos. It is maturity level L5 in the delivery framework and the allocator's lens in the segment papers.
Six phasesThe delivery path for each use case: 1 Discovery, 2 Audit, 3 Engineering, 4 Implementation / PoV, 5 Run, 6 Scaling. Gates follow Audit (G1 Discover), Implementation / PoV (G2 Prove), Run (G3 Realisation) and Scaling (G4 Scale). Durations are typical and set per engagement.
DiscoveryPHASE 1Which decisions are worth engineering? A maturity questionnaire and one sponsor workshop give a maturity profile, a long list scored with D · V · F · R at three levels, a potential and complexity map and a roadmap. No data leaves the firm.
AuditPHASE 2What does each decision cost today, and what could it earn? Two to three hours with each decision owner and read-only access to past decisions give the decision audit per use case: status quo, inefficiency diagnosis by the four alphas, augmentation and automation potential, and the underwritten alpha. No data leaves the firm. It ends at G1 Discover.
EngineeringPHASE 3How should this decision be made, beyond human limits? Working sessions with the decision owner and experts fill the solution, decision policy and analysis templates and build the causal decision graph and the data ontology, starting from the archetype directory. Design work only: nothing in the live process changes.
Implementation / PoVPHASE 4Does it work on a real decision? A dedicated instance is set up in days and the proof of value (PoV) runs over a few weeks of real decisions, live with the vencortex team or in parallel, with the live book untouched. It ends at G2 Prove with evidence on the client's own decisions.
RunPHASE 5Is it part of how we work? The decision owner and team use the use case day to day after a few hours of training; people decide and every override is recorded. It ends at G3 Realisation with the first value- realised review.
ScalingPHASE 6What next, and who builds it? The next use case starts from the decision assets, and the team learns to build in the no-code DeOS Studio. It ends at G4 Scale.
Gate“A decision about a decision”, with a question, required evidence and fixed outcomes. G1 Discover (after Audit) asks whether a decision is worth engineering; G2 Prove (after Implementation / PoV) asks whether it works on our own decisions; G3 Realisation (after Run) asks whether the underwritten alpha is delivered; G4 Scale (after Scaling) asks what to scale. Every gate can stop or park.
D · V · F · R scoringDesirability, viability, feasibility and risk, scored for each candidate at its own level: a solution, a decision policy or an analysis. D, V and F are scored 0 to 10, with risk and trust scored separately because they can veto. Potential is D + V; complexity is (10 − F) + R. An analysis reused by several policies counts its value in each; a red-line risk at any level blocks everything above it; the level landed sets the maturity entry (analysis L2, policy L3, solution L4 or L5).
Land the fruit, stage the moonshotsThe prioritisation principle: quick wins land first and fund and de-risk the ambitious use cases, which are staged through the maturity levels.
Alpha underwritingWriting expected benefits as equations with the client's own inputs before engineering, then comparing them with realized value at the realisation gate. “Never a fixed promise.”
Parallel runRunning a use case next to the existing process on the same decisions, without touching the live book, until it passes the prove gate. Its value is measured against the decision the old process would have made.
Entry modesThree ways to start: a live decision, fully serviced (a real pending decision run on DeOS by vencortex), a parallel run,oradecision portfolio (several use cases through the gates at once, where winners fund the next round).
Trust pathThe same three-step proof at every maturity level: backtest, parallel run, live capital, so that capital follows evidence.
Readiness checkPeople, process, technology and compliance, checked at every gate and marked ready, enable or blocked. “Defer and enable, never force.”
Proof layersThe evidence a use case must show: analysis, outcome, process and innovation, with trust and subjective factors added in the workbook.
Scale an analysis, decision policy or solutionThe three units of scale at the last gate: an analysis reused in other decisions, a policy rolled out to other teams, or decisions connected into a decision lifecycle or the total portfolio.
Maturity assessmentScoring a firm's decision foundation, in an investor version and an enterprise version of the same questionnaire, on six dimensions (decision governance, decision structure, context and data, prediction and judgment, learning and proof, scale and capability) in five stages from ad hoc to systemic. Each dimension is mapped to a part of the framework, stages 3 and 4 need evidence, and the result is a recommended entry level, not a ladder.
Decision heat mapFor each candidate decision, how each part is done today (governance, the four analysis components, learning) on a scale of not done, judgement only (unstructured or structured and recorded), augmented and automated. Part of the maturity assessment.
Concierge serviceOn-demand vencortex support while a use case runs and scales.

09

Use cases

13. Recurring terms in the use cases#

Analyses and outputs that recur across the use-case papers. They apply the framework to a domain and are defined here as the papers use them.

End-to-end intelligenceMODEThe core operating mode: DeOS supports each human decision in the existing process, and every hand-off stays a human decision.
End-to-end strategiesMODEThe optional operating mode: a systematic sleeve or programme runs under codified rules people set, such as a driver-neutral book, a synthetic theme index or a rules-based add-on pipeline.
Six capabilitiesThe engine components each use case presents: regimes, a decomposition, forecasting and ripple, catalyst models, exposure and where to find it, and timing.
Synthetic universe indexA benchmark built from what the mandate can actually own, used to test the thesis against the real opportunity set.
Universe mapEvery company placed by its drivers rather than its sector code, so that target exposures and replacements can be found.
Read-acrossWhen one deal, plan or campaign works, the companies most like it or most likely to respond to the same lever.
Contextual multipleWhat the market should pay for these characteristics and drivers; the gap to the market multiple is the mispricing.
True ROICReturn on invested capital with intangible investment capitalized, comparable across firms, alongside growth versus maintenance investment.
Value creation treeThe decomposition from return or shareholder value down to the operating drivers and levers that move it.
Value bridgeThe split of value creation into revenue growth, margin expansion, multiple expansion and debt paydown, each separated into what was created and what was ridden.
Created versus riddenSeparating value an owner or manager created from value the market, sector or leverage carried.
Value gapThe gap between intrinsic value and market value, split by cause, for example allocation, visibility, blending and systemic factors.
Discount diagnosisClassifying a discount as narrative, cyclical or structural, at screening and again while held.
Probability of mispricingThe probability that price sits below the intrinsic value distribution; the ranking metric that replaces “cheap on a ratio”.
Portfolio fitWhat a candidate adds to or duplicates in the portfolio, scored against the strategy's criteria and the other candidates.
Exit triggersNamed reasons monitored probabilistically: value realization, thesis breakdown, opportunity cost and analytical error.
Maximum premiumThe highest price at which a deal still meets the return hurdle with the required probability, computed from the simulated plan and not from a competing bid.
Lever mapThe operational levers available to an owner, each with its likelihood of success, difficulty and timing.
Integration capacityThe load on management and systems across a sequence of add-ons, treated as a binding constraint.
Entry thesisThe plan, structure and incentives stored as drivers at signing, used as the yardstick for every later board, add-on and exit decision.
Transmission chainThe six links from a theme to a price: structural driver, adoption, revenue pool, company capture, value creation, price.
HoldabilityWhether a position, usually a short, can be carried given borrow, squeeze risk and cost of carry.
Look-throughDecomposing every fund, sleeve and holding into the causal drivers it carries, and aggregating them.
Reference portfolioSimple, cheap index building blocks that serve as both the yardstick and the default implementation of a mandate.
Shared modelThe plan model left with management or the board so they can change any assumption and adopt it as their own.
Best-owner testWhether an owner still adds value that another owner would not; paired with the compounding test of returns on reinvested capital.

10

GEMs 3.0

14. Sovereign Infrastructure#

Terms from the GEMs 3.0 papers, which apply the same decision optimization approach to Sovereign Infrastructure.

GEMs 3.0vencortex's system and index family for Sovereign Infrastructure, “the decision optimization system that runs all three moves”: define the exposure, express it as an index family, observe it continuously.
Sovereign InfrastructureAn asset class defined by exposure to productive systems, not countries, and delivered as an index family that adapts to each mandate across public and private markets.
Productive systemThe unit of classification: what an asset does in the economy. There are ten under one ontology; country, currency and policy become risk factors, not buckets.
SI-CMCRSovereign Infrastructure Capital-Markets Conversion Ratio: the framework behind the SI market figures, measuring how much physical infrastructure stock is allocable in tradeable form.
Index familyOne universe, three expressions with increasing mandate alignment: the classical or thematic index, the personalized benchmark, and the optimal benchmark as an investable portfolio.
Four risk componentsTotal risk decomposed into structural alpha, cross-systemic productive risk, market beta and tactical alpha.
Deterministic engineThe non-probabilistic application of policy limits, statutory rules and mandate constraints before any analysis runs. “A hard constraint is never traded off.”
Continuous observabilityKeeping information, risk rating, pricing and exposure current for every asset, system and portfolio; the precondition for continuous allocation.
SandboxA programme for testing SI on one requirement before committing, in three levels (discover, prove, innovate) and an indicative ten-week cycle.

11

Concordance

15. Older terms and what to use now#

Names from earlier papers that the current framework replaces. Older papers remain valid; read their terms as the ones on the right.

Used in earlier papers Use now Where IT appears
Governance + Intelligence + Platform Strategy + Intelligence + Platform Short decision optimization paper
Governance (as the first pillar) Strategy Short decision optimization paper
Context (stage 1 of three) Perceive + Diagnose Use cases, credit, private equity, delivery framework
Causal diagnosis of context Diagnose Covers of the use-case papers
Scope context; Scope (step 1) Perceive context; Perceive Framework and consulting documents, earlier editions
Counterfactual world model(s) (stage) Predict Three-stage papers, World that didn't happen v1
Contextual optimization (stage) Recommend Three-stage papers
Multi-constraint optimisation Recommend (contextual optimization) CIO paper series
Diagnosis / Simulation / Optimization Diagnose / Predict / Recommend Private equity summary
Five architecture stages Four steps + Learning capability Technology papers
Perceive, Predict, Imagine, Search, Decide, Learn Perceive … Recommend, then Learning DeOSAlpha engine cycle
Govern, Connect, Predict, Recommend, Learn Governance, Context, Analysis, Recommendation, Learning Short paper loop
Prediction (platform capability) Analysis (capability) Platform papers and this glossary before October 2026
Context, Prediction (capabilities serving Diagnose) Diagnose runs on Analysis; Context runs Perceive Earlier glossary and platform papers
Five platform modules Five platform capabilities Platform paper
Context engineering (module) Context (capability) Platform paper
Decision (as a platform stage) Recommendation Credit paper comparison table
Four layers Five capabilities SI papers
Layer 1 / 2 / 3 Solution / Decision policy / Analysis Short paper
Three layers (solution, policy, analysis) Four levels: solution, decision policy, Earlier glossary, handbook analysis, analysis archetype Lifecycle; sequence (of decisions) Decision lifecycle Framework, handbook, workbook, buyer's guide before October 2026 Shared assets Decision assets Framework, ha Three layers (solution, policy, analysis) Four levels: solution, decision policy, analysis, analysis archetype Earlier glossary, handbook Lifecycle; sequence (of decisions) Decision lifecycle Framework, handbook, workbook, buyer's guide before October 2026 Shared assets Decision assets Framework, handbook, workbook, platform paper before October 2026 Analysis type Analysis archetype Framework, handbook, workbook before October 2026 Analysis archetype (by component) Analysis family Framework, handbook, workbook before October 2026 Meta use case Decision archetype Framework, handbook, workbook, catalogue before October 2026 Policy studio; no-code studio DeOS Studio Platform paper, handbook, workbook before October 2026 Regime tiers (economy, universe, portfolio; economic, sector, corporate) Regime scopes: global, local, macro, micro Use cases, technology paper before October 2026 Decision archetype (the four types) Decision policy type Handbook, workbook, earlier glossary Selection (archetype) MCDA Handbook, workbook, earlier glossary MCDA (as the name of the decision policy type) Selection; MCDA stays the name of the method All papers before October 2026 Optimization (archetype) Policy optimization Handbook, workbook, earlier glossary Go / no-go (archetype) Go / No-Go Handbook, workbook, earlier glossary Analysis archetypes (four, short paper) Decision policy types Short paper Automation levels: manual, augmented, automated Human / AI modes: judgement only, augmented, automated Technology papers, earlier glossary Analysis use case (Template A) Analysis template Workbook, delivery framework Decision use case (Template B) Decision policy template Workbook, delivery framework Solution use case (Template C) Solution template Workbook, delivery framework Six analysis archetypes (catalyst prediction … exit and review) Analysis families by component; analysis archetypes Delivery framework, workbook Decision audit / decision engineering (phase names) Audit / Engineering Delivery framework, workbook

(phase names)

Implementation (phase) Implementation / PoV Delivery framework, workbook Scale (phase) Scaling Delivery framework, workbook Scale a prediction Scale an analysis Delivery framework Decision lifecycle (four stages) Intelligence flow World that didn't happen Causal decision diagram Causal decision grap Implementation (phase) Implementation / PoV Delivery framework, workbook Scale (phase) Scaling Delivery framework, workbook Scale a prediction Scale an analysis Delivery framework Decision lifecycle (four stages) Intelligence flow World that didn't happen Causal decision diagram Causal decision graph World that didn't happen v1, Pratt
Decision Operating System Decision Optimization System Technology papers, body text Causal Decision Engine DeOS (decision engine) Credit paper titles Market beta Systemic beta SI papers Deserved success / Poetic justice Earned success / Just deserts Earlier buyer's guide and workbook editions Superi Decision Operating System Decision Optimization System Technology papers, body text Causal Decision Engine DeOS (decision engine) Credit paper titles Market beta Systemic beta SI papers Deserved success / Poetic justice Earned success / Just deserts Earlier buyer's guide and workbook editions Superior alpha Superior results CIO paper series Optimisation (UK spelling) Optimization CIO paper series, World that didn't happen

Conventions settled in this book#

Where the papers used one word for several things, or several words for one, this book settles on one convention. Each chapter applies it; older editions may still show the earlier wording.

Term

Convention and where IT applies

LevelsMaturity is written maturity level L1 to L5 (delivery framework, workbook, buyer's guide); the hierarchy is the four levels: solution, decision policy, analysis, analysis archetype (framework, handbook); levels of optimization are analysis, decision and decision lifecycle (handbook, buyer's guide); decision level is asset, assets or portfolio (handbook, workbook); the nested granularities of the use cases (universe, portfolio, company or issuer, asset) are tiers, not levels (technology paper, section 09). Maturity dimensions are scored on stages 1 to 5. The earlier automation levels are human / AI modes.
ArchetypeSolution archetypes, policy archetypes (a decision policy type plus a decision archetype), analysis archetypes and the eleven decision archetypes, across all chapters; the historic six are the six earlier delivery archetypes (delivery framework, chapter 09). The four decision policy types are never archetypes except in older-term notes.
Analysis and RecommendNouns name capabilities (Analysis, Recommendation), verbs name steps (Diagnose, Predict, Recommend); the capability is written Analysis (capability) only where the level of the hierarchy is also in play. Applies in every chapter.
MonitoringBoth a decision policy type (what should trigger action, and why did it differ?) and a mode of contextual optimization inside an analysis (triggers and thresholds), as Selection, policy optimization and Go / No-Go are. Applies in the framework, handbook and this glossary.
Decision maker and rolesFour decision roles: decision architect (typically the CIO or head of strategy; during an engagement vencortex acts as the first decision architect and hands over), decision maker (the investment committee, board or owner of the decision), recommender (portfolio manager, deal partner, analyst lead) and analyst. The portfolio manager recommends and decides only where the policy makes them the decision maker. The sponsor is a stakeholder role, distinct from the four. Applies in the platform paper, the solutions catalogue, the workbook and DeOSAlpha.
Conviction scoreThe probability that this is the right decision, given the mandate: the expected outcome on the optimization goal weighted by what matters to the mandate and adjusted for co-movement between the drivers; short form, the probability that this is the right decision. Applies in the handbook, the platform paper and the workbook.
BenefitsSix forms of benefit: efficiency, scale, coverage, effectiveness, experience, innovation (delivery framework). The buyer's guide's ten benefits and the workbook's twelve rows are measures under these forms: speed under efficiency; risk reduction and decision quality under effectiveness; transparency and learning under experience; fundraising success under effectiveness and experience.
HurdleReturn hurdle for the required return of a deal, sleeve or company; action hurdle for the threshold an action's expected benefit must clear (the expected-value trigger). A plain hurdle is avoided where it would be ambiguous. Applies in the use-case chapters, the handbook and the catalogue.
Total portfolio approachDeciding every position and strategy by its contribution to the whole portfolio against the mandate, rather than within silos. It is maturity level L5 in the delivery framework and the allocator's lens in the segment papers; the private equity papers' driver-level fund exposure is one instance of it.
Decision qualityMeasured by calibration, policy adherence and conviction against outcome, in every chapter that measures it; the decision quality matrix has the quadrants earned success, dumb luck, bad break and just deserts (full paper, buyer's guide, workbook).

Index

16. All terms, A to Z#

Numbers refer to sections.

A

Aggregation layer02
AI vote05
Allocation, decision lifecycle and hand-off alpha07
Alpha underwriting08
Analysis01
Analysis (capability)01
Analysis archetype01
Analysis components01
Analysis family02
Analysis template02
Analyst06
Answer scales04
Archetype directory02
Audit08
Audit trail06
Augmentation, not automation07
Augmented04
Automated04

B

Bayesian learning06
Benefits07
Best-owner test09

C

Calibrated distribution04
Calibration07
Catalyst model04
Causal decision graph03
Causal decomposition03
Causal diagnosis03
Causal driver tree03
Compounding07
Concept and metric05
Concierge service08
Constraint01
Context01
Context engineering03
Context generation03
Context graph03
Context scan03
Context sets the sensitivity03
Context, constraints and goals01
Contextual base rate03
Contextual multiple09
Contextual optimization05
Continuous observability10
Conviction05
Conviction test02
Core question and output02
Counterfactual04
Counterfactual learning06
Counterfactual prediction04
Counterfactual simulation04
Counterfactual world model04
Created versus ridden09

D

D · V · F · R scoring08
Data and source02
Decision02
Decision action05
Decision alpha07
Decision archetype02
Decision archetype profile02
Decision architect06
Decision assets02
Decision boundary03
Decision conviction score05
Decision criterion05
Decision engine06
Decision engineering08
Decision heat map08
Decision infrastructure06
Decision level02
Decision lever03
Decision lifecycle02
Decision lifecycle optimization05
Decision maker06
Decision map02
Decision memory06
Decision optimization01
Decision option05
Decision owner02
Decision perspective05
Decision point02
Decision policy01
Decision policy template02
Decision policy type02
Decision quality07
Decision quality matrix07
Decision ranking05
Decision recommendation05
Decision record06
Decision-centric data room03
Delivery framework08
DeOS06
DeOS instance02
DeOS Studio06
DeOSAlpha06
Deterministic engine10
Diagnose01
Discount diagnosis09
Discovery08

E

End-to-end decision policy01
End-to-end intelligence09
End-to-end strategies09
Engineering08
Entry modes08
Entry thesis09
EVI engine06
Exit triggers09
Expectations to track05
Expected-value trigger05
Expert prediction04
Expert question card04
Explanation05
External03

F

Fake alpha07
Feedback loop03
Fifteen capabilities06
Fine-grained peers03
Four alphas07
Four families of inefficiency07
Four risk components10
Four tiers02
Fusion04

G

Gate08
GEMs 3.010
Generative world model06
Go / No-Go02
Goal01
Goal-based optimization05
Governance01
Guardrails06

H

Hand-off02
Holdability09
Human / AI modes04
Human / AI split04
Human knowledge as structured input04
Human limits07
Hurdle05
Hybrid intelligence01

I

Imagination04
Implementation / PoV08
In-context learner06
Index family10
Insight05
Integration capacity09
Intelligence01
Intelligence flow01
Interface layer06
Intermediate03

J

Judgement only04

K

Keep, substitute, exit05

L

Land the fruit, stage the moonshots08
Learning01
Levels of evaluation07
Levels of optimization02
Lever map09
Look-through09

M

Main inefficiencies02
Main KPIs02
Mandate01
Maturity assessment08
Maturity levels08
Maximum premium09
Metacognition04
Micro-factors03
Monitoring02

N

Nesting rule02
Neurosymbolic core06

O

Objective02
Observability06
One history04
Ontology03
Outcome03
Outcome bias07
Override06

P

Parallel run08
Pareto frontier05
Path simulation04
Pearl's ladder of causation04
Perceive01
Perceive context03
Platform01
Point in time03
Policy adherence07
Policy optimization02
Portfolio fit09
Predict01
Priced-in check04
Probabilistic prediction and fusion04
Probability of mispricing09
Productive system10
Proof layers08
Proof of skill07
Pseudo-reasoning06

R

Read-across09
Readiness check08
Recommend01
Recommend cascade05
Recommendation01
Recommender06
Reference portfolio09
Regime03
Regulatory constraints02
Replacement specification05
Representation03
Ripple propagation04
Roadmap02
Root cause02
Run08

S

Sandbox10
Scale an analysis, decision policy or solution08
Scaling08
Selection02
Seventeen task types06
Shared model09
Shared-driver exposure03
SI-CMCR10
Signal alpha07
Six analysis steps01
Six capabilities09
Six phases08
Small world model03
Solution01
Solution template02
Solutions catalogue02
Sovereign Infrastructure10
Space03
Sponsor06
Stacking06
Stage02
Stakeholders02
Strategy01
Structural alpha03
Subjective factors07
Synthetic universe index09
Systemic beta03

T

Tactical alpha03
Target exposure05
Templates02
The decision is the atomic unit of alpha07
The human decides06
Three forms of uncertainty04
Threshold05
Total portfolio approach08
Transmission chain09
Treatment02
Trigger design02
True ROIC09
Trust calibration04
Trust gate06
Trust path08

U

Universe map09

V

Value bridge09
Value creation tree09
Value equation02
Value gap09
vencortex06

W

Wait05
What-if04
World model04

Z

Zero-history evaluation04

Compiled from the vencortex papers in the project library as of October 2026. Definitions paraphrase the papers; where they conflict, the framework of October 2026 applies.

← Consulting workbook

Decision optimization with DeOS · vencortex® – DeOS | Decision Optimization System. Converted from DeOS_Compendium_Light.pdf by scripts/pdf_to_markdown.py; built by scripts/build_book_site.py.