Khouri is a standalone engine for agentic scenario planning, owning the workflow that turns uncertainty into structured artifacts. Its core runs Causal Layered Analysis in reverse: decomposing text into CLA layers and reporting gaps deepest-first.
Khouri
Khouri (GSV-E3) is a standalone engine for agentic scenario planning, part of General Systems Ventures' autonomous-agents domain. It provides the generic machinery for turning uncertainty into structured planning artifacts — decomposition, ontology matching, causal-graph construction, gap detection, hypothesis generation, and forecast synthesis — while deliberately leaving domain ontology, scenario families, and issue conventions to downstream adapters. This separation is the core design decision: adapter projects keep their worldview, Khouri keeps the workflow, so the planning capability is reusable across domains rather than bound to one project's assumptions. The real mechanism is Causal Layered Analysis (CLA) run in reverse. Standard CLA names four layers of a problem, from surface to depth: litany (observable events), social causes, discourse and worldview, and myth and metaphor. Khouri's implemented six-stage pipeline — decompose, match, compare, check, probe, synthesize — assigns raw text about a future state to those four layers, maps them onto an adapter-supplied simulation ontology, builds a typed causal graph over the result, and checks that graph for gaps: missing data, missing causal links, absent discourse frames, unmodeled narrative archetypes, worldview conflicts, and ontology mismatches. Each detected gap is then probed with causal hypotheses before the pipeline synthesizes a structured forecast. CLA layer provenance is carried through the pipeline, so outputs trace back to which layer of the original scenario text generated them. Khouri was extracted from shadow-work, the project whose worldview-specific scenario-planning needs first proved this pipeline was a reusable capability rather than a bespoke feature — shadow-work remains a downstream adapter and the clearest example of the domain-ontology/engine split the architecture enforces. As of the current designation, the six-stage pipeline is described as implemented; the public body does not enumerate additional adapters beyond shadow-work or report deployment-scale metrics, so status here is limited to what is stated: a working core pipeline with one known adapter relationship.