Decisions Nobody Anticipated: Running and Checking Declared Knowledge with a General Reasoning Engine

Most decision-making software answers the questions its authors anticipated; the authors decide how those questions are answered and what the answers say about their grounds. In practice, however, decisions also depend on things that are hard to state as quantities: experience that holds with exceptions, how particular people tend to act, rules that must be kept alongside lessons that only advise, and reports nobody has checked. MINOS is a minimal ontology of systems: it identifies within any system what drives it, what constrains it and how the system holds the two together. Two earlier papers introduced MINOS and showed that a system described in this way can be reasoned about. We examine whether a single MINOS description can support decisions that involve all of these kinds of knowledge. Our test case is one everyday situation. A walker wants to reach a mountain hut before dark. There are cliffs she cannot cross and a private field with a No entry sign, which she can cross only at a declared price. A farmer usually lets walkers cross his field in a storm, unless his ewes are lambing. Walkers new to the mountains tend to turn back when the light goes; a passer-by says this walker is new to the mountains, and nobody has checked. Nobody knows whether the bridge on the long way round is open. We express this situation in the terms of MINOS, write no program to answer questions about it, and put fifteen questions to the description: which way she should go, whether she is likely to turn back, whether a route meets a standard she has declared, naming what counts as success and what counts as disaster. Each answer identifies any rule it breaks and the price, any lesson it relies on and how well established that lesson is, and any report it accepts on trust. Where something is unknown, the answer says what would settle it. We compare these answers with those produced by established methods, examining what each method requires and how it reports the grounds for its answers. We also put to the same description two sets of questions written by language-model agents that had not seen it. About two in three were answered or rightly declined unchanged as scored, and about half of the first set under a stricter count; an established method, encoded with care, did better on the second set, and the kinds of question the description lacks are named. Finally, we ask who should decide what counts as a good answer. In most software, a programmer settles the matter in advance. We propose that whoever holds the goal should declare the standard and that the answer should name it.