Name the action before anyone asks whether it is allowed.
A lightweight format, Python validator and CLI for describing the actions an AI agent may propose. Manifest 1.1 adds deterministic runtime bindings, so a downstream controller can compare a proposal with one specific declared action.
The same integration can read data, draft a message, issue a payment or delete a record. Reviewers cannot govern an action surface no one has written down.
Stable action and adapter IDs, finite targets and effect limits that survive the handoff from design review to runtime control.
tools, action types, owners and intended scope, identified before execution.
authority, review and reliance requirements declared, without issuing grants.
sensitive fields and redaction hints described for downstream record handling.
action and adapter IDs, finite targets, effect limits and Authority Context references (1.1 profile).
Pydantic models, JSON schemas and the aam CLI to validate, summarize and list actions.
A reviewer declares a routine refund with its allowed adapter, target and effect limits. At runtime the proposal is bound to that manifest commitment. The Control Plane then obtains Authority Context from a trusted resolver, independently of the incoming request, and checks the actual proposal. Matching the declaration alone never authorizes the refund.
Write a manifest for one bounded action you already run, validate it with the CLI and review it with that action’s owner.
Open the repository →Declaration and validation, not a security boundary or runtime access control. A valid manifest does not establish institutional legitimacy, current approval, a completed effect or compliance. The exporting system must apply redaction hints itself.