Compliance Profiles¶

AUMP compliance profiles make regulatory, enterprise, and safety obligations machine-readable without making the protocol specific to one jurisdiction, vendor, model, or transport.

The core rule is simple: compliance requirements are evaluated at the same runtime boundary as authority, hard constraints, disclosure, escalation, and evidence.

proposed action
  -> mandate authority
  -> hard constraints
  -> disclosure policy
  -> compliance profile
  -> escalation policy
  -> allowed | requires_escalation | denied

Why This Matters¶

Project Deal showed that agents can complete real negotiations from natural language instructions alone. That is not enough for adoption. Users, platforms, counterparties, and auditors need to know which obligations governed the agent, which fields the agent was not allowed to use, when review was required, and what evidence was retained.

AUMP keeps those requirements explicit and testable.

Profile Fields¶

Field	Purpose
`profiles`	Named external or internal compliance mappings.
`prohibited_decision_factors`	Fields the agent must not use to decide or rank an action.
`review_required_actions`	Action types that must pause for trusted review.
`required_evidence_events`	Audit events expected for regulated decisions and exceptions.

Reference Mappings¶

A profile can point to public frameworks such as:

Those references do not turn AUMP into a legal opinion. They make the runtime decision boundary reproducible and auditable.

Conformance Behavior¶

The conformance suite now includes high-stakes housing vectors that prove:

machine-readable hard constraints are enforced;
prohibited decision factors are denied;
compliance-gated commitments return requires_escalation;
SDKs produce the same result as the native conformance runner.