Reading room

Before you read

Redo our HelloPolicy lab so the chapter lands on working intuition, not blank pages.

Answer while reading

1. Which data types would you use for premium amounts, policy ids, and expiry dates — and why do wei-scale integers make rounding rules explicit?
2. What exactly does payable change about a function, and which HelloPolicy functions carry it?
3. When does the chapter reach events, how does indexing work, and what would your claims backend subscribe to?
4. Where do require/revert/custom errors each belong in a premium-collection flow?

After

Extend HelloPolicy with one feature the chapter taught you (e.g. a beneficiary address set at purchase, or a per-holder cover limit) — compile it clean in Remix.

How to study it

Don't read linearly. For each vulnerability class, run a three-step drill: ① read the attack until you can explain it to a colleague in two sentences, ② find which of our M02 "top-8 wounds" it matches, ③ write the one-line defence rule you'd enforce in code review.

Answer while reading

1. For reentrancy: why does checks-effects-interactions work, and what would the equivalent bug look like in TyphoonCover's claim() if the flag moved after the transfer?
2. Which attacks disappear on a permissioned chain (M03) and which survive unchanged? (This question sorts real security understanding from folklore.)
3. Whose incentives does front-running exploit, and does your parametric trigger design expose any?

After

Play three levels of Ethernaut. If you can beat "Re-entrancy" and explain why, this chapter did its job.

Answer while reading

1. Which oracle designs does the chapter distinguish (immediate-read, publish-subscribe, request-response), and which does a typhoon trigger need?
2. What trust assumptions does each design make — and who, concretely, would you be trusting for PAGASA wind data?
3. How do decentralised oracle networks change the failure story you coded in refundOnDataFailure()?

After

Rewrite the "oracle governance" row of your M06 edge-case table with the chapter's vocabulary — it should get twice as precise.

Answer while reading

1. List every guardrail layer the chapter names, then sort each into our four buckets: input filter, output validator, action limit, kill-switch. Which bucket is thinnest — there and in your own org?
2. What does a "constitution" concretely contain, and what would five articles of an insurance conduct constitution say? Draft them.
3. Where does the chapter argue a ledger beats a database for AI governance — and does that argument survive our M05 three-question framework?

After

Bring your five draft articles to Exercise 11.1 — they become the policy your decision-record schema must reference.

Answer while reading

1. Extract the chapter's decision criteria into a two-column table: "changes weights?" / "changes context?" — costs, update speed, auditability.
2. Note every inference metric it defines (latency, throughput, batching effects) — which would an insurer's SLA quote?

Then decide these four (our worksheet)

1. Claims triage over ever-changing policy wordings → RAG or FT?
2. A tone-consistent customer-email drafter → RAG or FT?
3. Fraud-pattern classifier on stable historical labels → RAG or FT?
4. Underwriting copilot citing current reinsurance treaties → RAG or FT?

Our answers: 1 RAG (fresh wordings, citations, auditability) · 2 FT (style is weights) · 3 FT/classical (stable distribution) · 4 RAG (currency + provenance). Argue with us.

The lens

Clinical trials and insurance claims share a shape: high-stakes decisions, regulator scrutiny, and an incentive to quietly rewrite history. Read every pattern asking "what is the claims equivalent?"

Answer while reading

1. What, exactly, gets anchored in the trial-integrity designs — raw data, documents, or hashes? Why does that answer repeat our M04 PII rule?
2. How does the reputation system bind identity to track record — and what would an adjuster or an AI model's version history look like in that scheme?
3. In drug tracking, who verifies, and when? Map each verifier to an insurance counterpart (auditor, regulator, reinsurer).

After

Add one improvement to your Fig 11.1 decision-record schema that this chapter earned you (most readers add pre-registration: anchoring the decision policy before decisions are made, not just decisions after).

Answer while reading

1. Fill the chapter's canvas for your capstone proposal: problem, users, value, channels, costs, revenue/funding — who pays in year 4 goes in ink.
2. Which canvas box did B3i, we.trade and Contour all leave empty? (Check against M08/M09's autopsies.)
3. What does "lean" change about a 90-day PoC — and what's your kill criterion, stated before you start?

After

Staple the finished canvas to capstone deliverable D6. A proposal that survives this chapter survives most steering committees.

Answer while reading

1. Draw the five layers (data / network / consensus / contract / application) from memory after reading — then place every M01 concept (hash, block, PoS, chaincode, wallet) on the right layer.
2. Where does the chapter put Paxos/Raft relative to PBFT and PoW — and why does that ordering explain enterprise chains' "instant finality"?
3. Which of the chapter's blockchain "characteristics" is the weakest claim, in light of our immutability-asterisks lesson?

After

Retake the M01 quiz. This chapter typically converts the last stubborn wrong answer.