Method

How expert judgment becomes operational

Most strategic analysis is trapped in decks, frameworks, and expert judgment — hard to reuse, hard to operate, and slow to turn into action. The tools in this portfolio take a different approach: decompose the problem, formalize the judgment into testable rules, and ship something someone can actually operate.

Evidence and provenance

Inspectable

The portfolio lets you inspect the inputs, rules, outputs, and interaction design. That is the capability evidence.

Illustrative

Each comparison starts with a decision contrast, then uses constructed inputs to make that contrast inspectable. Cutoffs and weights are modelling assumptions, with a stated rationale and sensitivity; they are not empirical market standards.

Not claimed

These personal tools do not represent client data, employer deployment, user adoption, or realised business results.

The process

Decompose

Break the domain into its core variables, actors, and failure modes. Map how value flows, where it leaks, and which forces shape outcomes.

Output: A structural map of the domain — the components that matter and how they interact.

See it → Issuer P&L

Formalize

Convert structural patterns into explicit decision rules. Each rule has a condition, a threshold, and a consequence — pass, warning, or fail.

Output: A rule set that turns qualitative judgment into testable, repeatable logic.

See it → Co-Brand

Calibrate

Choose the decision contrast first. Build the example inputs from explicit arithmetic or declared scenario conditions. Explain retained cutoffs as working assumptions and test nearby values; cite a public source for any empirical claim.

Output: Traceable assumptions, explicit thresholds, and scenarios that make sensitivity visible.

See it → Conversion

Ship

Build the system into an interface designed for quick orientation. Inputs can be adjusted, rules can be traced, and outputs can be reviewed in one place.

Output: An interactive tool with inspectable inputs, rules, and outputs.

See it → SME Payments

Analytical perspectives behind the tools

Every domain has structural forces that shape outcomes. The question is whether you see them systematically or catch them ad hoc. Each Logica tool is built on a structured set of analytical perspectives — ways of looking at a domain that surface different kinds of insight.

The analytical operating system uses a set of structured perspectives to decompose complexity into usable decision systems.

Structure

What are the core components, and where does value leak?

Before you can diagnose anything, you need to see the machine. Structural analysis decomposes a domain into its fundamental components — revenue lines, cost drivers, flow paths — and maps how they interact. Most strategic errors start here: people optimize a component without seeing how it connects to the rest of the system.

The Issuer P&L tool screens interchange, rewards, revolving, fees, activation, credit losses and capital returns. Its seven rules flag questions to investigate; two rules sharing activation data are related signals, not two independent causes.

Tool 01 → Issuer P&L

Readiness & transition

What must be true before a system change creates value rather than destroys it?

A viable objective can still lack the conditions needed for execution. Readiness analysis checks approvals, systems, operations and schedule buffers before stronger scores elsewhere can obscure an unresolved prerequisite.

The Conversion tool uses seven checks: timeline, strategy and segmentation, IT and data, fulfilment, compliance, attrition and early activation. Compliance approval and consent/list verification come first; support scope is planned separately by size.

Tool 03 → Conversion

Power & incentives

Who captures value, and how does control shift across the system?

In any multi-player system, margins don't just compress — they migrate. Power analysis tracks where value concentrates, which players have leverage, and what structural shifts are redistributing economics. In acquiring, the question isn't whether margins are thin — it's whether the business controls enough of the value chain to survive when they get thinner.

Tool 04 → Acquiring

Product-market architecture

Does the product architecture match observable customer and operating behaviour?

A product can have every feature and still miss the market. Architecture analysis tests whether the product's structure — what it bundles, how it engages, what makes it stick — aligns with the buyer's actual workflow and decision patterns. In SME payments, the gap between "payment card" and "operating system" is the gap between commodity and defensibility.

Tool 05 → SME Payments

Design principles

Inspectable inputs and assumptions

Decision inputs can be adjusted. Rule thresholds, formulas and assumptions are documented so the user can inspect what drives a result.

Prerequisites before ranking

Named rules expose constraints. Where weighted scores compare opportunities, unresolved prerequisites still block the corresponding recommendation; other high scores cannot cancel them.

Every input must change an output

Each decision input affects a rule or calculation. Pure context is labelled explicitly; it must not appear to provide evidence the model never evaluates.

Proxies are acknowledged, not hidden

A factual claim needs a traceable source. A modelling assumption needs a stated purpose and a sensitivity check. Keep both visible; absence of a citation does not establish originality or empirical validity.

Designed for quick orientation

A first-time visitor should be able to find the purpose, inputs, rules, and outputs in one interface, with deeper assumptions available for inspection.

Beyond payments

Payments was the starting point: six tools apply the same diagnostic architecture within one domain. The marketplace diagnostic is a seventh, cross-domain example. This repetition demonstrates how the structure transfers; it does not claim client validation or adoption.

← Browse the tools