JEP Action Mandate Profile (JEP-AMP)

3.1. Action Mandate

A signed JEP Delegation event whose what value conforms to the Action Mandate Descriptor defined by this profile.¶

3.2. Mandate Identity

The Event Identity (who,id) of the JEP Delegation event that issues the mandate.¶

Mandate Identity is the canonical logical identifier of an AMP-2 mandate.¶

3.3. Mandate Artifact Hash

The JEP Event Hash of one exact signed representation of the issuance event.¶

The Mandate Artifact Hash is not the Mandate Identity.¶

3.4. Issuer

The actor identified by the issuance event's who member.¶

The issuer is not automatically authorized to act for the principal.¶

3.5. Principal

The person, organization, account, tenant, legal entity, or other subject on whose behalf the delegated action is to be attempted.¶

3.6. Delegatee

The actor identified by what.delegatee.¶

3.7. Mandate Status

A profile-level result indicating whether the mandate satisfies the AMP-2 requirements for the requested evaluation context.¶

The initial values are valid, invalid, and indeterminate.¶

3.8. Action Decision

A local relying-party decision about whether an external action should be allowed, denied, reviewed, or deferred.¶

Action Decision is not a global JEP-AMP conclusion.¶

6.1. Encoding

For the AMP-2 baseline profile, the Action Mandate Descriptor is the JEP D event's what object.¶

The descriptor MUST therefore include the Core-required D members delegatee and scope.¶

AMP-2 does not define a detached descriptor encoding. External policy, credential, evidence, receipt, or domain objects MAY be referenced from the descriptor or from JEP references, but the authoritative AMP-2 descriptor itself is signed inline as what.¶

A future extension MAY define a detached representation, but it MUST preserve the Core-required signed D semantics and define conflict resolution.¶

6.2. Required Members

An AMP-2 Action Mandate Descriptor MUST contain:¶

• profile¶
• principal¶
• delegatee¶
• action¶
• target¶
• scope¶
• validity¶

The required members have the following baseline shapes:¶

• profile MUST be a string equal to https://humanjudgment.org/jep/profiles/amp/2.¶
• principal MUST be an object containing a non-empty string id. principal.type MAY be present as a non-empty string.¶
• delegatee MUST be a non-empty string actor identifier.¶
• action MUST be an object containing a non-empty string type. action.type MUST be an absolute URI identifying the action or action family. A domain profile MAY define additional members of action.¶
• target MUST be an object containing non-empty string members type and id. A domain profile MUST define the identifier and matching semantics for the target type it uses.¶
• scope MUST be a non-empty JSON object. A domain profile MUST define the meaning and comparison rules for any scope members that affect an Action Decision.¶
• validity MUST be an object containing expires_at. validity.expires_at MUST be an RFC 3339 date-time [RFC3339]. validity.not_before MAY also be present and, if present, MUST be an RFC 3339 date-time.¶

If validity.not_before is absent, AMP-2 imposes no profile-level lower time bound. A relying party MAY impose a local or domain-specific lower bound, but MUST NOT derive trusted start time solely from the JEP when value.¶

A mandate whose expires_at precedes not_before is invalid.¶

The descriptor MUST NOT add new top-level members beyond those defined by this document or a later compatible AMP revision. Additional extensibility MUST use JEP ext / ext_crit or referenced profile-defined objects rather than a second descriptor-level extension namespace.¶

6.3. Optional Members

The descriptor MAY contain:¶

• mandate_id¶
• constraints¶
• usage¶
• policy_ref¶
• authority_evidence¶
• delegation¶
• termination¶

mandate_id, when present, MUST be a non-empty string application-level alias. It MUST NOT replace Mandate Identity for cross-system logical references.¶

constraints, when present, MUST be a JSON object. If absent, AMP-2 imposes no additional constraint set beyond the required action, target, scope, validity, and applicable policy rules.¶

policy_ref, when present, MUST be a non-empty array of objects. Each object MUST contain a non-empty uri string identifying the applicable policy or policy document. Absence of policy_ref means that the mandate itself declares no external policy reference; local policy MAY still apply.¶

authority_evidence, when present, MUST be a non-empty array of references. Each reference MUST use JEP reference semantics or a reference form explicitly defined by the active authority profile.¶

No descriptor-level extensions member is defined by AMP-2. Extension data belongs in JEP ext / ext_crit or in referenced profile-defined objects.¶

6.4. Action

action MUST be an object and MUST contain the required type member defined in Section 6.2.¶

action.type identifies the action or action class.¶

AMP-2 does not define a global action taxonomy. A domain profile MUST define the semantics and request-matching rules for each action type it uses.¶

Additional members of action MAY be defined by the active domain profile.¶

6.5. Target

target MUST be an object and MUST contain the required type and id members defined in Section 6.2.¶

The target identifies the object, resource, record, account, workflow, case, transaction, or other domain object to which the mandate applies.¶

A domain profile MUST define the target identifier, normalization, comparison, and matching rules used for Action Decision.¶

6.6. Scope

scope MUST be a non-empty JSON object and MUST be machine-processable under the applicable domain profile.¶

It MAY include purpose, work-unit, resource, tenant, geography, data-boundary, or other domain limits.¶

A relying party MUST NOT infer a broader scope merely because a requested action uses the same action type or target family.¶

A domain profile MUST define comparison rules for every scope member that can change an Action Decision.¶

6.7. Constraints

constraints MAY define amount limits, data limits, resource sets, vendor sets, customer sets, risk limits, approval thresholds, or other boundaries.¶

A domain profile MUST define comparison rules for any constraint that affects Action Decision.¶

6.8. Usage

If usage is absent, AMP-2 imposes no profile-level use-count limit. Local or domain policy MAY still impose a limit.¶

If usage is present, it MUST be an object containing max_uses.¶

usage.max_uses MUST be a positive integer.¶

usage.reservation_required MAY be present as a boolean. If absent, its value is false.¶

A max_uses value of 1 defines a single-use mandate at the AMP layer.¶

Usage counting and consumption state MUST NOT be inferred from Core idempotent acceptance. A relying party MUST still enforce max_uses safely. Deployments requiring concurrent or distributed use control MUST provide an atomic or equivalent reservation/consumption mechanism, regardless of the value of reservation_required.¶

6.9. Authority Evidence

authority_evidence MAY reference evidence that the issuer is authorized to issue or convey the mandate on behalf of the principal.¶

If the principal is distinct from the issuer, a Mandate Verifier MUST NOT report issuer authority as pass without applicable authority evidence or a selected policy/profile rule that establishes that authority.¶

If the principal and issuer identifiers are the same, actor binding may be sufficient for a self-principal deployment only when the active profile or local policy explicitly permits that interpretation.¶

6.10. Delegation Controls

If delegation is absent, subdelegation is not allowed.¶

If delegation is present, it MUST be an object containing the boolean member subdelegation_allowed.¶

If subdelegation_allowed is false, no child mandate is permitted under AMP-2.¶

If subdelegation_allowed is true:¶

• max_depth MUST be present and MUST be a positive integer;¶
• scope_expansion_allowed MAY be present as a boolean and defaults to false;¶
• constraint_relaxation_allowed MAY be present as a boolean and defaults to false;¶
• the parent-reference rule defined by this document applies;¶
• any parent-termination effect on child eligibility MUST be explicitly defined by the parent descriptor or active domain profile.¶

AMP-2 has no implicit parent-termination cascade rule.¶

If a child mandate is permitted, its issuance event MUST reference the parent Mandate Identity using a typed JEP event reference. An exact parent artifact MAY additionally be pinned by Event Hash.¶

Unless scope_expansion_allowed is explicitly true, child scope MUST be equal to or narrower than parent scope.¶

Unless constraint_relaxation_allowed is explicitly true, child constraints MUST be equal to or stricter than parent constraints.¶

Even when expansion or relaxation is permitted by the descriptor, the active domain policy MAY still reject it.¶

6.11. Termination Controls

If termination is absent, the issuance actor is the default authorized terminator.¶

If termination is present, it MUST be an object. It MAY contain authorized_terminators.¶

authorized_terminators, when present, MUST be a non-empty array of non-empty string actor identifiers. Only actors permitted by this list and any stricter active policy may satisfy the AMP termination-status check as an authorized terminator.¶

Expiry under validity.expires_at does not require a T event.¶

6.12. Minimal Descriptor Example

{
  "profile": "https://humanjudgment.org/jep/profiles/amp/2",
  "principal": {
    "id": "did:example:acme",
    "type": "organization"
  },
  "delegatee": "did:example:agent:procure-7",
  "action": {
    "type": "urn:example:procurement:action:purchase"
  },
  "target": {
    "type": "procurement_request",
    "id": "req-123"
  },
  "scope": {
    "purpose": "purchase-approved-materials",
    "work_unit_ref": "req-123"
  },
  "validity": {
    "not_before": "2026-09-26T00:00:00Z",
    "expires_at": "2026-09-28T00:00:00Z"
  },
  "constraints": {
    "amount": {
      "currency": "USD",
      "max": 5000
    }
  },
  "usage": {
    "max_uses": 1,
    "reservation_required": true
  },
  "policy_ref": [
    {
      "uri": "urn:policy:acme:procurement:v3"
    }
  ],
  "delegation": {
    "subdelegation_allowed": false
  }
}

The DID identifiers are illustrative only.¶

8.1. Logical Reference

A JEP event referring to an AMP-2 mandate SHOULD reference the issuance Event Identity.¶

Conceptually:¶

{
  "type": "jep:event",
  "value": {
    "who": "did:example:issuer",
    "id": "urn:uuid:..."
  }
}

8.2. Exact Artifact Pin

When the exact signed issuance artifact matters, the reference MAY additionally pin the issuance Event Hash.¶

A validator MUST verify an exact-artifact pin when the active validation context requires reference_integrity.¶

8.3. Application Alias

A mandate_id alias MAY be indexed or displayed by applications.¶

A relying party MUST NOT substitute mandate_id for Mandate Identity unless a domain mapping explicitly defines that mapping and collision behavior.¶

9.1. Termination Event

An AMP-2 termination declaration is a JEP T event that:¶

• has verb equal to T;¶
• uses a typed JEP event reference in ref whose value equals the Mandate Identity;¶
• has what.termination_scope equal to https://humanjudgment.org/jep/profiles/amp/2#mandate-reliance;¶
• is signed and Core-validated;¶
• is issued by an actor authorized by the mandate or applicable profile.¶

The T event MAY include a profile-defined reason such as revoked, consumed, superseded, completed, policy_change, or constraint_violation.¶

9.2. Profile-Level Effect

A conforming Mandate Verifier that observes an authorized AMP-2 termination event in the applicable evaluation context MUST treat the referenced mandate as ineligible for future reliance in that context.¶

This is an AMP profile rule. The JEP T event itself does not delete history, retroactively invalidate prior events, or prove that every downstream system has observed or enforced the termination.¶

9.3. Expiry

After validity.expires_at, the mandate is invalid for new AMP reliance even if no T event exists.¶

Expiry is evaluated from the mandate validity rule and the time source chosen by the active profile or relying party. The issuance event's JEP when value alone is not trusted wall-clock evidence.¶

10.1. Separation from Core Acceptance

Core acceptance answers whether the same JEP Event Identity has already applied the same acceptance effect in one acceptance domain.¶

AMP usage answers whether a mandate has remaining authorized uses.¶

These are independent state machines and MUST NOT be conflated.¶

10.2. Single-Use and Bounded-Use Mandates

When usage.max_uses limits use, the relying party MUST maintain sufficient usage state to avoid permitting more uses than allowed.¶

For concurrent or distributed relying parties, a domain profile SHOULD define an atomic reservation or consumption mechanism.¶

10.3. Reservation

A reservation record SHOULD bind:¶

• Mandate Identity;¶
• requested action and target;¶
• request digest when available;¶
• reserving actor;¶
• reservation time;¶
• optional reservation expiry;¶
• reservation outcome.¶

A reservation MAY be recorded by a profile-defined V event or by an external domain record referenced from a JEP event.¶

10.4. Consumption

A consumption record SHOULD bind:¶

• Mandate Identity;¶
• receipt or evidence reference;¶
• consuming actor or relying party;¶
• consumed use count;¶
• consumption time;¶
• terminal reason when applicable.¶

A T event with reason consumed MAY record a declaration that no future reliance is intended. It does not by itself provide the concurrency guarantee required to prevent double consumption.¶

11.1. Layer Separation

AMP-2 distinguishes:¶

• JEP-Core validation status;¶
• AMP Mandate Status;¶
• local Action Decision.¶

A valid JEP signature is not sufficient for Mandate Status valid.¶

Mandate Status valid is not a global authorization decision.¶

11.2. Profile-Specific Checks

The following provisional AMP-2 check identifiers are defined:¶

• https://humanjudgment.org/jep/profiles/amp/2#profile-binding¶
• https://humanjudgment.org/jep/profiles/amp/2#descriptor¶
• https://humanjudgment.org/jep/profiles/amp/2#issuer-authority¶
• https://humanjudgment.org/jep/profiles/amp/2#delegatee¶
• https://humanjudgment.org/jep/profiles/amp/2#time-validity¶
• https://humanjudgment.org/jep/profiles/amp/2#audience¶
• https://humanjudgment.org/jep/profiles/amp/2#termination-status¶
• https://humanjudgment.org/jep/profiles/amp/2#usage-status¶
• https://humanjudgment.org/jep/profiles/amp/2#request-scope¶
• https://humanjudgment.org/jep/profiles/amp/2#subdelegation¶
• https://humanjudgment.org/jep/profiles/amp/2#evidence¶
• https://humanjudgment.org/jep/profiles/amp/2#policy¶

Check statuses use the JEP conformance values:¶

• pass¶
• fail¶
• not_checked¶
• not_applicable¶
• unsupported¶
• indeterminate¶

AMP-2 does not define a cumulative validation level.¶

11.3. Mandate Status

For the requested AMP validation context:¶

• valid means every required AMP check passed or was not applicable;¶
• invalid means at least one required AMP check failed;¶
• indeterminate means no required check failed but at least one required check is unsupported, not checked, or indeterminate.¶

A validator MUST report which checks were required and which statuses were obtained.¶

11.4. Baseline Validation Flow

A Mandate Verifier SHOULD:¶

• validate the issuance event under JEP-Core;¶
• confirm that the event is D and what.profile is the AMP-2 identifier;¶
• validate the descriptor structure;¶
• confirm what.delegatee and what.scope;¶
• evaluate issuer/principal authority under the active trust or policy profile;¶
• evaluate validity time using the applicable time source;¶
• evaluate aud when required;¶
• resolve relevant authorized termination declarations;¶
• evaluate usage or reservation state when applicable;¶
• evaluate requested actor, action, target, scope, and constraints;¶
• evaluate subdelegation rules when applicable;¶
• evaluate required evidence, approvals, and policy;¶
• return Core status, AMP check results, and Mandate Status separately.¶

A validator MUST NOT report Action Decision allow solely because Mandate Status is valid.¶

17.1. AMP-2 Mandate Producer

A conforming AMP-2 Mandate Producer MUST:¶

• produce a JEP D event conforming to the applicable Core Producer class;¶
• use https://humanjudgment.org/jep/profiles/amp/2;¶
• include the Action Mandate Descriptor inline in what;¶
• satisfy all required descriptor members;¶
• use Mandate Identity consistently;¶
• preserve profile and Core boundaries.¶

17.2. AMP-2 Mandate Verifier

A conforming AMP-2 Mandate Verifier MUST:¶

• perform or consume a JEP-Core validation result;¶
• support the baseline AMP checks required by the evaluation context;¶
• preserve independent check statuses;¶
• distinguish Core status, Mandate Status, and Action Decision;¶
• resolve authorized T events when termination status is required;¶
• evaluate usage state when the mandate declares a usage limit;¶
• reject or return indeterminate when required evidence or capabilities are unavailable;¶
• avoid treating Event Hash as Mandate Identity.¶

17.3. Gateway Evaluator

A gateway that claims AMP-2 Gateway Evaluator capability MUST perform Mandate Verification before making a local Action Decision.¶

If the local Action Decision relies on the AMP mandate as authorization evidence, the gateway MUST NOT return allow when Mandate Status is invalid or indeterminate.¶

A gateway MAY allow an action on an independent non-AMP basis, but it MUST report that AMP was not the authorization basis for that decision and MUST NOT present the result as AMP-authorized.¶

Its local Action Decision MUST be labeled as local or domain-specific and MUST NOT be presented as a universal AMP authorization result.¶