The Economic Action Focus

1. Introduction

Artificial intelligence systems are increasingly being used not only to generate text, analyze information, or recommend decisions, but also to interact with systems capable of changing operational and economic states.

Depending on their tools, permissions, and deployment environments, AI agents may initiate payments, submit purchase orders, modify commercial records, allocate budgets, change prices, communicate offers, or execute multistep business workflows.

These developments introduce an evaluation question that cannot always be answered by measuring whether a model generated an accurate response:

A model may correctly interpret a request but lack the authority to perform it. An agent may possess valid credentials but attempt an action outside the intended scope of delegation. A series of individually permissible transactions may exceed an aggregate budget. An authorization may be valid when a request is prepared but no longer valid when it reaches an execution boundary. A tool may report success even though the intended purchase, transfer, delivery, or commercial outcome has not occurred.

These cases illustrate a distinction between the quality of an AI system’s output and the status of the economic action that the system initiates or influences.

Existing disciplines address important parts of this problem. AI-agent research examines tool use, planning, and autonomous behavior. Cybersecurity addresses identity, privilege, and attack surfaces. Access-control mechanisms express and enforce permissions. Distributed systems address concurrency, retries, consistency, and transaction state. Financial and enterprise systems implement approval rules, spending limits, settlement processes, and audit records. Risk-management frameworks organize the identification and treatment of AI-related risks.

Recent work also directly addresses relevant parts of agentic execution. NIST has examined tool-use taxonomies and the implications of tool permissions, stateful actions, reversibility, and monitoring [1]. Its National Cybersecurity Center of Excellence has explored identity and authorization approaches for software and AI agents [2]. Research such as The Authority Benchmark investigates whether agents follow specified rules, while APort Vault evaluates payment authorization by comparing agent behavior with and without a deterministic authorization check at the tool-execution boundary [3, 4].

This work establishes an important constraint on the present proposal: authorization, tool enforcement, and agent governance are already active research and engineering areas. The Economic Action Focus must therefore not be presented as though these subjects have been overlooked or as though a new architectural layer is inherently required.

Instead, this paper asks a narrower and testable question:

The proposal is complementary to model-centered and agent-centered evaluation. It seeks to connect the action’s economic context with the authority under which it is performed, the constraints applied during execution, the evidence available afterward, and the outcome that can be verified.

1.1 The central research question

The primary research question is:

This question has several possible answers.

First, action-level analysis may provide a useful common vocabulary for organizing existing mechanisms without requiring a new technical architecture.

Second, it may reveal that existing mechanisms already satisfy the relevant requirements when correctly configured and integrated.

Third, it may identify recurring constraints that are not adequately handled in particular environments and justify targeted engineering interventions.

Fourth, it may establish that certain interventions improve control effectiveness but impose costs in latency, integration complexity, operational burden, or legitimate task completion.

All four outcomes are useful research results. None should be excluded in advance.

1.2 Contributions of this paper

This paper makes six conceptual contributions:

1. It proposes consequential economic action as an explicit unit of analysis complementary to the model, agent, workflow, and system.
2. It distinguishes capability, economic agency, authority, governance, execution, evidence, verification, and economic outcome.
3. It introduces a provisional lifecycle for describing and testing economic actions.
4. It formulates testable propositions concerning authority, cumulative constraints, changing conditions, execution boundaries, evidence, and outcomes.
5. It outlines a comparative methodology designed to evaluate action-centered analysis against existing approaches.
6. It defines how Ouamarkom can organize a research program around evidence generation and engineering decisions without assuming the necessity of a predetermined protocol or infrastructure architecture.

The paper does not report completed experiments, establish a formal standard, demonstrate commercial demand, or claim that the Economic Action Focus has already been established as an independent scientific field.

2. Defining the Economic Action Focus

2.1 What is an economic action?

For the purposes of this research program, a consequential economic action is an action initiated, influenced, or executed by a system that can create, modify, transfer, constrain, or extinguish an economically relevant resource, state, right, obligation, price, or commercial relationship.

Examples include:

• Initiating or executing a financial transfer.
• Creating or submitting a purchase order.
• Committing or allocating a budget.
• Changing the price of a product or service.
• Accepting or transmitting a commercial offer.
• Modifying an inventory allocation.
• Initiating a contract renewal or cancellation.
• Changing a payment instruction or approved beneficiary.
• Delegating an economic action to another agent or service.

This definition is intentionally functional. It does not imply that every action has legal effect, that every tool call is an economic action, or that an AI system possesses legal personhood.

The relevant question is whether the action can produce or influence a defined economic consequence in the environment being studied.

2.2 The proposed unit of analysis

The proposed unit is not simply a model response, a tool call, or an isolated transaction record.

It is an economic action situated within a defined context, including:

• The intended purpose and economic object.
• The initiating actor and relevant principal.
• The authority and delegation conditions.
• The applicable policies and constraints.
• The initial and evolving economic state.
• The execution environment and relevant system boundaries.
• The action’s observable transitions.
• The evidence available to establish those transitions.
• The actual or expected economic outcome.

An action may comprise several technical events. A payment, for example, may involve preparation, submission, acceptance, settlement, reconciliation, and confirmation. Which event matters depends on the claim being evaluated.

The unit of analysis must therefore be defined relative to the research question. A single request may be sufficient for testing an amount limit. A sequence of requests may be necessary for testing cumulative exposure. A multistep workflow may be necessary for studying revocation or a delayed external outcome.

2.3 Why action-level analysis may add value

Model quality and agent performance remain essential, but they do not automatically establish the status of a consequential action.

A model may produce a correct recommendation while the execution system applies it incorrectly. An agent may complete a workflow while violating a cumulative constraint. An application may record an authorization decision without enforcing it at the relevant execution boundary. A tool may return a successful response without establishing that the intended economic outcome occurred.

Action-level analysis makes these distinctions explicit and tests whether they matter in practice.

The proposed focus is therefore not a replacement for existing research. It is a candidate method for connecting the properties of an AI-enabled action to the economic state it can change.

3. Conceptual Vocabulary

The framework distinguishes eight related concepts. Their precise operational definitions must be adapted to each experiment.

3.1 Capability

Capability refers to what a model or system can technically or operationally do.

Examples include generating a purchase order, calling a payment API, modifying a contract record, or planning a sequence of transactions.

Capability establishes a possibility of action. It does not independently establish permission to act.

3.2 Economic agency

Economic agency is used provisionally to describe a system’s capacity to participate in processes that initiate, influence, or execute consequential economic actions.

The term does not imply legal personhood, independent ownership, or an inherent right to exercise authority. An AI system may participate in economic agency through functions delegated by a human or organization while remaining subject to technical, organizational, contractual, and legal controls.

The research task is to define observable indicators of economic agency without conflating operational capability with legal status.

3.3 Authority

Authority refers to the recognized permission, delegation, or mandate under which an actor may perform a specified action.

Authority must be evaluated in relation to a principal, scope, purpose, applicable conditions, and relevant time period.

Credentials and access permissions may enable an action, but they do not necessarily establish that a specific transaction falls within the intended delegation.

An experiment should therefore specify the authority model it assumes and how compliance with that model will be measured.

3.4 Governance

Governance comprises the rules, decisions, controls, and oversight mechanisms that determine whether an action may proceed and how it should be constrained.

Governance may include automated policy checks, approval workflows, transaction limits, segregation of duties, escalation, monitoring, and revocation.

A written policy or recorded approval is not, by itself, proof that the execution environment enforced the relevant requirement.

The research must examine the relationship between policy, decision, enforcement, and observable outcome.

3.5 Decision

Decision refers to the disposition applied to a proposed action under the relevant authority and governance conditions.

Possible dispositions include admission, rejection, escalation, deferral, or conditional admission.

A decision is an event in the action lifecycle. Its correctness and its effectiveness must be evaluated separately: a correct decision may not be enforced correctly, while an enforced decision may implement an incorrect or incomplete policy.

3.6 Execution

Execution refers to the process through which an attempted action is carried out in an operational environment.

Depending on the system, execution may involve request submission, acceptance, commitment, settlement, delivery, or another state transition.

The research must identify the relevant execution boundary rather than assume that every system uses the same definition of completion.

3.7 Evidence and verification

Evidence consists of records or observations used to establish what was requested, authorized, attempted, accepted, executed, or observed afterward.

Verification is the evaluation of whether the available evidence supports a specific claim.

A system-generated success message may support the claim that a request was accepted by an interface. It may not establish settlement, delivery, fulfillment, or the intended economic outcome.

The adequacy of evidence depends on the claim, the system boundaries, the reliability and independence of the records, and the observation method.

3.8 Economic outcome

Economic outcome refers to the resulting change in an economic state or relationship.

Examples include a completed transfer, an incurred obligation, a purchase fulfilled, a price change applied, or a budget consumed.

The outcome may be intended, unintended, partial, delayed, disputed, reversed, or not verifiable with the available evidence.

Economic success must also be distinguished from task completion. An action may be correctly authorized and technically executed but still fail to produce the intended business result.

3.9 Summary of the conceptual distinctions

The framework proposes the following analytical distinctions:

• Capability does not, by itself, establish authority.
• Authority does not guarantee that applicable constraints will be enforced.
• An authorization decision does not prove that the execution environment applied it correctly.
• Technical execution does not establish the intended economic outcome.
• A reported outcome is not necessarily a verified outcome.
• A verified technical outcome does not, by itself, establish commercial value.

These distinctions are not claims that all existing systems fail at these boundaries. They are hypotheses and categories for structuring evaluation.

4. From Model-Centered Evaluation to Action-Centered Evaluation

Model-centered evaluation asks whether a model performs a task or produces an appropriate output. Agent-centered evaluation adds the behavior of the surrounding system, including planning, tool use, and workflow completion.

The Economic Action Focus proposes a complementary evaluation perspective: whether the consequential action was permitted, properly constrained, effectively executed, and verified against an appropriate economic outcome.

These perspectives overlap and should not be treated as mutually exclusive. Action-centered evaluation may use model traces and workflow records while adding evidence about the economic state and the validity of the action.

4.1 Example: cumulative purchasing authority

Assume an organization delegates the following authority to a procurement agent:

• Total budget: $100,000.
• Maximum individual purchase: $25,000.
• Eligible suppliers: a defined approved list.
• Purpose: procurement of specified equipment.
• Duration: a defined authorization period.

The agent executes four purchases of $25,000 each. Each purchase is individually within the transaction limit, and together they consume the entire budget.

A subsequent purchase request of $10,000 must be evaluated against the remaining authorized budget and any relevant pending commitments.

A model-centered evaluation might determine that the agent selected appropriate equipment and generated valid requests. An action-centered evaluation would also examine whether the system accounted for prior and pending commitments, enforced the aggregate limit, handled concurrent requests correctly, and retained sufficient evidence to reconstruct the decision.

The example illustrates a testable distinction: compliance at the individual transaction level does not necessarily establish compliance with an aggregate constraint.

It does not establish that existing procurement systems cannot enforce cumulative constraints. The experiment must determine how well the selected baseline already handles the case.

4.2 Example: revocation during execution

Assume an agent has valid authority to initiate a payment. During the workflow, the principal revokes that authority.

Several events may already have occurred: the request may have been prepared, submitted, accepted, committed, or settled.

Changing an authorization record to “revoked” does not, by itself, establish that the change prevented an action that remained preventable.

An action-centered experiment would define the relevant execution boundary and test whether revocation propagates to that boundary. It would distinguish:

• Prevention of an action that has not yet been submitted.
• Rejection of a submitted request that has not been accepted.
• Cancellation where the system permits cancellation.
• Containment of actions that cannot be cancelled.
• Remediation or compensation after an irreversible effect.

These outcomes are not equivalent. The correct treatment depends on the transaction’s state, system semantics, organizational policy, and applicable legal or contractual conditions.

4.3 Example: technical success without economic success

An agent submits a purchase order. The procurement API returns a successful response, but the supplier later rejects the order because the requested item is unavailable.

The request may have been technically accepted. The intended purchase was not fulfilled.

An evaluation that equates the successful API response with task completion may overstate the result. An action-centered evaluation would distinguish submission, acceptance, fulfillment, and the final economic outcome, requiring evidence appropriate to each claim.

This distinction is especially relevant when the outcome depends on external systems or events beyond the initiating agent’s control.

5. The Proposed Economic Action Lifecycle

The Economic Action Focus proposes the following provisional lifecycle:

Learning and reassessment may occur throughout the lifecycle.

The sequence is an analytical model, not a universal implementation order. Existing systems may combine stages, distribute them across services, or execute some checks continuously.

5.1 Intent

What action is proposed, for what purpose, and with what intended economic effect?

The intent may originate from a user instruction, business objective, workflow condition, or machine-readable request.

A broad objective should not automatically be treated as authorization for every action that might advance it.

5.2 Authority

Who delegated the relevant authority? Which actions, resources, counterparties, limits, and time periods does the delegation cover?

Can the system establish that the proposed action falls within the applicable mandate?

5.3 Governance

Which policies, approvals, and constraints apply?

Do the constraints concern individual transactions, cumulative exposure, counterparties, purpose, timing, or the current economic state? How are conflicts and changing conditions handled?

5.4 Decision

Is the action admitted, rejected, escalated, deferred, or allowed subject to additional conditions?

The decision must be evaluated against the applicable policy and state. Its existence alone does not establish that execution will respect it.

5.5 Execution

Where does the action become operationally effective? Which component enforces the relevant constraints?

How are retries, duplicate requests, concurrency, delayed processing, partial completion, and uncertain transaction states handled?

5.6 Evidence

Which records establish the authority, decision, execution events, and subsequent state changes?

Can the action sequence be reconstructed? Are the records sufficiently complete and reliable for the claim being evaluated?

5.7 Verification

What evidence is required to establish whether the relevant claim is true?

Verification may concern authorization, acceptance, execution, settlement, delivery, or another outcome. Each claim requires an appropriate evidentiary basis.

5.8 Economic outcome

What actually changed? Did the action produce the intended effect, a partial effect, an unintended consequence, or no effect?

What remains uncertain, reversible, disputed, or unverified?

The lifecycle provides a common structure for experiments and comparison. It does not establish that every stage requires a separate component or that a new architecture is needed to represent them.

6. Relationship to Existing Research

The Economic Action Focus must be evaluated against relevant prior work rather than described as an entirely unexplored domain.

NIST’s work on AI-agent tool use identifies dimensions including tool functionality, access patterns, risk, reliability, monitoring, autonomy, statefulness, and reversibility [1]. These dimensions overlap with several properties relevant to economic actions.

NIST NCCoE’s work on software and AI-agent identity and authorization examines how existing identity and authorization practices may be applied to agentic systems [2]. Such work is directly relevant to authority representation, enforcement, and auditability.

The Authority Benchmark evaluates whether agents follow operator-defined rules under specified scenarios and reports results for the configurations tested [3]. It demonstrates the relevance of empirically evaluating authority compliance rather than assuming that instructions alone determine behavior.

APort Vault, published as a 2026 preprint, evaluates payment authorization using replayed attacks across models and policy configurations, comparing execution with and without a deterministic authorization check [4]. Its methodology is particularly relevant because it distinguishes attempted requests, authorization decisions, and executed transfers rather than collapsing them into a single metric.

These sources constrain the claims that can responsibly be made about the Economic Action Focus.

The proposed contribution is not that authorization checks are new, that action-level measurement has never been attempted, or that a control layer is always necessary.

Instead, the research agenda is to investigate whether a broader economic-action-centered structure can provide additional value across different classes of actions and outcomes, including:

• Cumulative economic exposure across multiple transactions.
• Changes in authority and policy during execution.
• Differences between action acceptance, commitment, settlement, and fulfillment.
• Evidence sufficiency for claims about economic outcomes.
• Trade-offs between enforcement effectiveness and legitimate task completion.
• Replication across different economic domains and execution environments.

These are research directions, not established gaps in the literature. Their novelty and practical significance require a focused review of related benchmarks, authorization mechanisms, transaction systems, and evaluation methodologies.

7. Research Propositions

The following propositions are hypotheses to test. They are not empirical findings.

Proposition 1: Action-level analysis may reveal failures obscured by task-completion metrics

A system may complete a task while violating an authority constraint, exceeding an aggregate budget, or failing to produce the intended economic result.

Research question: Does action-level evaluation identify consequential failures that model- and agent-level metrics do not adequately capture?

Possible experiment: Apply model-, agent-, and action-centered evaluation to the same controlled scenarios. Compare failure classifications, detected violations, false alarms, and the conclusions supported by the evidence.

Evidence that would weaken the proposition: Existing evaluation methods consistently identify the same failures with equivalent accuracy and lower operational cost.

Proposition 2: Authority and execution may diverge under changing conditions

An action may be permitted when proposed but no longer permitted when it reaches the relevant execution boundary.

Research question: Under what conditions do changes in authority, policy, or economic state fail to propagate effectively to the point where an action can produce an effect?

Possible experiment: Introduce controlled revocation, expiry, and policy changes at predefined stages of a workflow. Measure the action’s state, the enforcement decision, and the resulting economic effect.

Evidence that would weaken the proposition: The selected baseline consistently enforces the relevant conditions at the correct boundary across the tested scenarios.

Proposition 3: Cumulative constraints may require state-aware evaluation

A sequence of individually permissible actions may violate a shared aggregate constraint.

Research question: Which existing mechanisms correctly enforce cumulative limits under sequential, concurrent, delayed, and retried execution?

Possible experiment: Compare single-action and multi-action scenarios, including pending commitments, duplicate requests, and concurrent transactions.

Evidence that would weaken the proposition: Existing mechanisms already maintain and enforce the relevant aggregate constraints under all tested conditions.

Proposition 4: Outcome verification may require evidence beyond the initiating system

An agent’s internal record may not establish what occurred in an external economic environment.

Research question: Which classes of economic actions require independent or external evidence to support claims about settlement, delivery, fulfillment, or commitment?

Possible experiment: Compare reported success with independently observable transaction states. Evaluate whether the evidence available to the initiating system supports each claimed outcome.

Evidence that would weaken the proposition: The initiating system’s records reliably establish the relevant outcomes for the tested action classes and threat model.

Proposition 5: Action-centered interventions may improve outcomes, but their costs matter

Additional controls may reduce unauthorized actions while increasing latency, false rejections, integration complexity, or operational burden.

Research question: Which interventions improve governed execution under which conditions, and at what cost?

Possible experiment: Compare a strong baseline with one or more specified interventions using predefined authorization, utility, latency, exposure, and cost measures.

Evidence that would weaken the proposition: The interventions provide no meaningful improvement or impose costs that outweigh the measured benefits.

Proposition 6: Some constraints may recur across models and execution environments

If the same failure classes recur across models and environments, the underlying constraint may not be specific to one model implementation.

Research question: Which observed failures generalize across models, applications, policies, and execution configurations?

Possible experiment: Replicate identical scenario definitions across multiple models and environments while documenting differences in permissions, policy enforcement, transaction semantics, and evidence availability.

Evidence that would weaken the proposition: The observed failures are specific to a narrow implementation and do not generalize beyond it.

Proposition 7: Action-centered measurement may improve the comparability of economic-execution research

Different evaluations may use inconsistent definitions of an attempted action, an authorized action, an executed transaction, and a verified outcome.

Research question: Does a common action-level measurement schema improve the consistency and reproducibility of results across experiments?

Possible experiment: Have independent evaluators apply the proposed schema to the same test corpus. Compare classification agreement, missing-data handling, and reproducibility.

Evidence that would weaken the proposition: Existing schemas provide equivalent consistency and interoperability without the proposed structure.

8. Experimental Methodology

The Economic Action Focus should earn its value through controlled comparisons with reasonable existing alternatives.

8.1 Define the experimental unit

Each experiment should define:

• The action and economic object.
• The initiating actor and relevant principal.
• The delegated authority and applicable conditions.
• The governing policy and constraints.
• The initial and evolving economic state.
• The execution environment and relevant system boundaries.
• The expected permissible and impermissible outcomes.
• The evidence required to evaluate each claim.
• The observation window.
• The criteria for pass, fail, and inconclusive results.

Where the research concerns cumulative authority, revocation, or concurrent execution, the experimental unit must include the relevant sequence of actions and state transitions.

8.2 Establish a strong baseline

Before proposing a new control or architecture, researchers should evaluate the best reasonable configuration of existing mechanisms for the scenario.

Depending on the environment, the baseline may include:

• Identity and access management.
• Application-level permissions.
• Transaction limits.
• Approval workflows.
• Policy enforcement at the execution interface.
• Idempotency and duplicate-request handling.
• Audit logs and transaction-state records.
• Existing financial or enterprise control mechanisms.

The baseline must be documented. A deliberately weak or incorrectly configured baseline cannot establish the value of a new intervention.

Where relevant, the comparison should separate a policy-design problem from an enforcement problem, a state-consistency problem, an evidence problem, or an outcome-verification problem.

8.3 Introduce controlled variations

Experiments may vary:

• Model or agent configuration.
• Authority scope and duration.
• Individual and cumulative transaction limits.
• Approved counterparties.
• Policy changes during execution.
• Revocation timing.
• Concurrent requests and retries.
• Service interruptions and partial failures.
• Availability of external outcome evidence.
• Human approval requirements.
• Existing controls versus specified alternative interventions.

These variations should be defined before testing and recorded in the experimental manifest.

8.4 Measure the action, not merely the request

Candidate measurement areas include:

Each metric requires an explicit denominator, observation window, event definition, missing-data rule, and failure classification.

Economic exposure requires particular care. A submitted request, an accepted order, a committed obligation, and a settled payment may represent different levels of exposure. The experiment should specify the valuation method rather than treating these states as financially equivalent.

8.5 Predefine result classifications

A proposed classification scheme is:

• PASS: The action satisfies the predefined requirements applicable to the test.
• CONDITIONAL PASS: The action satisfies the criteria subject to an explicitly permitted condition.
• FAIL: The action violates a predefined requirement or fails a required control or outcome.
• INCONCLUSIVE: The available evidence is insufficient to determine whether the relevant criteria were satisfied.

A missing record is not automatically proof that an action was unauthorized. Equally, missing evidence is not proof that the action was properly governed.

The classification must match the claim being tested. For example, a test of authorization enforcement should not be scored solely on whether the agent verbally refused a request; the relevant outcome is whether the prohibited action crossed the specified execution boundary.

8.6 Use independent and observable outcomes where feasible

Whenever possible, the primary outcome should be derived from observable system state or independently verifiable records rather than from the agent’s own narrative about what happened.

This does not mean every experiment requires a separate external auditor or a real-world financial transaction. A controlled simulator may provide a reliable ground truth for the specific state transitions it models.

The report must nevertheless distinguish simulated outcomes from real-world settlement, fulfillment, legal effect, or commercial value.

8.7 Replicate and report limitations

Where feasible, experiments should be repeated across configurations and evaluated by researchers who did not design the intervention.

Reports should disclose scenario definitions, system versions, policies, metrics, exclusions, missing data, failures, limitations, and deviations from the protocol.

Negative results should be retained when methodologically sound. Evidence that existing mechanisms are sufficient is directly relevant to the engineering decision.

9. A Research Program for Ouamarkom™

Ouamarkom positions the Economic Action Focus as a proposed orientation for a research and engineering program investigating the conditions under which AI systems participate in consequential economic activity through bounded, governed, and verifiable actions.

The program is organized around a disciplined progression from questions to evidence and from evidence to engineering decisions.

9.1 Economic Action Focus: the research object

The Economic Action Focus identifies the consequential economic action as the central object to be examined.

It defines what is being studied and which properties may require measurement. It does not prescribe a specific product, protocol, or architecture.

9.2 CE-AI™: the analytical framework

The Command Economy of AI (CE-AI™) is Ouamarkom’s proposed research framework for analyzing the economic implications of AI participation through commands, delegated authority, governed execution, and verifiable outcomes.

It provides a conceptual context for examining the relationship between AI capability, economic agency, authority, governance, execution, and economic consequence.

CE-AI is a research framework under development, not an established scientific standard or a claim that a new economic system has replaced existing market arrangements.

9.3 Economic Action Engineering: the engineering research direction

Economic Action Engineering is the proposed engineering direction through which observations about consequential actions are translated into testable interventions.

Its role is to investigate how action constraints can be represented, measured, enforced, and verified in specific environments.

It should not be presented as an established independent discipline before its methods, results, and boundaries have been demonstrated through research and external engagement.

9.4 Economic Action Lab: the experimental environment

The Economic Action Lab is the proposed environment or program for controlled experiments on governed economic execution.

Its purpose is to support repeatable scenarios, instrumented action lifecycles, comparison with baseline mechanisms, and evidence collection.

Any claims about its operational maturity should reflect what has actually been built and tested.

9.5 GEAB: the proposed benchmark family

The Governed Economic Action Benchmark (GEAB) is a proposed family of tests and measures for evaluating defined properties of economic actions.

Initial candidate scenarios include:

• Authority boundaries and transaction limits.
• Cumulative economic exposure.
• Revocation and changing authority.
• Execution-state transitions.
• Evidence completeness and outcome verification.

Each benchmark should have a defined purpose, test manifest, initial state, event schema, metrics, expected results, and reproducibility requirements.

A benchmark becomes credible through transparent specifications, reliable implementation, baseline comparisons, repeated evaluation, and independent scrutiny-not through its name alone.

9.6 CEP: an intervention hypothesis

The Command Execution Protocol (CEP) is a proposed protocol hypothesis that may be investigated if experiments identify a recurring need for an additional enforcement or execution mechanism.

CEP should be compared with existing policy engines, identity systems, access-control mechanisms, transaction controls, and integration approaches.

Its continued development should depend on evidence that it provides measurable benefits that cannot be achieved as effectively through existing mechanisms or simpler interventions.

No claim of universal necessity, formal standardization, or demonstrated performance should be made without supporting evidence.

9.7 The evidence-to-decision rule

The program follows this research logic:

The sequence is a decision discipline rather than a claim that every project must progress linearly.

Its core rules are:

• No strong claim without adequate evidence.
• No new architecture without a defined and recurring constraint.
• No reusable mechanism without evidence of reuse across relevant cases.
• No broad generalization without replication.
• No commercial product claim without evidence of customer value.
• No infrastructure commitment without a demonstrated need that justifies its cost.

The research should remain capable of concluding that a proposed intervention is unnecessary.

10. Priorities for Initial Experimental Work

A focused research program should begin with a small number of experiments that expose clearly defined action-level questions.

10.1 Experiment A: cumulative economic exposure

Question: Can the evaluated system correctly enforce aggregate economic limits across related actions, including pending and concurrent transactions?

The experiment should compare a strong baseline with explicitly defined alternative configurations. It should measure constraint violations, legitimate task completion, latency, and the accuracy of exposure calculations.

10.2 Experiment B: revocation and the execution boundary

Question: When authority changes, at what point does that change become effective in the execution environment?

The experiment should distinguish unsubmitted requests, submitted requests, accepted transactions, committed obligations, and completed actions. It should measure prevention, cancellation, containment, and remediation separately where applicable.

10.3 Experiment C: outcome verification

Question: What evidence is necessary to establish that an economic action produced its claimed result?

The experiment should compare agent-reported success with observable transaction or business-system states. It should distinguish the claims that can be supported by internal logs from those requiring external confirmation.

These experiments are proposed research priorities, not reports of completed validation. Their order may change if a literature review, technical feasibility assessment, or access to representative environments identifies a more valuable starting point.

11. Criteria for Establishing Research Value

The Economic Action Focus should not be judged by the novelty of its terminology. Its value depends on whether it produces demonstrable improvements in research or engineering practice.

11.1 Additional explanatory value

The framework identifies meaningful distinctions or failure modes that existing evaluation methods do not adequately capture.

11.2 Improved measurement

The framework supports clearer, reproducible measures of authority, enforcement, exposure, execution state, and outcome verification.

11.3 Practical intervention value

An intervention developed through the framework improves relevant outcomes compared with a strong baseline, with costs and trade-offs measured.

11.4 Reproducibility

Independent evaluators can reproduce the relevant results from the published protocol, scenario definitions, and data available to them.

11.5 Bounded generalizability

Findings remain meaningful across more than one relevant configuration or environment, within a clearly specified scope.

11.6 Decision value

The framework helps determine whether the appropriate response is to improve an existing control, integrate existing mechanisms, develop a reusable intervention, or investigate a broader architectural change.

These forms of evidence are distinct. A useful taxonomy does not prove that a new protocol is necessary. A successful intervention in one environment does not establish universal generality. A technically effective control does not establish that customers will pay for it.

Conclusions must remain proportionate to the evidence.

12. Limitations and Research Boundaries

12.1 The framework does not replace model research

Reasoning, robustness, alignment, reliability, and model capability remain important. Action-centered evaluation complements these perspectives.

12.2 Not every AI action is an economic action

The framework is most relevant where actions can affect money, assets, obligations, prices, procurement, contracts, resource allocation, or other defined economic states.

The operational boundary of the category requires further specification.

12.3 Authority is context-dependent

Authority may depend on law, organizational policy, contracts, institutional arrangements, and technical configuration.

A research experiment must specify its authority model rather than assume that one representation resolves every context.

12.4 Existing mechanisms may be sufficient

Identity systems, access-control mechanisms, transaction processors, workflow engines, financial controls, and audit systems may already satisfy the relevant requirements in a particular environment.

The burden is to demonstrate a measurable gap, not to assume one.

12.5 A new protocol or infrastructure layer is not a predetermined outcome

A distinct protocol, gateway, reusable primitive, or infrastructure layer requires evidence of recurring need, measurable benefit, and practical advantage over alternatives.

The research may be valuable even if the eventual solution consists of better configuration, improved integration, or a more precise evaluation method.

12.6 Generalization requires evidence

Results from a limited number of models, scenarios, or execution environments cannot automatically be generalized to all AI systems or economic contexts.

12.7 The framework does not settle legal responsibility

Technical authorization, organizational approval, contractual authority, and legal responsibility are related but distinct questions.

The framework can help document and evaluate technical and operational conditions. It does not independently determine legal liability, contractual enforceability, or legal personhood.

12.8 Economic outcomes may be difficult to attribute

A successful business outcome may depend on market conditions, supplier behavior, human intervention, timing, or other factors beyond the AI system.

Experiments must distinguish whether they evaluate action correctness, execution effectiveness, economic outcome, or causal contribution to a business result.

13. Implications for AI Research and Engineering

If the Economic Action Focus proves useful, it may change how certain AI-enabled workflows are evaluated.

Instead of asking only whether an agent can complete a purchase, researchers could examine whether the purchase is within the relevant authority, whether aggregate commitments are correctly accounted for, whether execution enforces the applicable constraints, and whether the resulting state can be verified.

Instead of treating revocation as a change in configuration, researchers could evaluate whether it takes effect at the relevant execution boundary.

Instead of equating a successful tool response with completion, researchers could distinguish the action requested, the action accepted, the action executed, and the economic outcome verified.

Instead of assuming that a control is valuable because it blocks unauthorized actions, researchers could also measure legitimate task completion, false rejection, latency, integration cost, and operational complexity.

The wider methodological principle is that the unit of evaluation should match the claim being made.

A claim about model quality requires model-level evidence. A claim about workflow completion requires workflow-level evidence. A claim about governed economic execution requires evidence about authority, constraints, enforcement, execution state, and the relevant economic outcome.

This principle does not dictate a universal technical architecture. It defines a research obligation: evaluate the system at the level required to substantiate the claim.

14. Conclusion

As AI systems become capable of initiating and executing consequential actions, evaluating their outputs alone may not be sufficient to establish whether those actions were properly governed or whether their intended economic effects occurred.

The Economic Action Focus proposes that the consequential economic action may serve as a useful explicit unit of analysis-one that connects system capability to authority, governance, execution, evidence, verification, and economic outcome.

The proposal is deliberately bounded. It does not claim that existing disciplines lack the necessary concepts, that a new scientific field has already been established, or that an independent infrastructure layer must be built.

Related work on tool-use evaluation, agent identity, authorization, and payment enforcement demonstrates that important parts of this problem are already being investigated. The contribution of Ouamarkom must therefore be established through a focused comparison with that work and through experiments that demonstrate what the proposed approach adds.

The central test is whether action-level analysis provides additional explanatory value, more reliable measurement, or better practical outcomes than existing approaches-and whether those benefits persist under replication.

If existing mechanisms prove sufficient, the research should say so. If integration is enough, the solution should remain proportionate. If recurring constraints justify new mechanisms, their necessity should be demonstrated rather than assumed.

For Ouamarkom, the Economic Action Focus is therefore a starting point for disciplined research, not a declaration of a completed category or architecture.

References