KISS-Knowledge-Infrastructure-for-Scientific-Simulation README

The project's README from github.com/lzwei196/KISS-Knowledge-Infrastructure-for-Scientific-Simulation. As one markdown file: README.md.

KISS — Knowledge Infrastructure for Scientific Simulation

An agent-actionable scaffold that externalizes operational expertise so AI agents can reliably run, check, and extend process-based scientific models.

119 evaluated KI packages 14 Earth-science domains 3,000 benchmark trials MIT License

Explore the live catalogue · Build KI with KDT · Read the paper

Knowledge dissection converts model source code, documentation, examples, and datasets into a Knowledge Infrastructure package with three layers: validated modelling operators, staged domain protocols, and diagnostic recovery mechanisms. An agent uses these layers to constrain actions, check plausibility, and recover from failures.

Knowledge dissection converts operational expertise into agent-usable Knowledge Infrastructure. Figure 2 from the KISS manuscript.

What is Knowledge Infrastructure?

Running a scientific model requires more than knowing its equations. Practitioners also know how to prepare model-specific inputs, how to decide whether each intermediate state is scientifically plausible, and how to recover when a run fails silently or indirectly. That operational expertise is often scattered across source code, documentation, example cases, and specialist practice.

Knowledge Infrastructure (KI) makes that expertise explicit and usable by a general-purpose coding agent. It separates operational knowledge into three complementary forms:

Knowledge type The question it answers Representation in KI Role during execution
Procedural How should this operation be performed? Validated modelling operators Constrain actions through deterministic tools for format conversion, unit handling, dependency resolution, and execution
Evaluative Is the workflow still correct and scientifically plausible? Staged domain protocols Gate progress using spatial and temporal consistency, physical bounds, mass balance, parameter ranges, and output checks
Diagnostic Why did the run fail, and how should it recover? Diagnostic recovery mechanisms Map symptoms to diagnoses and validated remedies, then repair and rerun

Reliable simulation emerges when an execution path satisfies all three constraints. Without procedural knowledge, agents perform invalid operations. Without evaluative knowledge, erroneous states propagate. Without diagnostic knowledge, agents cannot recover from silent or indirect failures.

From tacit expertise to an executable scaffold

The Knowledge Dissection Toolkit (KDT) extracts operational expertise from model source code, documentation, examples, datasets, and expert practice. It packages that expertise as a self-contained KI that an agent can:

KISS leaves the governing equations untouched. The agent operates the original process-based model; KI changes the operational interface around it.

Model sources ── knowledge dissection ──► KI package ── agent execution ──► valid or repaired simulation
                                               │
                         ┌─────────────────────┼─────────────────────┐
                         │                     │                     │
                    Procedural            Evaluative            Diagnostic
                  constrain action      check plausibility      recover & repair

What this resource provides

The paper introduces four connected resources:

  1. The KI design — a three-layer scaffold for procedural, evaluative, and diagnostic knowledge.
  2. KDT — a knowledge-dissection toolkit for building KI packages for new models.
  3. An agent-driven simulation benchmark — a depth test of KI on a coupled VIC–Lohmann hydrological workflow.
  4. A public catalogue — 119 evaluated KI packages spanning 14 Earth-science domains, operated through a common interface.

This repository contains the model-level knowledge artifacts. The frozen cohort reported in the manuscript comprises:

Construction mode KI packages Validation depth
Hand-built depth test 2 VIC and Lohmann routing; evaluated in the 3,000-trial benchmark
Expert-supervised KDT transfer set 25 Three sites per model and three independent agent sessions per site
Fully autonomous KDT scaling set 92 59 observation-validated; 33 verified runnable on synthetic, example, or analytical inputs
Total evaluated in the paper 119 14 Earth-science domains

The repository may evolve beyond the frozen manuscript cohort. All study-scale numbers in this README refer to the 119-package evaluation reported in the paper.

What a KI package contains

Package layouts vary with the underlying model, but the artifacts serve the same three knowledge layers:

models/<MODEL>/
├── SKILL.md or SKILL_en.md          # operational entry point and staged guidance
├── tools/ and stage scripts         # validated modelling operators
├── dag.yaml                         # execution order, dependencies, and gates
├── knowledge_infrastructure.yaml    # machine-readable KI manifest
├── docs/
│   ├── format_spec.yaml             # input/output schemas and units
│   ├── validation_convention.yaml   # domain-appropriate acceptance rules, where available
│   └── REFERENCES.md                # provenance for operational claims
├── diagnostics/
│   └── triplets.yaml or triplets.md # symptom → diagnosis → remedy knowledge
└── preflight_check.py               # pre-execution consistency checks
KI layer Typical repository artifacts
Validated modelling operators tools/*.py, preparation stages, run and scoring scripts
Staged domain protocols SKILL.md, dag.yaml, format_spec.yaml, validation conventions, preflight checks
Diagnostic recovery mechanisms diagnostics/triplets.yaml, error logs, symptom–diagnosis–remedy records

Evidence from the paper

Depth: KI enables reliable agentic simulation

The depth benchmark tested a coupled VIC–Lohmann workflow with 14 milestones. Ten command-line coding agents from five independent platforms attempted the workflow across three Huai River basins in 3,000 independent trials.

Scale: KI construction transfers across models and domains

Structure: operational expertise converges

The cross-domain corpus supports the paper's central premise that operational expertise is structured and extractable rather than ad hoc:

Installation

Three ways in, depending on what you want to do.

1. The desktop application — no Python required

GeoForge Desktop runs these packages with an agent on your own machine. Download it from releases: everything travels inside the download, including all the model packages.

The manual walks one model from project creation to calibration, in English, 简体中文 or bilingual.

2. The library and harness — to drive a KI from your own code

For pointing your own agent at a package. Python 3.8 or newer; the clone is about 145 MB.

git clone https://github.com/lzwei196/KISS---Knowledge-Infrastructure-for-Scientific-Simulation.git
cd KISS---Knowledge-Infrastructure-for-Scientific-Simulation

pip install -e ki_tools_common/     # the shared library, and the KI harness

# the interpreter the harness runs a package's operators and preflight with
export HC_PROJECT_PYTHON="$(which python)"

Set HC_PROJECT_PYTHON before importing, not after — the harness reads it once at import time. Left unset, tool_command() emits an unresolved placeholder and run_preflight() raises FileNotFoundError trying to execute it.

Or nothing at all. The harness imports only the standard library — the numpy requirement comes from the rest of the shared library, which the harness does not use. To skip the install, load the module directly:

import sys; sys.path.insert(0, "ki_tools_common/ki_tools_common/harness")
import ki_harness

Everything below works the same way; read ki_harness.contract for harness.contract.

3. The command line — to inspect and install packages

Python 3.11 or newer.

pip install -e kiss/

kiss list                # the 127 packages
kiss info SWAT_Plus      # what one model needs
kiss papers WRF_Hydro    # the literature behind it
kiss verify              # what actually runs on this machine

Installing kiss/ does not give you the harness; the two are separate installs. Run both lines if you want both.

Usage — driving a KI with an agent

from pathlib import Path
from ki_tools_common import harness

contract = harness.contract(Path("models/VIC").resolve(), execute=True)

Put contract in the agent's system prompt. That is the integration — the same call works for every package in models/, and the agent receives the model's staged protocol, its operators as absolute commands, its diagnostic knowledge, and the obligations that govern how it may report a result.

Model binaries and large forcing or observational datasets are not bundled uniformly with every package. harness.run_preflight(ki) reports what is missing before a run rather than during one — it executes the package's own preflight script with HC_PROJECT_PYTHON, so set that first.

Reading a package by hand

The same knowledge is plain files, if you would rather look first:

ls models/                                  # the available packages
sed -n '1,160p' models/VIC/SKILL_en.md      # the operational entry point
find models/VIC -maxdepth 2 -type f | sort  # operators, protocols, diagnostics

Driving a KI with your own agent — the KI harness

contract() is the whole entry point, shown above. The rest of this section is what it puts in front of the agent, and the calls that surround it.

Why a shared contract

The instructions for using a KI were originally written twice — once in an interactive application, once in an automated improvement loop — and the two drifted. One kept its rules in a branch table, where 29 of them sat in a branch that most runs never reached, and its per-package review gate covered 3 of 458 packages. The other embedded a single block that could not be partially applied.

The design follows from that: a rule placed at a junction is skipped by whoever takes the other road, so the harness is a single function every caller passes through, with no branch on which caller is asking.

The obligations it carries

contract() renders a package's operational documentation as ten obligations, held as a registry in ki_harness.py rather than as prose, so a parity test fails if any driver stops emitting one:

Run the real model no toy substitute, no literature value reported as a result
Follow the protocol in order the staged protocol is a sequence, not a menu
Absolute tool paths run operators with the project interpreter — do not search, do not disk-glob
Know the outputs establish what the model produces before running it
Units from the files read them from each file's own attributes, never from documentation
Preflight first check the environment, and obey the result
Failure ladder diagnostic triplets, then documentation, then reasoning — in that order
Never weaken do not relax a tool or a gate to obtain a pass
Not your own judge verdicts belong to the caller, not the agent under test
Evidence series write the simulated series to CSV so the result is reproducible

The rest of the interface

ki = Path("models/MODFLOW6").resolve()

m = harness.manifest(ki)          # what this package actually ships
m["artifacts"]                    # {'SKILL.md': True, 'dag.yaml': True, ...}
m["missing"]                      # [] — stated up front, not discovered mid-run
m["tools"]                        # 30 operator scripts for MODFLOW 6

harness.tool_command(ki, "tools/calib_run.py")
# '/usr/bin/python3 /abs/path/models/MODFLOW6/tools/calib_run.py'

harness.run_preflight(ki, timeout=60)
# {'report': ..., 'returncode': 1, 'raw_tail': ...}

harness.assert_injected(prompt)   # raises unless the prompt carries the contract

Two of these refuse rather than guess. tool_command() raises KiHarnessError for an operator that does not exist, because a fabricated path fails later and less legibly. assert_injected() is the conformance hook: it raises unless the prompt carries the [KI HARNESS v1] marker, so a spawn site that bypassed the contract fails immediately rather than producing plausible unguided work. Wire it into your own runner and the same guarantee holds there.

HC_PROJECT_PYTHON interpreter used by tool_command() and run_preflight(); set it to your project environment
KI_HARNESS_FULL=1 adds the run-time attention digest: dependency-graph caveats, format specification, leading diagnostic triplets

Resolving a package by model name

A directory name is not always the model identifier: 8 of the packages here differ, with SWAT+ in SWAT_Plus, HEC-RAS in HEC_RAS, Noah-MP in Noah_MP. resolve_ki_path() consults a database that this repository does not distribute and refuses to guess without it, so resolve names against the catalogue instead, which handles the same spellings and reports ambiguity rather than selecting one:

from kiss_cli.catalog import Catalog
ki = Catalog.discover().get("SWAT+").root

Repository layout

.
├── README.md
├── models/                          # model-specific KI packages
├── ki_tools_common/                 # shared helper library + the KI harness
├── kiss/                            # the desktop application and its engine
├── docs/manual/                     # desktop application manual (EN / 中文 / bilingual)
├── CLAUDE_TEMPLATE.md               # reusable agent instruction template
├── AGENT_SERVICE_GUIDE.md           # agent-service deployment examples
├── DEPLOYMENT.md                    # infrastructure setup notes
└── revalidation_3x3_results.xlsx    # expert-supervised validation record

Citation

If you use KISS or its KI packages, please cite:

@article{li2026kiss,
  title         = {KISS - Knowledge Infrastructure for Scientific Simulation: A Scaffolding for Agentic Earth Science},
  author        = {Li, Ziwei and Zhu, Liujun and Liu, Yuchen and Zhao, Yichen and Li, Birk and Wu, Ruiqi and Jin, Junliang and Zhang, Jianyun},
  journal       = {arXiv preprint arXiv:2605.17856},
  year          = {2026},
  eprint        = {2605.17856},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2605.17856}
}

License

Released under the MIT License. Copyright © 2026 Jianyun Zhang Research Group, Hohai University.

KISS-Knowledge-Infrastructure-for-Scientific-Simulation (lzwei196/KISS-Knowledge-Infrastructure-for-Scientific-Simulation)

Searching Database…

这是什么?KISS 是一个知识基础设施(KI)框架,把运行科学仿真模型背后的操作经验——如何准备输入、判断结果在物理上是否合理、以及如何从故障中恢复——打包起来,让 AI 编码代理能够可靠地运行这些模型,而不只是知道它们的方程。
这是 Python 库,还是数据包集合?两者都是:Python 驱动库“kiharness”向 AI 代理提供标准化契约,而包含 119 个“KI 包”的目录——每个模型一个文件夹,内含工具、分阶段协议和诊断数据——正是驱动库所驱动的对象。模型本身的控制方程保持原样不动。
怎么让它跑起来?三种方式:从 releases 下载“GeoForge Desktop”,获得捆绑了所有模型包的免 Python 安装;克隆本仓库(约 145MB),通过 kiharness 库用自己的代理代码驱动某个包;或者单独安装“kiss/”包,通过 CLI 检查和安装各个 KI 包。
需要 Python 吗?需要哪个版本?驱动库需要 Python 3.8+,且只导入标准库(numpy 仅共享库的其他部分需要)。单独的“kiss/”CLI 需要 Python 3.11+,而且必须在导入驱动库之前设置 HCPROJECTPYTHON 环境变量,不能在其后。
设置环境变量这件事有什么坑?如果 HCPROJECTPYTHON 没有设置,toolcommand() 会静默输出一个未解析的占位符,runpreflight() 则在尝试执行它时抛出 FileNotFoundError;此外,代理的提示词必须带有“[KI HARNESS v1]”标记,否则 assertinjected() 会拒绝运行。
它面向哪些人?面向构建能运行基于过程的科学模型(目前聚焦于水文学等地球科学领域)的 AI 代理的研究人员和开发者,他们需要代理可靠地处理输入、合理性检查和故障恢复。
KI 究竟能把代理的可靠性提升多少?在一个基于 VIC-Lohmann 耦合水文工作流、共 3,000 次试验的基准测试中,配备 KI 的代理最多在 84% 的试验中完成了有效的端到端运行,而未配备 KI 的代理完成率从未超过 40%。
KI 包内部的三个知识层是什么?程序性知识(经过验证的建模算子)、评估性知识(检查科学合理性的分阶段领域协议)和诊断性知识(针对失败运行的症状到补救的恢复机制)。
模型目录有多大?横跨 14 个地球科学领域的 119 个经过评估的 KI 包:2 个手工构建的深度测试包,25 个通过专家监督的 KDT 迁移构建,92 个通过 KDT 工具包完全自主构建。
模型二进制文件和数据集包含在内吗?并非一概包含——模型二进制文件以及大型驱动或观测数据集并不是每个包都捆绑,因此有些环境需要你自行提供数据。
Creator
lzwei196
Size
214.7 MB
Stars
40
Age
6mo
Commits · 90 Days