---
id: TST-ACC-BAT-124
title: Batch rules submission execution split
kind: unit
product_area: accounting
module: batches
revision: 1
status: draft
product_intent: proposed
implementation_evidence: observed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - modules/batches/tests/unit/jobs/submission-execution-split.spec.js
implements:
  - ATS-ACC-BAT-012-01
environment: mock
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: Each case owns its supplied rule inputs and test doubles.
assertion_sources:
  - scenario: ATS-ACC-BAT-012-01
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/unit/jobs/submission-execution-split.spec.js#refuses
      a preview naming no batch, more than 100, or no tenant
evidence:
  - provenance: observed
    source: >-
      services-accounting:modules/batches/tests/unit/jobs/submission-execution-split.spec.js
    note: >-
      The executable file is inspected at the pinned revision; duration is an
      unmeasured planning estimate.
  - provenance: documented
    source: >-
      services-accounting:modules/batches/tests/unit/jobs/submission-execution-split.spec.js#suite
      header
    note: >-
      The graph and the registration are read in a child process, so the module
      cache and the job type registry are fresh. Real: the
  - provenance: documented
    source: >-
      services-accounting:modules/batches/tests/unit/jobs/submission-execution-split.spec.js#suite
      header
    note: >-
      modules, the registry, the handler, the requester. Doubled: the Lambda
      client and the in-process invoker (each case's own), and the
unbound_scope: null
---

# Batch rules submission execution split

## Verification Boundary

This suite exercises the named rule functions with controlled inputs. Its boundary ends before persistent accounting and deployed execution.

## What This Suite Proves

Submission and execution are checked as separate boundaries so returning a tracked request does not imply accounting has completed. The assertion anchors identify the supported portions of the bound scenarios.

## What It Does Not Prove

These checks do not prove transport authorization, transactional storage, scheduling delivery or the whole feature workflow.

## Real Dependencies and Test Doubles

The rule inputs and dependency callbacks are controlled by the case. Database, API dispatch and workflow delivery are outside this boundary.

## Must Not Be Doubled

Qualifying transactional integrity requires real storage and accounting execution beyond this rule-only suite.