Aipom behavior contract builder
Skill deanpeters/ai-product-operating-model-skills/skills/aipom-behavior-contract-builder
Evidence-based skills for designing and improving AI product operating models
npx -y skills add deanpeters/ai-product-operating-model-skills --skill aipom-behavior-contract-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Define expected, acceptable, and prohibited AI behavior with representative cases, thresholds, escalation, and consequences. Use before evaluation, launch, or autonomy decisions.
SKILL.md
5.6 KB, as published. Nobody here has run it
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.
AI may organize cases and draft language. Humans decide acceptable consequences, thresholds, and authority.
Key Concepts
- Behavior, not intention: describe what users can observe.
- Acceptable range: probabilistic systems require bounded variation, not one ideal answer.
- Consequence-aware evaluation: weight failures by who is affected and what follows.
- Contract evolution: version behavior when evidence or context changes.
Organizational Applications
Use for assistants, recommendations, classifiers, generated content, decision support, and agents. Reuse the contract across design reviews, evaluation datasets, autonomy decisions, production monitoring, and incident learning.
Common Pitfalls
- Using adjectives without observable cases
- Testing only happy paths
- Treating an average score as permission to ignore severe failures
- Setting thresholds without evidence or a decision
- Omitting affected people, refusals, escalation, or owners
- Treating the document as proof of reliable behavior
Combine With
Use aipom-autonomy-boundary-designer to decide authority, aipom-golden-dataset-builder to operationalize representative cases, and aipom-eval-scorecard-builder to define measurement and decision rules.
Assets and Templates
Sources
- NIST, AI Risk Management Framework 1.0, January 26, 2023. Supports lifecycle risk mapping, measurement, management, and accountable governance. Accessed July 16, 2026. NIST notes that the framework is being revised.