What one customer submission writes

A repository comes with git and usually a test suite. Ordinary business software does not come with a grader for each workflow. To test the same state-difference method there, we use Dolibarr, an open-source ERP, without modifying the application. The harness performs the workflow through an HTTP form submission and reads durable state directly from the database.

The precondition is reproducibility

A state difference can define success only if the same workflow produces the same durable outcome from the same reset. The check restores a known state, submits the customer ProbeCustomer through the application's HTTP form, reads the resulting database delta, and repeats.

run 1   ProbeCustomer   3 rows created   llx_societe, llx_actioncomm, llx_actioncomm_resources
run 2   ProbeCustomer   3 rows created   llx_societe, llx_actioncomm, llx_actioncomm_resources
run 3   ProbeCustomer   3 rows created   llx_societe, llx_actioncomm, llx_actioncomm_resources

3 of 3 normalized deltas are byte-identical

Timestamps and long epoch values are normalized before comparison. The underlying rows and relationships are read directly from the application database.

The cascade is the useful evidence

The visible request is to create a customer. The durable outcome is larger: Dolibarr writes the customer row, an audit event for company creation, and a resource row that binds the event to its user.

what a person submits            what the HTTP form submission wrote

ProbeCustomer exists      →     llx_societe
                          +     llx_actioncomm          AC_COMPANY_CREATE
                          +     llx_actioncomm_resources  user link

The two extra rows are precisely the kind of consequences a hand-authored check can omit. A state-derived grader does not need someone to remember them in advance: the demonstrated workflow makes them visible.

What is excluded

A second workflow creates a customer and then attempts to raise a proposal against it. The first step writes its expected rows; the second currently writes nothing. That workflow is excluded rather than presented as a successful environment. Deterministic failure is not a valid target state.

What this establishes

This is a substrate result, not an agent-training result. It establishes that an unmodified business application can expose a reproducible, multi-table state difference from one real workflow. No agent has been trained on this workflow, and the result does not claim that all workflows are deterministic.

See the public coding measurements for the same state-channel idea applied to replayed software trajectories.