Where does a mismatch workflow sit in an environment's architecture?

A mismatch workflow usually maps onto four layers in an environment.

**State stores.** Two or more tables or services hold the overlapping facts, for example a billing store and a payments store in a utility. Each has its own keys, so the link between them is a field the agent must discover, such as an external reference or account number with formatting differences.

**Tool surface.** Typical actions are search_records, get_record, list_adjustments, post_adjustment, reverse_entry, raise_query, add_case_note, escalate_case and close_case. Read tools should return partial views, so the agent has to make several calls to build the picture.

**Case layer.** A case record holds the pair of record IDs, the observed difference, status, owner and a note history. Status transitions are constrained, for instance a case cannot close while a query is open.

**Policy layer.** Tolerances, approval limits and ownership rules sit as data the agent can read, not as hidden logic. Write tools check them and return typed errors such as APPROVAL_REQUIRED or NOT_OWNER.

A task pack points at this environment by naming the case ID, the starting snapshot and the grading hooks. Because the content is generated, snapshots can be produced as consistent sets with the break already planted and the cause recoverable from the data. A buyer should confirm during a pilot that key formats, error codes and tool names can be mapped onto their own harness.