# Aipom Trust Assurance Pack Builder

> Assemble current, audience-appropriate evidence about an AI product's purpose, behavior, limits, evaluations, controls, ownership, incidents, and change history.

- Skill: `deanpeters/aipom-trust-assurance-pack-builder` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add deanpeters/aipom-trust-assurance-pack-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/deanpeters/aipom-trust-assurance-pack-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Dean Peters (https://skillmd.com/u/deanpeters)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/deanpeters/aipom-trust-assurance-pack-builder

---


# AIPOM Trust Assurance Pack Builder

## What Is It

Assemble a bounded, current, traceable evidence package explaining an AI product’s purpose, scope, behavior, limitations, evaluations, production evidence, human oversight, controls, accountability, incidents, dependencies, and change history for a named audience and decision.

## Why Use It

Trust claims become stale, promotional, or contradictory when evidence lives across teams. An assurance pack makes claims inspectable without pretending documentation proves safety, compliance, or universal trustworthiness.

## When to Use It

Use for internal governance, customer assurance, procurement, audit preparation, partnership, or material change. Tailor disclosure to audience, confidentiality, security, legal duties, and decision need.

## What It Produces

- Audience, decision, scope, versions, and freshness boundary
- Claims linked to evidence, owner, date, confidence, and limitations
- Purpose, behavior, evaluation, production, oversight, control, incident, and dependency summary
- Gaps, restricted evidence, update triggers, and accountable sign-off

## Who Should Participate

Include the product and technical owners, evidence owners, legal, privacy, security, risk, governance, communications, and the accountable business owner. The intended audience should review usability where possible.

## Evidence to Bring

Bring system and data documentation, behavior contracts, evaluations, production reviews, source and dependency maps, accountability and autonomy records, controls, incidents, limitations, changes, specialist decisions, and prior assurance responses.

## How to Do It

1. Define the audience, decision, disclosure boundary, system scope, versions, and effective date.
2. Inventory proposed claims and classify each as evidenced, qualified, assumed, disputed, restricted, or unsupported.
3. Link every retained claim to evidence, owner, date, scope, confidence, and limitation.
4. Summarize purpose, intended and prohibited use, users, affected parties, and human oversight.
5. Summarize behavior, evaluations, production evidence, subgroup or edge coverage, and known limits.
6. Summarize data and context, dependencies, controls, accountability, escalation, incidents, remediation, and change history.
7. Remove promotional claims that evidence cannot support; record gaps and restricted evidence honestly.
8. Review disclosure, security, legal, accessibility, and audience usability with accountable partners.
9. Assign sign-off, expiry, refresh, withdrawal, and change-trigger rules.

## Key Concepts

- Assurance is evidence for a decision, not a universal trust seal.
- Every claim has scope, freshness, and limits.
- Restricted evidence should be acknowledged, not silently omitted.
- Incidents and remediation are part of current trust evidence.

## Organizational Applications

Use for customer diligence, enterprise procurement, launch councils, boards, auditors, regulators, internal risk committees, and affected-user communication.

## Common Pitfalls

- Writing marketing copy with technical appendices
- Claiming compliance from artifact completion
- Omitting incidents or negative evidence
- Mixing evidence from different versions
- Publishing restricted details without review
- Creating a pack with no expiry or owner

## Combine With

Use `aipom-accountability-charter` for decision rights, `aipom-risk-control-incident-playbook` for response evidence, and `aipom-strategy-narrative-builder` for organization-level choices.

## Assets and Templates

- [Trust assurance pack template](template.md)
- [Synthetic worked example](examples/worked-example.md)
- [Weak example](examples/weak-example.md)

## Sources

- NIST AI Resource Center, [AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/). Supports documented scope, risks, impacts, evaluations, limitations, oversight, controls, and communication. Accessed July 17, 2026; NIST notes AI RMF 1.0 is under revision.
- OECD.AI, [Advancing Accountability in AI](https://oecd.ai/en/accountability/). Supports lifecycle accountability, documentation, communication, monitoring, and role-appropriate risk management. Accessed July 17, 2026.

An assurance pack does not establish legal or regulatory compliance and must not disclose information beyond authorized boundaries.