BountyHub Docs
Decisions
Make structured decisions over an input state document with step.decision, with validated typed answers from the built-in jevos provider.
Some steps cannot be expressed as a shell command or a transform. Deciding
whether a finding is in scope, ranking leads, or choosing the next action needs
judgement over messy input. step.decision makes that judgement an explicit,
typed step: it declares an input state, one or more named questions, a provider,
and where the validated result is written.
#step.decision
| Parameter | Meaning |
|---|---|
state | Input document the decision is made over (path.file(...)), read at execution time and treated as untrusted data |
questions | Ordered {name: decision_question} mapping; names are unique |
provider | Optional decision provider: "jevos" (the default) for the built-in live server, or "mock" for the deterministic in-process provider |
output | Where the validated result document is written (path.file(...)) |
endpoint | jevos endpoint, often config.var(...) (default local server: http://127.0.0.1:8017/v1/systemone) |
api_key | Optional jevos API key; must be a config.secret(...) reference |
model | Optional jevos model alias (default jev-latest) |
#Question types
Questions are created with the decision namespace and carry their own
validation rules:
noulis binary: jevos returns P(yes), the answer isP(yes) >= 0.5, and the probability is carried through as the reported confidence.choicerequires a non-empty list of unique, non-empty options; the answer must be one of them.scorerequires ordered bounds (minmust not exceedmax); the answer must be an integer inside them.
Invalid definitions are rejected when the workflow is parsed. Invalid provider answers are rejected at execution time, before anything is written.
#Inputs and credentials
state is a file and is always treated as data, never as instructions. Provider
configuration is referenced, never embedded:
api_key accepts only a config.secret(...) reference; literal credentials are
rejected so they can never enter the serialized workflow definition. Endpoints
and keys are resolved at execution time and are not written to the result
document.
#Providers
provider is optional and selects the decision implementation; it defaults to
"jevos". Two providers ship, and the platform standardizes on them:
"jevos"is the built-in live provider: a self-hosted jevos decision server, reached over HTTP atendpoint(defaulthttp://127.0.0.1:8017/v1/systemone). jevos answers yes/no (noul), multiple-choice, and score questions on a laptop CPU and returns a probability for each answer. Pointendpointat your jevos instance and, if you setJEV_API_KEYon it, supply the same key throughconfig.secret(...)."mock"is deterministic and in-process. It needs no endpoint or credential and is what the test suite uses, so decision steps stay hermetic.
Adding a provider is a code change, not a configuration value: the engine
rejects any other provider name rather than implying a provider zoo.
Two jevos limits surface as parse-time or step errors: a choice needs 2–26
options and a score needs 2–10 levels, so keep score bounds within a ten-point
span.
#The result document
The validated result is written to output as JSON: a mapping from question
name to a typed answer.
Downstream steps consume the file like any other workspace artifact:
#Trust boundary
A decision result is model-produced data, not proof. Every answer is validated against the question that produced it before the document is written, but:
- a self-reported
probabilityis not a calibrated probability, and - a
choiceorscoreanswer is a judgement about the input, not a verified fact.
Treat the document as one more input to validate downstream, not as an authority. Because the questions and their bounds are declared in the workflow, the result stays typed and reviewable instead of collapsing into free text.
#A security-triage workflow