ROR Holding · Basel · v0

Resolving multilateral, sequential decisions.

An option-generation engine. ROR holds it; concrete projects spin out from it.

SYSTEM f : (Actors, Signals, Constraints, History) (Options, Commitments, Executions)
0layers
0modules
0feedback edges
0live project

Three layers.
Five modules.
Five feedback edges.

Each component is a pure function of its inputs plus its component state. Intermediate artefacts are cacheable, diffable, and reproducible given a fixed model version. Feedback is not optional — every upstream component subscribes to the change streams of those below.

iROR architecture diagram — three layers, five modules, five feedback edgesA layered diagram showing three horizontal layers (L1 Reality Structuring, L2 Decision Architecture, L3 Operationalisation) containing five modules: M1 Interest graph, M2 Option set generator, M3 Evaluator, M4 Process compiler, M5 Governance module. Solid arrows depict forward dataflow between modules and dashed warm-toned arrows depict five feedback edges flowing back upstream.L1 — REALITY STRUCTURINGL2 — DECISION ARCHITECTUREL3 — OPERATIONALISATIONM1Interest graphM2Option set generatorM3EvaluatorM4Process compilerM5Governance module12345

Five modules.
Each with an interface contract.

Internal implementations vary by domain. The interfaces do not. Because modules interact only through their declared interfaces, each can be reimplemented independently — a domain with mature utility elicitation may use a sophisticated M1 and a naïve M3; a domain with heavy simulation needs will invert that.

Module M1 L1

Interest graph

Structured representation of what each actor wants, trades off, and considers infeasible. Modelled as a weighted multigraph where nodes are actors, attributes, and goals, and edges encode preferences, trade-offs, and hard constraints. Interests are preserved in their native heterogeneity — never aggregated into a social welfare function.

input actor declarations, revealed behaviour, elicitation signals, priors
output versioned interest graph G_t, per-actor projections G_t|a
ops query(actor), slice(goal), diff(t1, t2), update(signal)
deps none — foundational
Module M2 L2

Option set generator

Constructs the space of feasible, executable configurations. Each option carries a feasibility witness and an explicit assumption set. Not a search returning a single optimum — a structured, filtered option space with guarantees about coverage and feasibility.

input G_t, constraint set C, generation policy π
output option set O_t = { (config, witness, assumptions) }
ops enumerate(π), filter(predicate), expand(option), invalidate(assumption)
deps M1, constraint solver, combinatorial generator
Module M3 L2

Evaluator

Scores each option against each actor's projection of the interest graph, under an explicit uncertainty model. Output is a per-actor evaluation vector with point estimates, confidence intervals, and sensitivity decompositions — never a single scalar collapsed across actors. Deterministic given a fixed (G_t, U_t, seed) triple.

input option o, interest graph G_t, uncertainty model U_t
output E(o) = { per_actor_score, confidence, sensitivity, risk_profile }
ops score(o), compare(o_a, o_b), stress_test(o, scenario)
deps M1, M2, simulation runtime (MC / Bayesian inference)
Module M4 L3

Process compiler

Compiles a selected option into an executable process — a directed acyclic graph of tasks with role assignments, checkpoints, preconditions, and escalation handlers. The module emits a specification; it does not execute. The specification is handed to an execution runtime and instrumented for observability.

input selected option o*, actor role map R
output process DAG P with tasks, checkpoints, triggers, escalations
ops compile(o*), validate(P), trace(P, event_log)
deps M2, M1
Module M5 L3

Governance module

Installs the incentive and commitment scheme that makes the process durable under self-interested behaviour. Emits a versioned policy object specifying opt-in thresholds, penalty functions, reward contingencies, disclosure requirements, reversibility rules. Ratification is an explicit state transition producing a verifiable commitment record.

input process P, evaluations E, actor commitment signals
output policy object Π, ratified commitment C, audit log A
ops ratify(Π), adjust(event), audit(C), revoke(C, trigger)
deps M4, M3, M1
Projects · From the engine

The first options it produced.

ROR is a holding. Each option the engine produces becomes its own company; investors who resonate co-invest at that point.

01 / Health & affect live

Smile

The first option the engine produced. A coordination layer for what makes people smile — running, shipped at smileyou.ch.

smileyou.ch →
02 / Coordination coming

Crew Up

A second option, queued. Shape: coordination primitives for ad-hoc small groups.

In construction
03 / Reference architecture coming

iROR

The engine itself, exposed as a reference implementation. The architecture this page describes.

In construction
01 / Healthcare

Coordinated patient pathways

Cross-clinic, cross-payer decisions where each actor holds a different fragment of the situation and no shared schema exists.

02 / Capital

Stakeholder allocation

Capital deployments with multiple principals, each with distinct utility functions, risk tolerances, and governance constraints.

03 / Infrastructure

Consortium projects

Multi-party infrastructure where participation, contribution, and benefit must be ratified across heterogeneous actors.

04 / Cross-org

Planning across boundaries

Joint planning where the artefacts produced by each organisation's tools never share a schema, and the pipeline never closes.

None of these fields is weak on its own. The engineering gap is that they are almost never composed.

Each module resolves to existing, validated engineering and mathematical primitives. The architecture adds the composition discipline; it does not invent the primitives.

M1
Interest graph
Expected utility theory · multi-attribute utility · revealed preference · prospect theory · probabilistic graphical models
M2
Option set generator
Constraint satisfaction · combinatorial search · Pareto optimisation · dynamic programming · state-space modelling
M3
Evaluator
Bayesian inference · Monte Carlo simulation · sensitivity analysis · stochastic modelling · risk-management frameworks
M4
Process compiler
Process calculus · Petri nets · workflow modelling · multi-agent coordination · distributed consensus protocols
M5
Governance module
Mechanism design · contract theory · principal-agent theory · transaction-cost economics · institutional design for common-pool systems
Signal · v0

If you back option-generation engines, leave a trace.

This page is a signal test. We're measuring whether investors who fund engines — not single bets — find the shape here legible. Nothing automated happens after you submit. Christian reads every signal himself, and replies only where a real fit shows up. No deck attached, no pitch follow-up sequence.

No list. No automation. Just a signal.

The claim is narrow and engineering-shaped. Multilateral decisions can be engineered as systems — with explicit interfaces, versioned state, observable artefacts, defined feedback loops, reproducible runs.

This engine has produced its first option: Smile, live. The next options are queued. If the architecture resonates, the projects are where capital meets it.

Where that discipline is applied, decision throughput rises and dormant potential becomes addressable. Where it is not, no amount of capital, talent, or goodwill closes the gap, because the gap is structural.