decide, Decisions

A decide declares an open choice: this twin must pick one of an enumerated set of options, usually by a deadline. It is the fourth of the five speech-act kinds (The Five Axioms), and it is also the one construct in the language whose completion the engine is forbidden to perform.

Syntax

From spec §5:

decide      = "decide" fact "among" "{" value { "," value } "}"
              [ "by" instant ] ;

The example from spec §4.5, verbatim:

decide venue(dinner) among { verde, banh-mi-house } by 18:00

Semantics

Spec §3 gives decide a dual role in the engine:

  • Gap generator. An open decision implies missing inputs: it generates gaps for each option's unevaluated consequences. Demand radiates from an unresolved choice.
  • Assertion emitter. Upon resolution, the decision emits an assertion: the chosen value becomes a hold, and from that moment it is ordinary supply that can flow to any counterparty whose seek matches and whose membrane passage is granted.

Between declaration and resolution, the decide simply stands open. Nothing in the mesh can force it closed.

Resolution: injected human judgment

Who closes it, then? A human, always, and only a human. In v0.1 a resolution arrives on the command line:

python3 -m osmol dinner.osmol --resolve "raj:venue(dinner)=verde"

The resolved decide becomes, in effect, hold venue(dinner) = verde on raj. That new hold then satisfies any counterparty seeks: in the dinner mesh this is exactly flow t₁, where maya's seek venue(dinner) by 18:00 else escalate finally has supply to draw on, and the venue flows to her ledger. The walkthrough is in Resolving Decides.

This is not a v0.1 shortcut that waits for a smarter engine. It is the permanent contract of the runtime, in every habitat, always: the engine cannot choose. The dissertation states it as design law, human judgment is an input type and not a solver capability, and the reference interpreter states the same in a comment at the exact point where resolutions enter the engine:

human judgments arrive as declarations, never as choices the machine makes on a person's behalf

Any future implementation that "helpfully" resolves a decide, even an obviously one-sided one, is nonconforming. A mesh that picks your restaurant is a mesh that will eventually pick your answer.

v0.1 interpreter notes

The reference interpreter's handling, normative for v0.1:

  • Parsing. The options list is parsed into a per-twin decides dict: fact -> {"among": [...], "by": ...}.
  • Validation. A --resolve value is checked against the declared options set; a value not among the options is an error (resolution 'X' not among options for fact). You cannot inject a choice the program never enumerated.
  • Resolution. A valid resolution deletes the decide, installs the chosen value as a hold, and prints a [human judgment] line in the trace.
  • Unresolved decides do not block. All other flows settle normally around an open decision; at equilibrium the interpreter reports each one:
awaiting human judgment [raj]: venue(dinner) among ['verde', 'banh-mi-house']  (machines do not choose venues)

Note that "equilibrium" and "everything resolved" are different states. A mesh with an open decide can be perfectly settled (no pressure clears any threshold) while it still waits on a person. The final silence is a fixpoint line prints only when open gaps and pending decides are both zero.

  • Structural gaps are simplified. Spec §3's per-option consequence gaps are not materialized as first-class gaps in v0.1; the decide's demand shows up through counterparty seeks (like maya's seek venue) rather than through auto-generated internal gaps. An implementation targeting the full spec should generate them.
  • Resolving Decides, the tutorial walkthrough of --resolve on the dinner mesh
  • owe, the other structural-gap generator (commitments)
  • seek, the gaps a resolved decision ultimately satisfies