Decision behavior
How a particular AI system tends to decide across cases — where it leans, abstains or errs. Once embedded in operational thresholds, it becomes a dependency that makes switching vendors harder.
Decision behavior is the pattern in how a model or decision service resolves cases: which way it leans on ambiguous inputs, how its confidence relates to correctness, where it declines to decide. Two systems with similar benchmark scores can behave quite differently on the cases that matter to you.
It becomes strategically important once a vendor's behavior is built into your operations. Teams set thresholds against that behavior, tune review queues around it and accumulate evidence about it. After that, switching models stops being a simple quality comparison: every threshold must be re-tested and the evidence rebuilt. This is a quiet form of vendor lock-in, separate from prompts, context or APIs.
Managing it
Record the behavior you depend on, re-measure calibration after model changes, and keep thresholds owned by your side of the decision layer.
Read more in OpenAI Decisions API turns probability into policy.
Related terms
Decision layer
A dedicated component between AI judgment and organizational action that decides whether the work should continue, separate from the part of the system that does the work.
Vendor lock-in
Dependence on one provider that makes switching costly. With AI it extends beyond APIs and prompts to the vendor's decision behavior, embedded thresholds and platform features.
Threshold policy
The explicit rules that turn a model's probability or score into an action — reject, send to a human, or act autonomously — owned and reviewed separately from the model itself.
Calibration
How well a model's stated confidence matches reality: if it says 90% on a hundred comparable cases, roughly ninety should be correct. Once probabilities drive actions, it becomes an operating metric.