UEARM Technical Specification v0.1
Unified Economic Action Representation Model

1.1 Purpose

This specification defines the initial technical structure of the Unified Economic Action Representation Model (UEARM).

UEARM provides a proposed machine-readable representation for economically consequential actions initiated, requested, delegated, or executed within AI-enabled systems.

Its purpose is to establish a consistent structure for representing the relationships between:

• 1. Identity and provenance.
• 2. Economic action.
• 3. Economic parameters.
• 4. Delegated authority.
• 5. Policies and constraints.
• 6. Execution context.
• 7. Governance decisions.
• 8. Execution states.
• 9. Evidence and verification.
• 10. Economic and operational outcomes.

The specification establishes an initial technical contract for implementing and evaluating these relationships.

1.2 Scope

UEARM v0.1 defines:

• A core JSON data model.
• Mandatory and optional fields.
• Data-type and validation requirements.
• Economic amount representation.
• Action-bound authorization requirements.
• Governance decision semantics.
• Execution-state definitions.
• Revocation and cancellation requirements.
• Concurrency and idempotency requirements.
• Evidence and outcome representation.
• Schema versioning requirements.
• Initial conformance test cases.

1.3 Out of Scope

UEARM v0.1 does not define:

• A universal payment protocol.
• A complete identity-management system.
• A particular financial settlement mechanism.
• A universal policy language.
• A cryptographic identity infrastructure.
• A complete legal model for delegated authority.
• A production-grade execution gateway.
• An accredited industry standard.

Implementations may integrate with existing systems that provide these capabilities.

1.4 Specification Status

UEARM v0.1 is a proposed technical specification.

Its data structures and behavioral requirements are intended to support prototype implementation and controlled experimentation.

They have not yet been validated through comprehensive interoperability testing or independent certification.

3.1 Capability–Authority Separation

An AI agent's ability to formulate or reason about an action MUST NOT be interpreted as authorization to execute it.

3.2 Action-Bound Authorization

Authorization MUST be associated with the specific economic action, its relevant parameters, and the applicable authority grant.

3.3 Execution-Boundary Enforcement

The execution system MUST validate the applicable authorization and constraints at the defined enforceable execution boundary.

3.4 Economic Parameter Integrity

Requested, authorized, reserved, and executed economic values MUST remain distinguishable.

3.5 Explicit State Representation

Execution states MUST be represented explicitly and MUST follow defined transition rules.

3.6 Revocation Awareness

An implementation MUST define how authority revocation affects pending and executing actions.

3.7 Evidence Provenance

Evidence records MUST identify their source and relationship to the relevant economic action.

3.8 Outcome Verification

An execution acknowledgement MUST NOT automatically be treated as proof of final economic settlement.

3.9 Governed Learning

Learning and adaptation MUST NOT independently expand delegated economic authority.

3.10 Traceability

Each economic action MUST be traceable through its identifiers, governance decisions, execution events, evidence records, and outcome records.

4.1 Core Representation

The proposed UEARM representation is:

The required components may contain explicitly defined null values where permitted by the schema. A missing object MUST NOT be silently interpreted as an authorized or successful state.

4.2 Functional Separation

UEARM and its associated research components have different responsibilities.

No component should be assumed to be technically necessary solely because it appears in this conceptual architecture.

5.1 Top-Level Structure

A UEARM v0.1 document MUST contain the following top-level fields:

5.2 Identity and Provenance

The "identity" object MUST contain:

• "initiator_id"
• "initiator_type"
• "request_id"

The initiator type MUST identify the relevant category, such as:

• HUMAN
• AI_AGENT
• ORGANIZATION
• SYSTEM

An implementation SHOULD preserve the provenance of any delegated request and MUST NOT treat an unverified identity assertion as independently authenticated identity.

5.3 Economic Action

The "economic_action" object MUST contain:

• "action_type"
• "resource"
• "parameters"

The initial action categories are:

• PROCUREMENT
• FINANCIAL_TRANSFER
• CAPITAL_ALLOCATION
• PAYMENT_INITIATION
• RESOURCE_ALLOCATION
• CONTRACTUAL_COMMITMENT

Additional action types MAY be introduced through documented extensions or a later specification revision.

The "resource" field identifies the economic resource, account, contract, asset, or other relevant object.

5.4 Economic Parameters

Where an action involves monetary values, the implementation MUST represent the amount using a decimal string.

Example:

The following representation is NOT RECOMMENDED:

The use of decimal strings avoids relying on binary floating-point arithmetic for financial values.

A monetary amount MUST be associated with an explicit currency code.

For v0.1, currency codes SHOULD use the applicable ISO 4217 alphabetic code.

The implementation MUST distinguish:

• Requested amount.
• Authorized maximum amount.
• Reserved amount, if applicable.
• Executed amount.
• Settled amount, if independently established.

These values MUST NOT be treated as interchangeable.

5.5 Delegated Authority

The "delegated_authority" object MUST identify:

• Authority grant identifier.
• Granting principal.
• Authorized agent.
• Permitted action types.
• Monetary limit, where applicable.
• Currency, where applicable.
• Validity interval.
• Current authority status.

An authority grant SHOULD include a reference to the source document or record establishing the delegation.

An implementation MUST verify that the authority grant covers the requested action and its relevant economic parameters.

An authority grant that permits procurement MUST NOT automatically be interpreted as permitting financial transfers.

5.6 Policy and Constraints

The "policy" object MUST identify the applicable policy references.

Where a policy decision is made, the implementation SHOULD preserve:

• Policy identifier.
• Policy version.
• Evaluation timestamp.
• Evaluation context reference.
• Decision or evaluation result.

A policy reference alone does not establish that a policy was successfully evaluated.

5.7 Execution Context

The "execution_context" object SHOULD include:

• Environment identifier.
• Execution system identifier.
• Region or jurisdiction reference, where relevant.
• Context timestamp.
• Concurrency or transaction context reference.

Context information MUST be limited to what is necessary for the action and its governance requirements.

5.8 Governance Decision

The "governance" object MUST include:

• Decision identifier.
• Decision value.
• Decision timestamp.
• Decision reason.

The initial decision values are:

• ADMIT
• REJECT
• ESCALATE

An ADMIT decision MUST be bound to the action and authority evaluated.

A change to material action parameters MUST trigger a new authorization evaluation.

An ADMIT decision MUST NOT be interpreted as proof that execution has occurred.

5.9 Execution State

The "execution" object MUST contain:

• Current state.
• Last state-transition timestamp.

It SHOULD also preserve:

• Execution attempt identifier.
• Idempotency key.
• Executor identifier.
• Cancellation status.
• Execution receipt reference.

A system MUST maintain an auditable history of state transitions, even when the top-level object only exposes the latest state.

5.10 Evidence and Verification

Each evidence record SHOULD contain:

• Evidence identifier.
• Evidence type.
• Evidence source.
• Capture timestamp.
• Related event or transaction identifier.
• Integrity reference, where available.

Evidence types may include:

• COMMAND_RECORD
• AUTHORIZATION_RECORD
• POLICY_DECISION
• EXECUTION_RECEIPT
• SYSTEM_ACKNOWLEDGEMENT
• SETTLEMENT_CONFIRMATION
• STATE_TRANSITION
• CANCELLATION_RECORD

The implementation MUST distinguish between:

• 1. Evidence captured.
• 2. Evidence validated for integrity.
• 3. Evidence independently verified for the intended claim.

A record marked as captured MUST NOT automatically be marked as verified.

5.11 Outcome

The "outcome" object MUST represent the latest known outcome.

Initial outcome values:

• PENDING
• COMPLETED
• PARTIALLY_COMPLETED
• REJECTED
• FAILED
• CANCELLED
• EXPIRED
• UNRESOLVED

An outcome SHOULD identify the evidence supporting its classification.

A COMPLETED execution state does not necessarily establish a COMPLETED settlement outcome.

6.1 Schema Validation Requirements

An implementation MUST:

• 1. Validate incoming documents against the declared schema version.
• 2. Reject documents with missing required fields.
• 3. Reject invalid data types and enum values.
• 4. Reject malformed monetary amounts.
• 5. Reject duplicate property names at the JSON parsing boundary.
• 6. Apply semantic validation after structural validation.
• 7. Document its handling of unsupported schema versions.

The "format" keyword in JSON Schema may be treated as an annotation rather than an enforced assertion by some validators. Therefore, implementations MUST explicitly validate timestamps and other critical formats in their application-level validation layer.

7.1 Authority–Action Binding

The following conditions MUST hold before an action is admitted for execution:

• The authorized agent matches the initiating agent.
• The action type is included in the permitted action types.
• The authority grant is valid for the relevant time.
• The authority status is ACTIVE.
• The requested amount does not exceed the applicable monetary limit.
• The currency matches the authorized currency where the grant is currency-restricted.
• The action resource and beneficiary comply with applicable restrictions.

A mismatch MUST result in rejection or escalation according to the configured policy.

7.2 Temporal Validity

The implementation MUST evaluate:

An authority grant MUST NOT be treated as valid outside its defined validity interval.

The implementation SHOULD use synchronized timestamps and document its clock assumptions.

7.3 Monetary Validation

For a monetary action:

The comparison MUST use exact decimal arithmetic.

The implementation MUST NOT rely on binary floating-point comparisons for authorization decisions.

The implementation MUST also validate the currency and applicable precision rules.

7.4 Parameter Integrity

Any material change to the following fields MUST trigger a new authorization evaluation:

• Action type.
• Amount.
• Currency.
• Beneficiary.
• Source resource.
• Destination resource.
• Relevant execution constraints.

An earlier governance decision MUST NOT automatically authorize a materially modified action.

7.5 Decision Consistency

If:

Then the action MUST NOT transition to EXECUTING.

If:

Then the action MUST remain outside the executable state until the required escalation is resolved.

If:

The action MAY proceed to the next execution stage, subject to a final enforceable authorization check.

7.6 Evidence Consistency

An implementation MUST NOT mark an outcome as independently verified without a corresponding verification record.

Evidence references MUST identify the action or event to which they relate.

8.1 Defined States

8.2 Permitted Transitions

A new attempt after a terminal failure or cancellation MUST be represented through an explicitly linked retry or new action attempt. The original event history MUST be preserved.

8.3 Transition Enforcement

Every state transition MUST:

• 1. Identify the previous state.
• 2. Identify the new state.
• 3. Record the transition timestamp.
• 4. Identify the component initiating the transition.
• 5. Record a reason or event reference.
• 6. Preserve an immutable transition history.

A transition that violates the state machine MUST be rejected.

8.4 Cancellation Semantics

A cancellation request and a confirmed cancellation are different events.

"CANCEL_REQUESTED" means that cancellation has been requested.

"CANCELLED" means that the execution system has confirmed the defined cancellation condition.

A cancellation request MUST NOT be represented as successful cancellation before confirmation.

If execution has already crossed an irreversible boundary, the implementation MUST NOT claim that cancellation reversed the action.

It SHOULD instead record the actual execution state and, where supported, initiate a separate compensating or reversal action.

9.1 General Requirement

An authority grant may be revoked independently of the lifecycle of an action.

The implementation MUST define how revocation affects:

• CREATED actions.
• PENDING actions.
• AUTHORIZED actions.
• EXECUTING actions.
• PARTIALLY_EXECUTED actions.

9.2 Revocation at the Execution Boundary

Before execution begins, the system MUST revalidate the authority grant.

If the grant has been revoked before the enforceable execution boundary, the action MUST NOT proceed under that grant.

9.3 Revocation During Execution

If revocation occurs after execution has started, the implementation MUST evaluate whether:

• The operation can be stopped safely.
• The operation has crossed an irreversible boundary.
• Partial execution has occurred.
• A compensating action is required.
• The final outcome remains unresolved.

The implementation MUST preserve the revocation event and its timestamp.

9.4 Revocation Record

A revocation record SHOULD contain:

• Grant identifier.
• Revocation identifier.
• Revoking principal.
• Revocation timestamp.
• Effective boundary.
• Reason reference.
• Affected action identifiers, where available.

10.1 Concurrency Risk

Multiple individually valid actions may collectively exceed an authorized economic limit.

For example:

• Authorized limit: USD 10,000.
• Action A: USD 6,000.
• Action B: USD 6,000.

Independent validation of each request would incorrectly permit a cumulative exposure of USD 12,000 if the same limit is shared.

10.2 Atomic Reservation

Where an authority grant defines an aggregate monetary limit, the execution environment SHOULD implement an atomic reservation or equivalent concurrency-control mechanism.

The following invariant MUST hold:

The exact treatment of reservations, reversals, and settlement adjustments MUST be documented by the implementation.

10.3 Concurrency Control

The implementation MUST prevent stale authorization decisions from being used to bypass an updated aggregate limit.

It SHOULD use one or more of:

• Atomic database transactions.
• Versioned authority records.
• Optimistic concurrency control.
• Serializable transaction processing.
• Distributed locking with documented failure semantics.

10.4 Idempotency

Each execution attempt SHOULD have an idempotency key.

A repeated request with the same idempotency key and identical material action parameters MUST NOT cause an unintended duplicate economic execution.

If the same key is reused with materially different parameters, the implementation MUST reject the request or require a new key.

Idempotency records MUST be retained for a documented period appropriate to the risk and transaction lifecycle.

11.1 Evidence Lifecycle

The proposed evidence lifecycle is:

Each stage MUST be distinguishable.

11.2 Evidence Record

An evidence record SHOULD include:

• Evidence identifier.
• Action identifier.
• Event identifier.
• Evidence type.
• Source system.
• Capture timestamp.
• Integrity reference.
• Verification status.

11.3 Integrity

Where cryptographic integrity protection is required, implementations MAY use established signing and canonicalization mechanisms.

For JSON-based cryptographic operations, RFC 8785 provides a JSON Canonicalization Scheme designed to produce a repeatable representation for hashing and signing.

Use of that scheme MUST be implemented according to its specification; merely hashing an arbitrary JSON serialization is not sufficient.

11.4 Verification Independence

An implementation SHOULD distinguish the system that performs an action from the system or process that verifies its outcome.

Where independent verification is unavailable, the outcome MUST be represented with an appropriate unresolved or unverified status.

11.5 Evidence Retention

Implementations MUST define:

• Evidence retention period.
• Access controls.
• Integrity protection.
• Audit access.
• Privacy restrictions.
• Deletion and legal-retention handling.

12.1 Version Identifier

The initial version is:

The "schema_version" field MUST identify the schema version used to interpret the document.

12.2 Versioning Policy

A future versioning policy SHOULD distinguish:

• Patch changes: clarifications or corrections without intended structural incompatibility.
• Minor changes: backward-compatible additions.
• Major changes: changes that may invalidate existing implementations or data.

The exact versioning policy remains subject to refinement.

12.3 Unknown Fields

In v0.1:

• Unknown top-level fields MUST be rejected.
• Implementation-specific extensions MUST be placed inside "extensions".
• Extension names SHOULD be namespaced.
• Implementations MUST NOT silently reinterpret unknown fields as authorization instructions.

12.4 Schema Migration

An implementation MUST NOT silently change the meaning of an existing field when migrating between schema versions.

A migration SHOULD preserve:

• Original action identifier.
• Original request.
• Authority references.
• Governance decisions.
• Execution history.
• Evidence provenance.
• Outcome records.

Level 1 - Structural Conformance

The implementation:

• Accepts valid v0.1 documents.
• Rejects structurally invalid documents.
• Enforces required fields.
• Validates basic data types and enumerations.

Level 2 - Semantic Conformance

The implementation:

• Validates authority-to-action relationships.
• Validates economic parameters.
• Validates policy references.
• Checks temporal authorization validity.
• Enforces governance decision consistency.

Level 3 - Execution Conformance

The implementation:

• Enforces the state machine.
• Revalidates authority at the execution boundary.
• Implements defined cancellation and revocation behavior.
• Prevents unintended duplicate execution.
• Handles concurrency and cumulative limits.

Level 4 - Evidence and Outcome Conformance

The implementation:

• Records traceable evidence.
• Distinguishes evidence capture from verification.
• Preserves execution history.
• Distinguishes execution completion from economic settlement.
• Supports outcome attribution.

15.1 Illustrative Test Case: Authorization Limit

Input

• Agent: Agent-Alpha-07
• Action: CAPITAL_ALLOCATION
• Requested amount: USD 15,000
• Authorized limit: USD 10,000
• Authority status: ACTIVE

Expected result

• Governance decision: REJECT
• Reason: REQUEST_EXCEEDS_AUTHORIZED_LIMIT
• Execution state: REJECTED
• Executed amount: USD 0
• Outcome: REJECTED

15.2 Illustrative Test Case: Revocation

Initial condition

• Authority status: ACTIVE
• Action state: AUTHORIZED
• Execution has not started.

Event

The authority grant is revoked.

Expected result

• Revocation event recorded.
• Authority revalidation fails.
• Execution is prevented.
• Action transitions to a defined non-executable state.

The implementation must document the exact state transition used for this case.

16.1 Reference Processing Sequence

• 1. Receive an economic-action request.
• 2. Parse the declared UEARM version.
• 3. Validate the document structure.
• 4. Validate semantic relationships.
• 5. Resolve identity and authority.
• 6. Evaluate policy and constraints.
• 7. Produce a governance decision.
• 8. Record the decision and its supporting references.
• 9. Revalidate authority at the execution boundary.
• 10. Apply concurrency and idempotency controls.
• 11. Execute the permitted action.
• 12. Record execution events.
• 13. Capture and validate evidence.
• 14. Verify the outcome.
• 15. Preserve the resulting action history.

Phase A - Schema Validation

Objective:

Verify that the JSON Schema accepts valid documents and rejects invalid structures.

Deliverables:

• Schema validator.
• Positive test fixtures.
• Negative test fixtures.
• Validation report.

Phase B - Semantic Validation

Objective:

Verify the consistency of action parameters, delegated authority, and policy constraints.

Deliverables:

• Authority-validation tests.
• Monetary-limit tests.
• Temporal-validity tests.
• Parameter-binding tests.

Phase C - Execution State Machine

Objective:

Verify permitted and prohibited state transitions.

Deliverables:

• State-transition implementation.
• Transition history.
• Invalid-transition test report.

Phase D - Revocation and Concurrency

Objective:

Evaluate revocation timing and cumulative authority enforcement.

Deliverables:

• Revocation test scenarios.
• Concurrent execution tests.
• Exposure calculations.
• Failure and recovery records.

Phase E - Evidence and Outcome Verification

Objective:

Evaluate whether the implementation can distinguish execution evidence from verified economic outcomes.

Deliverables:

• Evidence records.
• Verification results.
• Outcome attribution report.

Phase F - Comparative Evaluation

Objective:

Compare the proposed representation and implementation against relevant existing approaches.

Evaluation dimensions:

• Data-model completeness.
• Authorization consistency.
• Interoperability.
• Execution traceability.
• Revocation behavior.
• Concurrency handling.
• Verification coverage.
• Operational overhead.