WEB / WEB-16.S05

Business invariants and workflow state machines

Read domain decisions through state, authority and effect outcomes.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Reservation allow

Command prepared
The client prepared copy-A intent with quantity=1, expectedRevision=7 and commandId=reservation-A. Price, role and current state remain server authority; the service has not received the command.
Client
reservation-A; copy-A; quantity=1; expectedRevision=7
Workflow service
Current gate pending
Catalog store
Available; revision 7; no receipt
Service received command
The service received the ordinary reservation command; an old page or command key cannot replace current authorization.
Client
Reservation command ready
Workflow service
Command arrived; current gate pending
Catalog store
Available; revision 7; no receipt
Current gate decision
Current permission supplied evidence passed; state and revision are still checked separately in the store transaction.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Available; revision 7; no receipt
Local store invocation
The service passed the bound command locally to its in-memory SQLite store. This is not a network packet; conditional-guard, committed-write and receipt outcomes are still pending.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Command arrived; transaction condition pending
Local transaction outcome
The conditional update and receipt committed in one local transaction; revision 8 and one effect resulted.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Reserved; revision 8; receipt ready
Local transaction result
The service obtained the committed receipt from the same-process store call and prepared the client reply. This local return is not response arrival at the client.
Client
Reservation command ready
Workflow service
Committed receipt arrived; client reply ready
Catalog store
Reserved; revision 8; receipt ready
Client received outcome
The client received the committed reservation receipt; retrying the same command still requires current permission.
Client
Receipt arrived; one committed effect
Workflow service
Committed receipt arrived; client reply ready
Catalog store
Reserved; revision 8; receipt ready
Local outcome record
The client recorded the supplied outcome locally; this step performs no new write or external effect.
Client
Committed receipt recorded locally; one effect
Workflow service
Committed receipt arrived; client reply ready
Catalog store
Reserved; revision 8; receipt ready

Revision stale

Command prepared
The client prepared copy-A intent with quantity=1, expectedRevision=6 and commandId=reservation-A. Price, role and current state remain server authority; the service has not received the command.
Client
reservation-A; copy-A; quantity=1; expectedRevision=6
Workflow service
Current gate pending
Catalog store
Available; revision 7; no receipt
Service received command
The service received the ordinary reservation command; an old page or command key cannot replace current authorization.
Client
Reservation command ready
Workflow service
Command arrived; current gate pending
Catalog store
Available; revision 7; no receipt
Current gate decision
Current permission supplied evidence passed; state and revision are still checked separately in the store transaction.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Available; revision 7; no receipt
Local store invocation
The service passed the bound command locally to its in-memory SQLite store. This is not a network packet; conditional-guard, committed-write and receipt outcomes are still pending.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Command arrived; transaction condition pending
Local transaction outcome
Expected revision=6 does not match current revision=7. The conditional update affects zero rows; state stays available and no receipt is created.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Available; revision 7; denial ready; no receipt
Local transaction result
The service obtained the negative result from its local store call. No committed receipt exists; a client denial is ready but has not reached the client yet.
Client
Reservation command ready
Workflow service
Denial arrived; no-write/no-body decision ready
Catalog store
Available; revision 7; denial ready; no receipt
Client received outcome
The client received the negative outcome; original available state remained, with no receipt body or committed write.
Client
Denial arrived; no body/delivery/committed write
Workflow service
Denial arrived; no-write/no-body decision ready
Catalog store
Available; revision 7; denial ready; no receipt
Local outcome record
The client recorded the supplied outcome locally; this step performs no new write or external effect.
Client
Denial recorded locally; no new receipt/body
Workflow service
Denial arrived; no-write/no-body decision ready
Catalog store
Available; revision 7; denial ready; no receipt

Permission missing

Command prepared
The client prepared copy-A intent with quantity=1, expectedRevision=7 and commandId=reservation-A. Price, role and current state remain server authority; the service has not received the command.
Client
reservation-A; copy-A; quantity=1; expectedRevision=7
Workflow service
Current gate pending
Catalog store
Available; revision 7; no receipt
Service received command
The service received the ordinary reservation command; an old page or command key cannot replace current authorization.
Client
Reservation command ready
Workflow service
Command arrived; current gate pending
Catalog store
Available; revision 7; no receipt
Current gate decision
Current permission evidence is absent; no-write and no-body were decided before dispatch into the command store.
Client
Reservation command ready
Workflow service
Permission unknown; denial ready; no receipt
Catalog store
Available; revision 7; no receipt
Client received denial
The client received only denial for missing current permission; no store dispatch, receipt body or committed write occurred.
Client
Denial arrived; no body/delivery/committed write
Workflow service
Permission unknown; denial ready; no receipt
Catalog store
Available; revision 7; no receipt

Rollback decision

Command prepared
The client prepared copy-A intent with quantity=1, expectedRevision=7 and commandId=reservation-A. Price, role and current state remain server authority; the service has not received the command.
Client
reservation-A; copy-A; quantity=1; expectedRevision=7
Workflow service
Current gate pending
Catalog store
Available; revision 7; no receipt
Service received command
The service received the ordinary reservation command; an old page or command key cannot replace current authorization.
Client
Reservation command ready
Workflow service
Command arrived; current gate pending
Catalog store
Available; revision 7; no receipt
Current gate decision
Current permission supplied evidence passed; state and revision are still checked separately in the store transaction.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Available; revision 7; no receipt
Local store invocation
The service passed the bound command locally to its in-memory SQLite store. This is not a network packet; conditional-guard, committed-write and receipt outcomes are still pending.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Command arrived; transaction condition pending
Local transaction outcome
After the controlled failure inside the transaction, an explicit rollback runs. State stays available at revision=7; no new committed effect or receipt is created.
Client
Reservation command ready
Workflow service
Current permission accepted; store command ready
Catalog store
Available; revision 7; denial ready; no receipt
Local transaction result
The service obtained the negative result from its local store call. No committed receipt exists; a client denial is ready but has not reached the client yet.
Client
Reservation command ready
Workflow service
Denial arrived; no-write/no-body decision ready
Catalog store
Available; revision 7; denial ready; no receipt
Client received outcome
The client received the negative outcome; original available state remained, with no receipt body or committed write.
Client
Denial arrived; no body/delivery/committed write
Workflow service
Denial arrived; no-write/no-body decision ready
Catalog store
Available; revision 7; denial ready; no receipt
Local outcome record
The client recorded the supplied outcome locally; this step performs no new write or external effect.
Client
Denial recorded locally; no new receipt/body
Workflow service
Denial arrived; no-write/no-body decision ready
Catalog store
Available; revision 7; denial ready; no receipt

ACTORS · STATE · DATA FLOW

Invariant, transition and authority

A business invariant is a domain condition that must remain true after every accepted operation. In a one-copy catalog, remaining capacity cannot become negative, one copy cannot have two active reservation owners, and a completed command cannot create a second effect. A workflow state machine expresses these conditions using state, action and guards. The available -> reserved transition requires current permission, quantity, capacity and revision checks.

The client declares intent: copy-A, quantity 1, expectedRevision 7 and commandId reservation-A. It is not authoritative for price, role or current state. The artifact’s 12 fictional priceUnits belong to the server catalog record and are neither money nor payment. The reader-reserver role comes from verified server context and available state from the store. Schema validation checks input shape without authorizing replacement of these three authorities with client values.

Revision and idempotency solve different problems

Revision 7 identifies the state on which this command intends to decide. A conditional update changes one row only when current revision is 7 and state is available; zero affected rows means the stale decision produces no write. The guard and write share a transaction boundary. Successful commit advances revision to 8 and records the receipt. The local SQLite fixture runs sequentially and tests neither parallel requests, every isolation mode nor distributed locking.

Idempotency is a contract that reconsidering the same logical command does not multiply its effect. Bind the command key to the authenticated actor, action, resource and normalized parameters. A repeated retained command requires current permission; returning its accepted receipt creates no second reservation. Different parameters do not give the same command a new meaning. Possession of a key grants no permission. Safe retry is not automatically established after retention expires or an external outcome becomes unknown.

Comparing invite, booking, coupon and recovery

An invite needs pending, unexpired state bound to a designated recipient and workspace. Booking consumes availability using current capacity and an authorized reserver. A coupon needs eligibility, approved terms, remaining uses and a validity period; a client-requested benefit is not itself a server condition. Recovery has a different purpose: account-bound verified evidence and an unexpired, unused transaction. A normal login role is not substituted for recovery proof.

These four flows can have similarly named guards while their objects and evidence sources differ. FlowFamilies is not an engine implementation; it helps derive each operation’s domain contract. No credential, real recovery link or code is produced; no invitation is sent and no coupon or payment is used. The common lesson is to bind transitions to purpose and current actor while distinguishing one-time effects from idempotent receipts.

Read every scenario without motion

Stale revision

Reservation conditions were established
Duru requests reserve for copy-A with quantity=1. The current record is available at revision=7, while the command expects revision=6.
Command conditions
Expected revision=6
Transition and record
Current: available, rev=7
Receipt boundary
Receipt not prepared
Permission and revision were separated
This row has currentPermissionDeclared=true. Permission is not the rejection cause; even an authorized actor must match the current revision.
Command conditions
Expected revision=6
Transition and record
Permission=true
Receipt boundary
Dispatch pending
The first transition boundary was applied
Dispatch occurs but the conditional revision check mismatches. expectedCommittedWrite=false; the available record does not become reserved.
Command conditions
Expected revision=6
Transition and record
Dispatch=true; commit=false
Receipt boundary
Body=null
State and revision were preserved
The final state is available at revision 7. Correct quantity or commandId cannot replace the revision precondition.
Command conditions
Expected revision=6
Transition and record
Available; revision=7
Receipt boundary
No reserved body
No success receipt was supplied
expectedReceiptDelivery=false and expectedBody=null. The resource remaining available does not make this stale command successful.
Command conditions
Expected revision=6
Transition and record
No commit
Receipt boundary
Receipt delivery=false
The denial reason was interpreted narrowly
This row shows a known revision mismatch. It alone establishes neither malicious intent nor general correctness of concurrency isolation.
Command conditions
Expected revision=6
Transition and record
State unchanged
Receipt boundary
Known denial / missing evidence separate

Permission missing

Reservation conditions were established
Duru requests reserve for copy-A, but currentPermissionDeclared=null. An available record does not complete missing permission evidence.
Command conditions
Permission=null
Transition and record
Current: available, rev=7
Receipt boundary
Receipt not prepared
Permission and revision were separated
Null is not the same record as verified false permission. Since the gate cannot be resolved, reserve is not started using guessed authority.
Command conditions
Permission=null
Transition and record
Permission evidence missing
Receipt boundary
Dispatch pending
The first transition boundary was applied
expectedDispatch=false remains. Without permission evidence, processing does not reach the transaction or reserve effect and creates no receipt.
Command conditions
Permission=null
Transition and record
Dispatch=false; commit=false
Receipt boundary
Body=null
State and revision were preserved
The final state remains available at revision 7. Caller-provided role or priceUnits cannot replace server identity and catalog authority.
Command conditions
Permission=null
Transition and record
Available; revision=7
Receipt boundary
No reserved body
No success receipt was supplied
expectedReceiptDelivery=false and expectedBody=null remain. Missing permission is not converted to allow using an earlier receipt or command key.
Command conditions
Permission=null
Transition and record
No commit
Receipt boundary
Receipt delivery=false
The denial reason was interpreted narrowly
The known result is withheld dispatch and write; the actor’s actual permission outcome is unknown. Missing evidence is not automatically malicious intent or verified denial.
Command conditions
Permission=null
Transition and record
State unchanged
Receipt boundary
Known denial / missing evidence separate

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: the right sequence grants domain permission

The Red perspective does not treat following screen order as authorization evidence. Seeing an available page proves neither current reservation state nor actor permission. Permission-missing carries null evidence; it is not claimed false, but lacks the positive evidence needed to write. Denial is prepared before dispatch into the command store, with no receipt or public result body.

Stale-revision shows a different failure boundary. Actor permission exists and the command reaches the store, but the current revision is 7 rather than the expected 6, so the conditional write affects zero rows. This is not a permission denial and the copy remains unchanged. A domain review records the correct failure reason: identity, state and commit are not interchangeable. The lesson executes no race attempt against a real booking or payment system.

Broken assumption: attempting an effect completes success

In effect-failed, the local transaction performs an explicit rollback after a controlled failure. Return a receipt only after commit; an unsuccessful attempt must not produce a reserved body. This fixture knows the rollback outcome. The conceptual external-result-absent row instead carries null commitEvidence: a lost response does not establish that no write occurred. A local transaction cannot make another service’s effect atomic.

An idempotency review also checks that a retained receipt is not returned before current authorization. A previously successful command does not permit delivery of a receipt to an actor whose permission is now denied. The same command ID with a different resource or quantity is not silently matched to the old result. Impact review separates an actual outcome from unknown evidence without creating arbitrary parallel operations, consuming coupons or attempting recovery.

Read every scenario without motion

Receipt authority

The retained command record was read
reservation-A previously produced one effect. The idempotency ledger shows its retained result with effects=1; avoiding another effect is a separate property.
Workflow observation
Command: reservation-A
Tuple comparison
Historical effects=1
Review decision
New receipt pending
The current permission record was selected
The same-command permission-denied row has currentPermission=false. Matching parameters do not make earlier acceptance grant current resource permission.
Workflow observation
Current permission=false
Tuple comparison
Same parameters=true
Review decision
Receipt gate closed
The receipt decision was checked separately
expectedReceipt=false while expectedEffects=1 is retained. Review records denial of a new receipt, not rollback of the previous effect.
Workflow observation
Current permission=false
Tuple comparison
Historical effects=1
Review decision
Expected receipt=false
Idempotency was not converted into authority
A repeated commandId helps constrain effect count. It does not replace current permission or actor, action, resource and parameter binding.
Workflow observation
Command key ≠ permission
Tuple comparison
Effects remain 1
Review decision
No new delivery
The different-resource branch was separated
Another row denies the receipt when sameBoundParameters=false even though currentPermission=true. Permission and command matching are independent conditions.
Workflow observation
Two independent gates
Tuple comparison
Parameter binding required
Review decision
Old receipt not generalized
A shared review tuple was selected
Review combines command, actor/action/resource bindings, current permission and effect/receipt counts. The same key alone proves neither delivery nor authority.
Workflow observation
Binding tuple required
Tuple comparison
Current permission required
Review decision
Receipt withheld

Effect unknown

The failure record was classified
The external-result-absent record is conceptual. Even with authorizationEvidence=true, commitEvidence=null leaves the external effect outcome unknown.
Workflow observation
Permission evidence=true
Tuple comparison
Commit evidence=null
Review decision
Receipt=false
A missing result was not counted as failure
An absent receipt does not show that the effect never occurred. Review preserves null commit evidence without converting it into false commit.
Workflow observation
Outcome evidence missing
Tuple comparison
Commit UNKNOWN
Review decision
No receipt evidence
The local rollback record was compared
The controlled local transaction failure row declares rollbackExecuted=true and commit=false. That known rollback is not assumed for the branch missing an external result.
Workflow observation
External: UNKNOWN
Tuple comparison
Local: rollback known
Review decision
Two failures separate
The transaction scope was bounded
A local transaction can protect state and receipt records together. There is no evidence that it makes an external-service effect part of the same atomic boundary.
Workflow observation
Local atomic boundary
Tuple comparison
No external atomicity evidence
Review decision
Outcome remains UNKNOWN
Automatic retry was not approved
automaticRetrySafe=false does not treat an uncertain outcome as sufficient for automatic retry. Outcome and retained-command linkage need reconciliation before another effect.
Workflow observation
Commit UNKNOWN
Tuple comparison
Automatic retry=false
Review decision
Reconciliation required
The final evidence boundary was preserved
These records teach local decision distinctions, not actual payment, external services or parallel-contention measurements. An unknown effect receives neither success nor clean-rollback conclusion.
Workflow observation
Local decisions known
Tuple comparison
External effect UNKNOWN
Review decision
No success receipt

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

One local transaction for guard and commit

The Blue implementation changes the fake catalog row under conditions on current revision and available state. Exactly one affected row advances revision and saves the command receipt in the same transaction. An explicit rollback in a local failure branch undoes both state update and receipt insert. Do not rely on the assumption that every SQLite error automatically rolls back the whole transaction; observe the rollback decision and outcome separately.

Check current authorization at the start of command evaluation. Before inspecting a stored receipt, verify that actor, action and resource binding remain acceptable. Do not treat request-supplied price or role as authority; derive them from server catalog and context. Parameter matching does not conceal a revision conflict, and receipt existence does not replace permission. A real design involving external effects separately handles reconciliation and durable delivery state.

Testing an invariant through outcomes

The initial row is available at revision=7. A normal reservation produces one committed effect and a reserved row at revision=8. Re-evaluating the same retained command leaves the effect count at one. Stale revisions, missing permission, and a rolled-back operation preserve the initial row and produce no new receipt. A previously successful command must not return a cached body after current permission is denied.

These results cover sequential finite tests, not actual contention, crash durability, multi-process scheduling or external payment outcomes. Animation shows the gate as a local null-transfer step, ordinary command arrival as a receiver update and the committed receipt as a separate message. Assessment asks which invariant held, where authority came from and whether rollback or commit is actually known. Invite, coupon and recovery tables require their own purpose-specific guards under the same questions.

NOW APPLY IT TO THE CASE

Which condition cannot be completed by a repeated command or available state?

The copy-A reservation model evaluates current permission, revision and effect outcome separately. A previous effect and new receipt delivery are not the same decision.

Read accepted, delivery and committed-effect records at their respective owners. Do not rename unknown caller outcome as business rollback.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Conditional reservation and receipt

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "resource": "copy-A",
    "actor": "Duru",
    "action": "reserve",
    "initialState": "available",
    "initialRevision": 7,
    "capacity": 1,
    "authoritativePriceUnits": 12,
    "commandId": "reservation-A",
    "quantity": 1,
    "actualPayment": false,
    "actualExternalEffect": false,
    "actualParallelConcurrency": false
  },
  "rows": [
    {
      "case": "normal",
      "label": [
        "Reservation kabul",
        "Reservation allow"
      ],
      "currentPermissionDeclared": true,
      "expectedRevision": 7,
      "effectSucceededDeclared": true,
      "expectedDispatch": true,
      "expectedCommittedWrite": true,
      "expectedReceiptDelivery": true,
      "expectedBody": {
        "reservationId": "reservation-A",
        "resource": "copy-A",
        "revision": 8
      },
      "expectedFinalState": "reserved",
      "expectedFinalRevision": 8
    },
    {
      "case": "stale-revision",
      "label": [
        "Revision eski",
        "Revision stale"
      ],
      "currentPermissionDeclared": true,
      "expectedRevision": 6,
      "effectSucceededDeclared": true,
      "expectedDispatch": true,
      "expectedCommittedWrite": false,
      "expectedReceiptDelivery": false,
      "expectedBody": null,
      "expectedFinalState": "available",
      "expectedFinalRevision": 7
    },
    {
      "case": "permission-missing",
      "label": [
        "Permission eksik",
        "Permission missing"
      ],
      "currentPermissionDeclared": null,
      "expectedRevision": 7,
      "effectSucceededDeclared": true,
      "expectedDispatch": false,
      "expectedCommittedWrite": false,
      "expectedReceiptDelivery": false,
      "expectedBody": null,
      "expectedFinalState": "available",
      "expectedFinalRevision": 7
    },
    {
      "case": "effect-failed",
      "label": [
        "Rollback kararı",
        "Rollback decision"
      ],
      "currentPermissionDeclared": true,
      "expectedRevision": 7,
      "effectSucceededDeclared": false,
      "expectedDispatch": true,
      "expectedCommittedWrite": false,
      "expectedReceiptDelivery": false,
      "expectedBody": null,
      "expectedFinalState": "available",
      "expectedFinalRevision": 7
    }
  ],
  "transitionTable": [
    {
      "before": "available",
      "action": "reserve",
      "guards": [
        "current permission",
        "quantity 1",
        "remaining capacity 1",
        "revision 7"
      ],
      "after": "reserved",
      "afterRevision": 8
    },
    {
      "before": "reserved",
      "action": "same command receipt",
      "guards": [
        "current permission",
        "same actor/action/resource/parameters",
        "retained command record"
      ],
      "after": "reserved",
      "afterRevision": 8
    }
  ],
  "authorityLedger": [
    {
      "field": "priceUnits",
      "authority": "server catalog record",
      "value": 12,
      "callerAuthoritative": false
    },
    {
      "field": "role",
      "authority": "verified server actor context",
      "value": "reader-reserver",
      "callerAuthoritative": false
    },
    {
      "field": "state",
      "authority": "current reservation store",
      "value": "available",
      "callerAuthoritative": false
    }
  ],
  "idempotencyLedger": [
    {
      "operation": "first",
      "currentPermission": true,
      "sameBoundParameters": true,
      "expectedEffects": 1,
      "expectedReceipt": true
    },
    {
      "operation": "same command retained",
      "currentPermission": true,
      "sameBoundParameters": true,
      "expectedEffects": 1,
      "expectedReceipt": true
    },
    {
      "operation": "same command permission denied",
      "currentPermission": false,
      "sameBoundParameters": true,
      "expectedEffects": 1,
      "expectedReceipt": false
    },
    {
      "operation": "same command different resource",
      "currentPermission": true,
      "sameBoundParameters": false,
      "expectedEffects": 1,
      "expectedReceipt": false
    }
  ],
  "flowFamilies": [
    {
      "flow": "invite",
      "subject": "designated recipient",
      "object": "workspace invitation",
      "guards": [
        "pending",
        "unexpired",
        "verified recipient"
      ],
      "transition": "pending -> accepted"
    },
    {
      "flow": "booking",
      "subject": "authorized reserver",
      "object": "owned catalog copy",
      "guards": [
        "current capacity",
        "current revision",
        "available"
      ],
      "transition": "available -> reserved"
    },
    {
      "flow": "coupon",
      "subject": "eligible actor",
      "object": "fictional benefit record",
      "guards": [
        "approved terms",
        "remaining uses",
        "valid period"
      ],
      "transition": "eligible -> applied"
    },
    {
      "flow": "recovery",
      "subject": "account-bound verified recovery context",
      "object": "recovery transaction",
      "guards": [
        "purpose bound",
        "unexpired",
        "unused"
      ],
      "transition": "pending -> completed"
    }
  ],
  "failureLedger": [
    {
      "stage": "before dispatch",
      "authorizationEvidence": null,
      "commit": false,
      "receipt": false
    },
    {
      "stage": "controlled local transaction failure",
      "authorizationEvidence": true,
      "rollbackExecuted": true,
      "commit": false,
      "receipt": false
    },
    {
      "stage": "external result absent (concept only)",
      "authorizationEvidence": true,
      "commitEvidence": null,
      "receipt": false,
      "automaticRetrySafe": false
    }
  ],
  "boundaries": {
    "idempotencyKeyIsPermission": false,
    "localTransactionMakesExternalEffectAtomic": false,
    "sequenceTestProvesConcurrentIsolation": false
  }
}

profile: Fake copy, authoritative priceUnits, revision and command scope.
rows: Current permission/revision/effect evidence and committed state/receipt outcomes.
transitionTable: Guarded state transitions versus retained-command receipts.
authorityLedger: Server-owned authority sources for price/role/state.
idempotencyLedger: One effect and current authorization for bound-command retries.
flowFamilies: Purpose-specific guards for invite/booking/coupon/recovery.
failureLedger: Pre-dispatch denial, known rollback and unknown external commit.
boundaries: Evidence limits of key possession, local transactions and sequential tests.

Owned in-memory SQLite sequential fake reservation; no parallel race, payment, real identity or external effect.

Two reality checks

An idempotency key proves permission.

Current authorization is required before returning a retained result; a key only identifies a bound command.

No response means no write occurred.

Without commit evidence the outcome may be unknown; explicit rollback here proves only its own local transaction.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Revision=7 and the effect condition passes, but currentPermissionDeclared=null. Is the reservation dispatched to the store?

No. There is no dispatch, write or receipt.
Yes. Correct revision and an idempotency key supply all permission.

Read the explained answer

No. There is no dispatch, write or receipt. — The permission-missing row has expectedDispatch=false and expectedBody=null. State does not change without required current permission evidence.

The same command previously produced an effect. With current permission denied, why do expectedEffects stay at one while expectedReceipt=false?

Selected lesson artifact fields; teaching example

idempotencyLedger[0]: {"operation":"first","currentPermission":true,"sameBoundParameters":true,"expectedEffects":1,"expectedReceipt":true}
idempotencyLedger[1]: {"operation":"same command retained","currentPermission":true,"sameBoundParameters":true,"expectedEffects":1,"expectedReceipt":true}
idempotencyLedger[2]: {"operation":"same command permission denied","currentPermission":false,"sameBoundParameters":true,"expectedEffects":1,"expectedReceipt":false}

Permission denial automatically rolls back the earlier successful reservation.
The previous effect is not undone; new receipt delivery is withheld.

Read the explained answer

The previous effect is not undone; new receipt delivery is withheld. — Dedupe retains the prior effect. Finding the same command record does not authorize sharing its receipt body without current permission.

Stale-revision and effect-failed branches retain available/revision=7. Why are revision guards, transaction rollback and an unknown external result separate?

Read the explained answer

A stale revision fails the conditional-write guard. Local effect failure rolls back the transaction and withholds success receipt. A missing external result may leave commit/effect unknown, so automatic retry is not assumed safe. A local transaction does not make an external effect atomic. This reservation example is neither a real payment nor a parallel-concurrency test. Client fields do not replace server authority over price, role and workflow state.

□ I separated stale guards, rollback and unknown outcomes.

□ I did not infer external atomicity from a local transaction.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OWASP Business Logic SecurityAlways Re-derive Security-relevant Values on the Server / Prices and Totals; Permissions and Ownership; Identity and Role · Model Workflows Explicitly / Define and Enforce State Transitions · Prevent Race Conditions / Use Database Transactions and Locks: conditional update and affected rows; Use Idempotency Keys: authorization before cached result
SQLite transaction documentation§2.1 Read transactions versus write transactions; §2.2 DEFERRED, IMMEDIATE and EXCLUSIVE · §3 Response To Errors Within A Transaction: explicit rollback and error scope
OWASP Forgot PasswordIntroduction guidelines: single use, expiration and no account change before verified evidence · Methods / General Security Practices: bind to individual user and invalidate after use
Python 3.14 sqlite3 documentationconnect: :memory:, isolation_level=None and LEGACY_TRANSACTION_CONTROL scope · Connection.in_transaction; Cursor.execute parameter binding; Cursor.rowcount; Transaction control via isolation_level

YOUR NOTES / THIS BROWSER

Business invariants and workflow state machines

1. Core · Mechanism

Reservation allow

Revision stale

Permission missing

Rollback decision

Invariant, transition and authority

Revision and idempotency solve different problems

Comparing invite, booking, coupon and recovery

2. Red · Trust & Impact

Stale revision

Permission missing

Broken assumption: the right sequence grants domain permission

Broken assumption: attempting an effect completes success

3. Blue · Secure development & defense

Receipt authority

Effect unknown

One local transaction for guard and commit

Testing an invariant through outcomes

Which condition cannot be completed by a repeated command or available state?

Two reality checks

Revision=7 and the effect condition passes, but currentPermissionDeclared=null. Is the reservation dispatched to the store?

The same command previously produced an effect. With current permission denied, why do expectedEffects stay at one while expectedReceipt=false?

Stale-revision and effect-failed branches retain available/revision=7. Why are revision guards, transaction rollback and an unknown external result separate?

Sources and scope