Amit’s Library

Transform work with governed, dependable requests

Follow an organisational change from its benefit case to correction authority and request-handling behaviour. Prerequisites: the shared-records workshop, basic Python functions and transaction concepts. Allow approximately two to three hours for reading, experimentation and a memo; this is an editorial estimate.

Reading sequence

  1. Digital transformation: value, process change, adoption and balanced benefit measurement.
  2. Data governance: definitions, permitted use, decision rights and correction.
  3. API integration: contracts, ambiguous outcomes, retries and boundaries.

Each chapter has separate foundation, undergraduate, postgraduate and research teaching, plus four individual questions with indicative marking guidance.

Predict and run

Download durable_requests.py. Run python3 durable_requests.py. It uses Python's standard library, synthetic records and a temporary SQLite file. Each operation opens and closes a connection. The file retains state between operations and is deleted when the demonstration ends.

  1. First R1 approves O1 for 10,000 paise: approved.
  2. Repeating R1 after a connection closure: replayed, with no extra order.
  3. Changing the payload under R1: conflict.
  4. A simulated viewer role: forbidden.
  5. Failure after inserting O3 but before storing R3 rolls back: total remains one order and 10,000 paise.
  6. Retry R3 successfully: final count two and total 17,000 paise, equivalent to INR 170.

Extend one boundary at a time

Use a fresh practice path in a temporary folder for experiments. Call apply(path, request_id, order_id, amount_paise). Reopen from a separate Python process and retry an accepted request: the stored state should identify the replay. Use the supplied tests for a repeatable process-restart example. Do not reuse a database containing organisational records.

Try zero, a negative amount, a Boolean amount, an empty identifier and a new request naming an existing order. Explain which validation or identity rule rejects each case. A correction is different from a retry: propose a separate reviewed correction operation instead of weakening conflict detection. Define who authorises it and what downstream reports must change.

Balanced business case

Baseline: 100 approvals × six minutes = 600 minutes. Proposed routine work: 100 × two = 200 minutes; exceptions: twenty × ten = 200. Total 400; saved time 200 minutes. Valuing this at INR 300/hour gives INR 1,000 against an illustrative INR 1,500 weekly system cost. Explain why the INR 500 shortfall is a limited time-value comparison, not a full cash-flow or customer-value assessment. Include training, error reduction, capacity use and workload in your recommendation.

Roles, feedback and continuous improvement

Sales supplies the promised order meaning, finance reviews monetary consequences, operations evaluates feasible work, the steward maintains definitions and IT implements the rule. Management decides whether the pilot meets its balanced objectives. Customer and employee feedback can reveal failures that a successful transaction test does not measure. Record a reason to pause or revise the intervention.

The fixture's role parameter simulates an access decision. It is not authentication: a real system must derive authority from trusted identity and enforce it appropriately. The exercise also provides no transport, external service, durable audit history, correction API or distributed exactly-once guarantee.

Assessment and portfolio

Open chapter questions before checking answers: transformation, governance, integration. Revisit the matching chapter revision cards. Submit a process map, benefit contract, decision-rights table, request specification, failure evidence and recovery memo. Use Who, Whom, Whose, What, Where, When, Why, Which and How to expose the assumptions behind the design.

Free primary references

RFC 9110: HTTP Semantics — study method semantics and idempotence, especially section 9.2.2. Python sqlite3 documentation — connections, transactions and parameterised operations. These publicly readable references were checked on 3 October 2026; they are not free certificates or deployed infrastructure.

Previous workshop: shared records · Current status · Your progress