| Abstain | The decision’s output had no answer, so there is no score. The response’s status is abstained; outcomes.abstain names the outcome to use, and may reuse one such as escalate. | From answers to an outcome |
| Acceptance | A suggestion is accepted when the version it proposed first serves primary production traffic after the suggestion was made. Previews, test keys and reverts never count. | Suggestions and previews |
| Action | What your app actually did with an item, sent as an action feedback claim. It’s observed behavior, not the right answer. | Feedback |
| Action mix | The share of each outcome over recent primary traffic in your key’s environment, before and after a change, at your cut points. Part of a preview. | Suggestions and previews |
| Aggregator | A node that combines other nodes’ values into one number: combine or calibrate. Moonbounce computes it; no engine is involved. | Describe a decision |
| Binding | Which engine a decision runs on, per environment. Changing it appends a new binding revision. | Engines, keys and environments |
| Calibrate | An aggregator that maps a score onto the probability that the target is true. Until weights are fitted it passes its input through, with calibrated: false. | From answers to an outcome |
| Claim | One statement inside a feedback submission: an outcome, target, verdict, feature, input_broken or action claim. | Feedback |
| Combine | The aggregator that turns several answers into one score. Each term says whether its answer raises or lowers the score. | Describe a decision |
| Content part | One piece of the item you send: a text or json part, optionally named. subject parts are what’s being judged; context parts are background that every feature reads. | Evaluate content |
| Contributions | In a combine node’s value, each term’s weight times its answer: how much each answer moved the score. | From answers to an outcome |
| Cut points | The thresholds in your code that turn a score into an outcome, sent as outcomes with each call. Northpine: below 0.38 deny, from 0.38 escalate, from 0.60 grant. Not part of any hash. | From answers to an outcome |
| Decision | A decision_id you choose, such as refund-exception, plus its spec. | Describe a decision |
| Decision file | The file in your repository, by convention moonbounce/<decision_id>.json, holding the spec, the weights pin and the cut points, so one pull request changes all three together. | Versions and hashes |
| Default weights | The numbers every combine starts with before any fit, set by its prior: a plain average for mean, or “one strong yes is enough” for any. Sent as "weights": "default". | From answers to an outcome |
| Dry run | dry_run: true on evaluate: runs the engines and answers, stores no evaluation, and returns a dry_ id that names nothing stored; only its spend is recorded. | Evaluate content |
| Engine | The model service that answers a decision’s features. Two are offered, Jev (the default) and Clef. | Engines, keys and environments |
| Engine profile | Which engine and exact model answered each feature of an evaluation. Weights fitted on one profile aren’t applied to another. | Engines, keys and environments |
| Environment | Production or test. It comes from the API key, and each environment has its own evaluations, feedback, review queue, engine binding, suggestions and previews. | Engines, keys and environments |
| Evaluation | One run of a decision on one item: every answer, the score, the outcome and the version that produced them. Its id starts evl_. | Evaluate content |
| Evidence label | How strong a preview’s evidence is, by what it was tested on: Starting examples, Training cases or Held out. | Suggestions and previews |
| Feature | An indicator we look for in the content: its name says what it is, its prompt asks the engine to detect it, and its value is how likely it’s there. Northpine: defective. | Describe a decision |
| Feedback | What was true about an evaluation, sent by you, your app or a reviewer. It’s what previews and suggestions learn from. | Feedback |
| Guidance | Background text: on the spec, for every prompt (the policy), or on one feature, for that prompt only. | Describe a decision |
| Held out | A reviewed case kept out of the suggestion writer’s sight, so a preview can test a change on cases it was never shaped by. | Suggestions and previews |
| Idempotency key | A value you send in the Idempotency-Key header so a retried request returns the first result instead of running twice. | Evaluate content |
| Item | The thing being judged, named by your item_id, such as a ticket. Several evaluations of the same item share its id. | Evaluate content |
| Node | A named entry in a spec’s nodes map: a feature or an aggregator. | Describe a decision |
| Outcome | The name a score lands on at your cut points, such as grant. Your code decides what it means. | From answers to an outcome |
| Output | The node whose value is the decision’s score, named by the spec’s output. | Describe a decision |
| Owner | The person whose judgment decides a case. Feedback with source: "owner" comes from them. | Feedback |
| Preview | A replay of a changed spec on your past cases with feedback, before you merge it: what it fixes, what it breaks, the action mix and an evidence label. | Suggestions and previews |
| Primary traffic | Evaluations your app acts on, as opposed to seed examples and replays. Only primary traffic enters the review queue, and only primary production traffic counts toward acceptance. | Evaluate content |
| Review | Answering an item from the review queue in the web app. The person reviewing is a reviewer. | Review |
| Review queue | A short daily list of the evaluations whose review would teach the most, plus random spot checks. | Review |
| Scope | What an API key may do: decisions:evaluate, decisions:feedback or decisions:develop. | Engines, keys and environments |
| Score | The output node’s value, between 0 and 1, at full precision. | From answers to an outcome |
| Seed examples | About a dozen labeled examples you upload when you start, so previews have cases to test against. They never count as traffic. | Feedback |
| Source | Who is speaking in a feedback submission: owner, app_native (your app’s own approve or reject feedback) or app_resolution (how your process finally settled the case). | Feedback |
| Spec | The JSON document that describes a decision: its nodes, output, target and guidance. | Describe a decision |
| Spot check | A random item in the review queue, shown blind (without Moonbounce’s answer), so agreement can be measured honestly. | Review |
| Structure hash | The hash of the features and how they combine. Formatting and key order don’t change it; changing a prompt does. | Versions and hashes |
| Suggestion | One proposed change to a spec, such as a reworded prompt or a new feature, delivered as a diff with a preview. | Suggestions and previews |
| Target | The yes/no statement the score is the probability of. Northpine: “The refund exception should be granted.” | Describe a decision |
| Version | A structure hash and a weights hash together. There are no version numbers. | Versions and hashes |
| Weights | The numbers inside combine and calibrate. Moonbounce stores them by hash; your code pins which ones to use. | Versions and hashes |
| Weights hash | The hash of a weights document. "default" stands for the default weights of the spec you send. | Versions and hashes |