DM11 AUTONOMOUS TRANSACTION ASSURANCE
An AI agent's bulk update went half-through. Here is what happened.

THE ACTION
  An AI agent changed customer state across 3 business systems (Billing, CRM, Entitlement).

WHAT EACH SYSTEM REPORTED
  Billing     UPDATE     records 5000   returned success
  CRM         UPDATE     records 5000   returned success
  Entitlement UPDATE     records 5000   returned success
  A dashboard reading these API responses marks the run complete.
  Most agent stacks stop here.

WHAT DM11 DID INSTEAD
  Before executing: the transaction had to satisfy assurance profile BUSINESS_WRITE
  (5 requirements, 5 satisfied). Without them it cannot reach an
  executable state.
  After executing: DM11 measured the 6 declared postconditions against
  each system's real state. 5 were met, 1 was not — so the transaction was
  REFUSED the VERIFIED state. It could not report success.
  DM11 then ran 4 compensating steps and re-measured.

THE OUTCOME, ON THREE SEPARATE AXES
  Action RECOVERED / Settlement PARTIALLY_SETTLED / Outcome OUTCOME_UNKNOWN
  Not one status: a finished action can leave the business half-settled,
  and the result unknown.

WHAT YOU CAN HAND TO SOMEONE ELSE
  A Reality Receipt (dm11.reality_receipt 2.1, hash 97233f4fe6f6) over a 15-entry
  tamper-evident trail, checkable by a standalone validator that imports
  no DM11 code.

WHAT THIS RUN DOES NOT SHOW — data origin SYNTHETIC_DEMO
  - Measured on synthetic systems. Not run against a real CRM, billing platform or entitlement service.
  - No customer business result measured (churn, revenue) — outcome_status is OUTCOME_UNKNOWN.
  - Economic exposure cannot be measured on synthetic data.
  - No exactly-once claim. What is shown is that a repeat of the same idempotency key added no further side effects.
  - Latency and throughput were not measured; that is not what this run is for.

  A hash proves the record was not altered — not that the business state
  is what the record says. DM11 keeps those claims separate.