Defining the authorization oracle for mixed-object batch requests

Goal

Expose ambiguous access rules in batch operations before an agent writes tests that approve whichever response the implementation happens to return. The proposal focuses on mixed ownership within one request.

Prerequisites

In an authorized disposable application, create synthetic documents belonging to separate accounts. Agree whether a batch operation is atomic, partially successful, or rejected whenever any requested object is inaccessible.

Steps

1. Write the expected response and stored state for an all-owned batch. Execute that control and verify each requested effect through a separate read using the document owner.

2. Construct a mixed batch with an owned document and an inaccessible document. State the expected outcome before execution, including whether the owned document is allowed to change.

3. Repeat the mixed fixture with the document order reversed. Compare decisions, returned identifiers, and committed changes; ordering should not select a different policy unless the contract explicitly defines it.

4. Add a nonexistent synthetic identifier as a separate case. Decide whether absence and denied access must be indistinguishable, and inspect per-item details rather than only the overall status.

5. After a repair, inspect every document through its authorized owner. Preserve an all-owned control so that a blanket rejection cannot masquerade as correct object authorization.

Expected result

Every batch case should have an explicit response expectation and a matching state expectation. Unexpected partial writes become visible even when the outer request reports failure.

Limits and test basis

Do not infer atomicity from the transport status. This method does not test database transaction isolation; it tests the declared authorization behavior observable to callers. This is an original proposed method; no execution or empirical result is claimed.