| name | aipom-behavior-contract-builder |
| description | Define expected, acceptable, and prohibited AI behavior with representative cases, thresholds, escalation, and consequences. Use before evaluation, launch, or autonomy decisions. |
| type | component |
| category | evaluation-and-evidence |
| phase | 1 |
| status | active |
| operating_level | ["product-team","initiative"] |
| audience | ["Product Operations","Product Manager","Team Lead","Design","Engineering","Data","Research","AI Governance"] |
| best_for | ["Defining acceptable behavior before evaluation or launch","Resolving disagreement about what good enough means","Establishing limits before granting AI authority"] |
| evidence_required | ["Intended users, use cases, and affected people","Product outcomes and known failure consequences","Representative examples and constraints","Existing evaluation evidence where available"] |
| produces | ["AI behavior contract","Representative behavior cases","Escalation and decision thresholds"] |
| assessment_questions | ["EVAL-01","EVAL-02","EVAL-03","GOV-02"] |
| maturity_move | {"from":"emerging","to":"repeatable"} |
| estimated_time | 45-75 min |
| group_size | 3-8 |
| depends_on | [] |
| combine_with | ["aipom-autonomy-boundary-designer","aipom-golden-dataset-builder","aipom-eval-scorecard-builder"] |
| sources | ["https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10"] |
AIPOM Behavior Contract Builder
What Is It
Define how an AI product should behave, the range of acceptable variation, what it must refuse or escalate, and what happens when behavior falls outside the contract. The contract connects product intent to evaluation and operating decisions.
Why Use It
Teams cannot evaluate “helpful,” “safe,” or “accurate” consistently without observable expectations and consequences. A contract makes disagreement inspectable before it becomes a launch dispute or incident. Writing it does not prove conformance; representative evaluations and production evidence do.
When to Use It
Use before building an evaluation set, setting autonomy boundaries, launching a probabilistic feature, or revising behavior after incidents or user evidence. It is not a legal compliance determination or a substitute for specialist review.
What It Produces
- Purpose and scope
- Expected, acceptable, escalated, and prohibited behaviors
- Representative normal, edge, adversarial, and failure cases
- Thresholds tied to ship, continue, pause, rollback, or retire decisions
- Owners, evidence gaps, and review triggers
Who Should Participate
Include the Product Manager, technical and evaluation owners, design or research, workflow operators, and the person accountable for affected outcomes. Add legal, privacy, security, safety, accessibility, or domain specialists in proportion to consequences.
Evidence to Bring
Bring user research, intended-use statements, real inputs, known failures, policies, evaluation results, complaints, incidents, and affected-user perspectives. Label hypothetical cases and unsupported thresholds as assumptions.
How to Do It
- Set scope. Name the system version, users, affected people, contexts, and decision the contract must support.
- Define purpose. State the user outcome and boundaries; avoid capability marketing.
- Describe behaviors. Use observable input-condition-output-consequence statements.
- Classify behavior. Mark each as expected, acceptable variation, escalate/refuse, or prohibited.
- Add cases. Cover frequent use, difficult ambiguity, affected groups, misuse, adversarial inputs, and consequential failure.
- Set evidence rules. Name measures, human judgment, sampling, thresholds, and limitations. Avoid fake precision.
- Connect decisions. Specify which evidence triggers ship, continuation, correction, pause, rollback, or retirement.
- Assign ownership. Name who interprets evidence, decides, remains accountable, and approves changes.
